Signed-off-by: Igor M. Liplianin <liplianin@netup.ru> --- drivers/media/video/cx23885/cx23885-core.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/cx23885/cx23885-core.c b/drivers/media/video/cx23885/cx23885-core.c index 307eaf4..3a09dd2 100644 --- a/drivers/media/video/cx23885/cx23885-core.c +++ b/drivers/media/video/cx23885/cx23885-core.c @@ -904,12 +904,6 @@ static int cx23885_dev_setup(struct cx23885_dev *dev) dev->pci_bus = ...

The mm-of-the-moment snapshot 2010-08-27-15-43 has been uploaded to http://userweb.kernel.org/~akpm/mmotm/ and will soon be available at git://zen-kernel.org/kernel/mmotm.git It contains the following patches against ...

Now that the drivers have caught up, we can push out the Blackfin arch changes. This fixes some issues David pointed out. Only failures left are the NOMMU FB fix which David has already pushed, the linker script issue Sam sent out, and a new bug that has hit the NAND tree. I'll research & fix that in a bit. Barry Song (1): Blackfin: bf52x/bf54x boards: drop unused nand page size Mike Frysinger (1): Blackfin: punt duplicate SPORT MMR defines arch/blackfin/include/asm/bfin_sport.h ...

From: Barry Song <barry.song@analog.com> Now that the driver for the Blackfin on-chip NFC no longer uses/respects the page_size from the platform resources (figures out the needs on the fly), drop it from the platform resources. This fixes some build errors since the defines no longer exists. Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> --- arch/blackfin/mach-bf527/boards/cm_bf527.c | 1 - arch/blackfin/mach-bf527/boards/ezbrd.c ...

I downloaded the LDD examples (http://examples.oreilly.com/9780596005900/), and I unzipped the file and just tried building it with make just to see if it built properly and here are the errors I get: setlevel.c:30: error: expected declaration specifiers or '...' before 'type' setlevel.c:30: error: expected declaration specifiers or '...' before 'bufp' setlevel.c:30: error: expected declaration specifiers or '...' before 'len' setlevel.c:30: warning: data definition has no type or storage ...

This driver is for the QCI i2c keyboard used on Quanta smartbooks. Signed-off-by: Horace Fu <horace.fu@quantatw.com> [nleeder@codeaurora.org: cleanup to latest kernel standards] Signed-off-by: Neil Leeder <nleeder@codeaurora.org> --- drivers/input/keyboard/Kconfig | 12 ++ drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/qci_gkbd.c | 258 ++++++++++++++++++++++++++++++++++++ include/linux/input/qci_keyboard.h | 25 ++++ 4 files changed, 296 insertions(+), 0 ...

Hello, I was told that lkml is still highly preferred over bugzilla, so reposting the bugreport here. The problem first manifested as "ext3 hang" in 2.6.27 based kernel; the cause appeared to be somewhat more involved, see the analysis below. hpa@ confirmed he's seen similar problems elsewhere. This has been worked around in mainline since but our folks consider the fix potentially broken and propose the real one (this seems to have not been fixed for -stable, not sure; the patch is for ...

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- Documentation/power/regulator/overview.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt index 9363e05..8ed1758 100644 --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -13,7 +13,7 @@ regulators (where voltage output is controllable) and current sinks (where ...

It might be nicer to align the output. For instance, ACPI messages sometimes have "(null)" pointers. $ dmesg | grep "(null)" -A 1 -B 1 [ 0.198733] ACPI: Dynamic OEM Table Load: [ 0.198745] ACPI: SSDT (null) 00239 (v02 PmRef Cpu0Ist 00003000 INTL 20051117) [ 0.199294] ACPI: SSDT 7f596e10 001C7 (v02 PmRef Cpu0Cst 00003001 INTL 20051117) [ 0.200708] ACPI: Dynamic OEM Table Load: [ 0.200721] ACPI: SSDT (null) 001C7 (v02 PmRef Cpu0Cst 00003001 INTL 20051117) [ 0.201950] ...

This problem was originally tracked down by Brad Spengler. When calling wireless ioctls, if a driver does not correctly validate/shrink iwp->length, the resulting copy_to_user can leak up to 64K of kernel heap contents. It seems that this is triggerable[1] in 2.6.32 at least on ath5k, but I was not able to track down how. The twisty maze of ioctl handlers stumped me. :) Other drivers I checked did not appear to have any problems, but the potential remains. I'm not sure if this patch is the ...

Hi Jean, I did not, no. Since I couldn't reproduce the original problem (I lacked the hardware to test ath5k, and all the other drivers correctly managed The comment should probably be clarified -- it's the caller's iwp->length that may be causing problems (when combined with a driver that forgets to adjusted iwp->length downward). Regardless, the above patch would appear to limit the copy_to_user to only the kzalloced region. Thanks! -Kees -- Kees Cook Ubuntu Security Team --

Got it, ah so it would be Cc: stable@kernel.org [2.6.27+]. To get this trickled in we first need it for wireless-testing.git, and provide links / patches to the backport of the patch for each kernel. Once it gets merged into Linus' tree the stable team can apply the respective backported patches. Luis --

By moving the iounmap up above the test, it takes place whether the test succeeds or fails. The sematic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression x; expression E,E1; identifier l; statement S; @@ *x = ioremap_nocache(...); ... if (x == NULL) S ... when != iounmap(x) when != if (...) { ... iounmap(x); ... } when != E = x if (...) { ... when != iounmap(x) when != if (...) { ... iounmap(x); ... ...

Sorry if this is the wrong place to ask. https://bugzilla.kernel.org/ seems not to be responding. In fact I got the login page after waiting many minutes, but get no response after waiting of the order of 30 minutes when attempting to login. ael --

The string clone is only used as a temporary copy of the argument val within the while loop, and so it should be freed before leaving the function. The call to strsep, however, modifies clone, so a pointer to the front of the string is kept in saved_clone, to make it possible to free it. The sematic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression x; expression E; identifier l; statement S; @@ *x= ...

Hello, I'm in the process of dusting off some old unidirectional fiber link patches as part of support for a new custom hardware chassis. Specifically, a critical piece of the hardware is unidirectional fiber connections between independent computers, with data transmission performed using UDP to a static ARP entry. These first 2 RFC patches provide support for off-the-shelf gigabit sky2 boards. I also have another fairly trivial patch to "ethtool" which enables it to configure the new ...

On Fri, 27 Aug 2010 15:51:58 -0500 No that is fine, but the FIB doesn't really understand RX only links so I expect users will do stupid things. --

Well, I suppose that's possible, but we've only just reset and enabled the PHY moments before, so I don't see where you could get an *extra* 2-second delay. On the other hand, I suppose it would be much nicer if there was an easy way to fake an extra interrupt there instead of reinitializing the whole PHY. I'm not all that comfortable with my understanding of the interrupt logic in the sky2 driver, so I figured I would just reuse all the necessary locking from sky2_phy_reinit(). Do you have any ...

The Intel 82571EB chipset can be used in an unmanaged configuration as a fast dual-port Gig-E controller. Unfortunately a board constructed that way would fail to correctly come up because the driver polls for the completion of a management cycle that will never occur. To resolve this problem, we disable the poll and error return on chips whose EEPROMs indicate no management. As a protection against misconfigured chipsets, we still delay for the entire management ...

[cc'ing Thomas Gleixner and David Woodhouse since this driver needs to get some data about the platform (to know what spi_devices are present) and I don't know how that is handled for x86 SoCs.] Hi Ohtak-san, Comments below. This shouldn't be a separate driver. The SoC platform setup code should take care of registering the devices which will be on the spi Hmmm. I think I misunderstood the purpose of this symbol in your initial posting. This isn't the number of busses (as I ...

I tentatively agree, but this has to coexist with ACPI, which most of these platforms will also have, for power management if nothing else. --

I knew you were going to say that! :-) Ohtak-san, for this patch I'd like you to drop the separate driver that only registers the spi_devices and just submit the core driver. (You can of course keep the spi_device registration in your own tree for debug purposes). I'll expect that the device will get instantiated using a device tree to determine which spi_devices are present. The parsing of spi device tree data will be moving into the core spi subsystem code in the next merge window most ...

Move enable_IR_x2apic() inside the default_setup_apic_routing() And for smp platforms, move the default_setup_apic_routing() after smp_sanity_check(). This cleans up the code that tries to avoid multiple calls to default_setup_apic_routing() when smp_sanity_check() fails (which goes through the APIC_init_uniprocessor() path) Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> --- arch/x86/kernel/apic/apic.c | 3 --- arch/x86/kernel/apic/probe_64.c | 3 +++ ...

Hi, I have received many mails asking to refresh the patch so I decided to post them on the public mailing list In this version such feature is configurable via a kernel config option Signed-off-by: Matteo Croce <matteo@openwrt.org> --- a/arch/x86/kernel/Makefile 2010-08-27 00:27:50.101261000 +0200 +++ b/arch/x86/kernel/Makefile 2010-08-27 00:31:11.391261002 +0200 @@ -88,6 +88,8 @@ obj-$(CONFIG_APB_TIMER) += apb_timer.o obj-$(CONFIG_K8_NB) += k8.o +obj-$(CONFIG_GEODE_NOPL) += ...

Same line added twice... -- Thomas --

You're doing user-space references without get_user(). -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

Sorry still left the duplicated line --- a/arch/x86/kernel/Makefile 2010-08-27 19:42:01.795858001 +0200 +++ b/arch/x86/kernel/Makefile 2010-08-28 00:16:53.607507000 +0200 @@ -88,6 +88,7 @@ obj-$(CONFIG_APB_TIMER) += apb_timer.o obj-$(CONFIG_K8_NB) += k8.o +obj-$(CONFIG_GEODE_NOPL) += nopl_emu.o obj-$(CONFIG_DEBUG_RODATA_TEST) += test_rodata.o obj-$(CONFIG_DEBUG_NX_TEST) += test_nx.o --- a/arch/x86/kernel/cpu/amd.c 2010-08-27 19:42:01.855858001 +0200 +++ ...

can I ignore the return value when I expect val to be non zero? the doc says: "On error, the variable @x is set to zero." -- Matteo Croce OpenWrt developer   _______                     ________        __  |       |.-----.-----.-----.|  |  |  |.----.|  |_  |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|  |_______||   __|_____|__|__||________||__|  |____|           |__| W I R E L E S S   F R E E D O M  KAMIKAZE (bleeding edge) ------------------   * 10 oz Vodka       Shake well ...

Hello, Nope, REQ_FUA will be interpreted by queues lower in the stack. Heh... I probably should set up a simple dm-mpath and test it. I'll Sure, that's a rather silly wrapper at this point. Thanks. -- tejun --

Hello, This patchset converts dm to REQ_FLUSH/FUA, which was the last remaining one. I've put patches on top of the previous patches for easier review. The series can be trivially reordered so that the order is more logical. Jens, please let me know if you want it to be reordered. The dm conversion is _lightly_ tested. Please proceed with caution. In particular, I haven't tested dm implementation at all. So, it probably is best to hold off merging these bits until dm people can verify ...

Unlike REQ_HARDBARRIER, REQ_FLUSH/FUA doesn't mandate any ordering against other bio's. This patch relaxes ordering around flushes. * A flush bio is no longer deferred to workqueue directly. It's processed like other bio's but __split_and_process_bio() uses md->flush_bio as the clone source. md->flush_bio is initialized to empty flush during md initialization and shared for all flushes. * When dec_pending() detects that a flush has completed, it checks whether the original bio has ...

Currently __blk_rq_prep_clone() copies only REQ_WRITE and REQ_DISCARD. There's no reason to omit other command flags and REQ_FUA needs to be copied to implement FUA support in request-based dm. REQ_COMMON_MASK which specifies flags to be copied from bio to request already identifies all the command flags. Define REQ_CLONE_MASK to be the same as REQ_COMMON_MASK for clarity and make __blk_rq_prep_clone() copy all flags in the mask. Signed-off-by: Tejun Heo <tj@kernel.org> --- ...

Is this right? I got a built failure before 7x00 isn't in the list.. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --

Now that all supported gpio_tlmm_config-using boards are using gpiomux, remove the deprecated code. Signed-off-by: Gregory Bean <gbean@codeaurora.org> --- arch/arm/mach-msm/Makefile | 1 - arch/arm/mach-msm/gpio.c | 85 ----------------------- arch/arm/mach-msm/include/mach/gpio.h | 123 --------------------------------- 3 files changed, 0 insertions(+), 209 deletions(-) delete mode 100644 arch/arm/mach-msm/gpio.c diff --git a/arch/arm/mach-msm/Makefile ...

Change deprecated gpio_tlmm_config calls to gpiomux calls. Signed-off-by: Gregory Bean <gbean@codeaurora.org> --- arch/arm/mach-msm/board-msm7x30.c | 20 -------------------- arch/arm/mach-msm/gpiomux-7x30.c | 21 ++++++++++++++++++++- 2 files changed, 20 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c index e329819..74abb74 100644 --- a/arch/arm/mach-msm/board-msm7x30.c +++ b/arch/arm/mach-msm/board-msm7x30.c @@ ...

v2: http://lkml.indiana.edu/hypermail/linux/kernel/1008.1/01838.html Changes since v2: use #define for wait length during init, as suggested by Shubhrajyoti Datta add error check from gpio_direction_input move struct i2c_device_id closer to its use in i2c_driver, for clarity -- Neil -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --

Hello, I2C part of lis3 accelerometer driver can be unloaded while in use which may cause kernel oops. These patches allow to change /dev/freefall file ops owner to prevent driver unloading while device in use. Please review. Best regards, Yuri Yuri Kululin (2): lis3: Add device owner lis3: Set device owner drivers/hwmon/lis3lv02d.c | 8 ++++++-- drivers/hwmon/lis3lv02d.h | 2 ++ drivers/hwmon/lis3lv02d_i2c.c | 2 ++ 3 files changed, 10 insertions(+), 2 ...

Set device owner for i2c part. Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com> --- drivers/hwmon/lis3lv02d_i2c.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/hwmon/lis3lv02d_i2c.c b/drivers/hwmon/lis3lv02d_i2c.c index b2f8bae..1a55bb3 100644 --- a/drivers/hwmon/lis3lv02d_i2c.c +++ b/drivers/hwmon/lis3lv02d_i2c.c @@ -129,6 +129,7 @@ static int __devinit lis3lv02d_i2c_probe(struct i2c_client *client, lis3_dev.reg_ctrl = lis3_reg_ctrl; ...

ATTENTION: WEBMAIL SUBSCRIBER: This mail is to inform all our {WEBMAIL} users that we will be upgrading our site in a couple of days from now. So you as a Subscriber of our site you are required to send us your Email account details so as to enable us know if you are still making use of your mail box. Further informed that we will be deleting all mail account that is not functioning so as to create more space for new user. so you are to send us your mail account details which are as ...

I have another crash dump which recorded the same values in the debug fault handler, but the resulting crash dump contains 0x1 (not 0x0) in the spinlock. R15 was still 0x1 (even though it should contain the original value, not the incremented one, shouldn't it?). Petr Tesarik --

OTOH the counter is only 15-bit, so it also wraps around at 0xfffe7fff, but I have never seen it fail there. It always fails after the wrap-around from 0xfffeffff. Petr Tesarik --

Here it is. I don't have a system with the old 64-bit ticket spinlocks at hand, so this is completely untested, but it should work fine. Adjust if needed. Petr

On Fri, Aug 27, 2010 at 18:16 Petr Tesarik wrote: | On Friday 27 of August 2010 18:08:03 Luck, Tony wrote: | > > Hedi Berriche sent me a simple test case that can | > > trigger the failure on the siglock. | > | > Can you post the test case please. How long does it typically take | > to reproduce the problem? | | I let Hedi send it. It's really easy to reproduce. In fact, I can reproduce it | within 5 minutes on an 8-CPU system. Test case provided via private email. Cheers, Hedi. -- ...

Hi everybody, SGI has recently experienced failures with the new ticket spinlock implementation. Hedi Berriche sent me a simple test case that can trigger the failure on the siglock. To debug the issue, I wrote a small module that watches writes to current->sighand->siglock and records the values. I observed that the __ticket_spin_lock() primitive fails when the tail wraps around to zero. I reconstructed the following: CPU 7 holds the spinlock CPU 5 wants to acquire the spinlock Spinlock ...

I let Hedi send it. It's really easy to reproduce. In fact, I can reproduce it Right. I also realized I was reading the spinlock value with a plain "ld4". When I changed it to "ld4.acq", this is what happens: 1. We're in _spin_lock_irq, which starts like this: 0xa0000001008ea000 <_spin_lock_irq>: [MMI] rsm 0x4000;; 0xa0000001008ea001 <_spin_lock_irq+1>: fetchadd4.acq r15=[r32],1 0xa0000001008ea002 <_spin_lock_irq+2>: nop.i 0x0;; AFAICS the spinlock ...

I think I take this back ... if it were a memory ordering problem, then it could show up any time - not just at wrap-around. -Tony --

Can you post the test case please. How long does it typically take What is the duplicate ticket number that CPUs 5 & 7 get at this point? Is the fault handler using "ld.acq" to look at the spinlock value? If not, then this might be a red herring. [Though clearly something What cpu model are you running on? What is the topological connection between CPU 4, 5 and 7 - are any of them hyper-threaded siblings? Cores on same socket? N.B. topology may change from boot to boot, so you may need to ...

I wouldn't be so sure about it. Given that I have only observed the problem when the spinlock value wraps around, then an 8-byte spinlock might only need much more time to trigger the bug. Just my two cents, Petr Tesarik L3 International Novell, Inc. --

Hello, I sometimes see this on one of my two 3ware cards in my system. I have opened a case previously with LSI/3ware and they are not sure what is going on, all disks are good, etc. I notice this sometimes occurs when there is high I/O & network activity, but I am not able to reproduce it at will. I do remember it happening before though just running a postmap on some files and rsyncing a few configuration files around. Originally I thought it might be something to do with having ...

Hi Adam, Thanks for responding! LSI just got back to me on a second case, their latest beta firmware: http://www.lsi.com/DistributionSystem/AssetDocument/readme.txt SCR 2196: Unexpected controller soft resets Fixed an issue with regards to deferral of write and read commands to help eliminate unexpected soft resets. Well well! Plan of action: 1. See if the error recurs without 'nobarrier' - only because there are some threads about problems when this is enabled on 3ware ...

Patch set provides driver for ak8974 and ami305 3 axis magnetometer driver. Data is provided via misc character device as a structure of data. Driver supports regulator framework and has PM support. Short documentation is also provided. Data format and sysfs interface is shortly described in the documentation. Provided data is raw magnetic field density for 3 axis. For compass purposes data requires further processing. Samu Onkalo (3): drivers: misc: ak8974 / ami305 magnetometer ...

So we have a different API to the ak8975 just posted and to the other existing devices. This needs sorting out across the devices before there is a complete disaster. Right now we have a mix of submissions pending which variously use misc + sysfs sysfs input (reporting X Y Z etc axes) What happens if you have two readers - is it fine they get copies of the Pedantically if data is consumed and a partial copy occurs you should Other devices make all of this sysfs or use input. We ...

Your understanding is correct - the regulator API provides separation between the driver and the platform so that the driver code can work with any platform. The driver requests supplies in terms of the physical supplies the chip has (using the struct device and the supply names from the datasheet). The regulator API them matches this with actual regulators on a given system using data provied separately by the code specific to that machine so that the regulator and the consumer using it ...

This is really hard question and I am going back and forth myself. When considering using input subsystem try answering the following question - is the device's main purpose is indeed to be a human interface device or do you want to use input subystem because evdev interface is convenient? If the answer is former- then it should be in input (or available through input - let's say IIO-to-input bridge module). If the answer is latter then input is not the right place for the device. Lately I ...

Hi, (please keep me on CC) in order to improve IO behavior on my brand new DELL Presision M4500 notebook, I have decided to try out a newer kernel compared to the 2.6.18-xxx CentOS one. Installing 2.6.35.4 went pretty well and besides small problems with two external/proprietary modules (my fault, I know ...) I only see two issues: a) accessing the HW clock does not work [root@lbwjxqm1 ~]# hwclock Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of ...

Check the argument name whether it is invalid (not C-like symbol name). This makes event format simple. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: linux-kernel@vger.kernel.org --- kernel/trace/trace_kprobe.c | 20 ...

Don't make argument names from raw parameters (means the parameters are written in kprobe-tracer syntax), because the argument syntax may include special characters. Just leave it, then kprobe-tracer gives a new name. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Arnaldo Carvalho de Melo ...

Set "argN" name for each argument automatically if it has no specified name. Since dynamic trace event(kprobe_events) accepts special characters for its argument, its format can show those special characters (e.g. '$', '%', '+'). However, perf can't parse those format because of the character (especially '%') mess up the format. This sets "argX" name for those arguments if user omitted the argument names. E.g. # echo 'p do_fork %ax IP=%ip $stack' > tracing/kprobe_events # cat ...

The exportfs encode handle function should return the minimum required handle size. This helps user to find out the handle size by passing 0 handle size in the first step and then redoing to the call again with the returned handle size value. Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/btrfs/export.c | 8 ++++++-- fs/exportfs/expfs.c | 9 +++++++-- fs/fat/inode.c | 4 +++- ...

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/compat.c | 11 +++ fs/exportfs/expfs.c | 2 + fs/namei.c | 223 +++++++++++++++++++++++++++++++++++++++++++--- fs/open.c | 32 ++++++- include/linux/fs.h | 10 ++- include/linux/namei.h | 1 + include/linux/syscalls.h | 3 + 7 files changed, 263 insertions(+), 19 deletions(-) diff --git a/fs/compat.c b/fs/compat.c index 718c706..c4037fd ...

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/open.c | 20 ++++++++++++++++++++ include/linux/syscalls.h | 2 ++ 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/fs/open.c b/fs/open.c index 7abdcba..5e06c12 100644 --- a/fs/open.c +++ b/fs/open.c @@ -623,6 +623,26 @@ out: return error; } +SYSCALL_DEFINE4(handle_chown, int, mountdirfd, struct file_handle __user *, ufh, + uid_t, user, gid_t, group) +{ + struct path ...

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/compat.c | 20 ++++++++++++++++++ fs/utimes.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ include/linux/syscalls.h | 3 ++ include/linux/time.h | 3 ++ 4 files changed, 75 insertions(+), 0 deletions(-) diff --git a/fs/compat.c b/fs/compat.c index c4037fd..29c4cb4 100644 --- a/fs/compat.c +++ b/fs/compat.c @@ -131,6 +131,26 @@ asmlinkage long compat_sys_utimes(const char ...

File system UUID is made available to application via /proc/<pid>/mountinfo Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/ext4/super.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 2614774..b46a78c 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2941,6 +2941,8 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) sb->s_qcop = &ext4_qctl_operations; sb->dq_op ...

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/stat.c | 28 ++++++++++++++++++++++++++++ include/linux/syscalls.h | 3 +++ 2 files changed, 31 insertions(+), 0 deletions(-) diff --git a/fs/stat.c b/fs/stat.c index 12e90e2..29052eb 100644 --- a/fs/stat.c +++ b/fs/stat.c @@ -319,6 +319,34 @@ SYSCALL_DEFINE3(readlink, const char __user *, path, char __user *, buf, return sys_readlinkat(AT_FDCWD, path, buf, bufsiz); } ...

This patch add new syscalls to x86_64 Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- arch/x86/ia32/ia32entry.S | 11 +++++++++++ arch/x86/include/asm/unistd_64.h | 24 ++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 0 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index b86feab..7b6c67d 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -845,4 +845,15 @@ ia32_sys_call_table: .quad ...

Hi, The below set of patches implement open by handle support using exportfs operations. This allows user space application to map a file name to file handle and later open the file using handle. This should be usable for userspace NFS [1] and 9P server [2]. XFS already support this with the ioctls XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE. [1] http://nfs-ganesha.sourceforge.net/ [2] http://thread.gmane.org/gmane.comp.emulators.qemu/68992 git repo for the patchset ...

--

Reviewed-by: Rik van Riel <riel@redhat.com> -- All rights reversed --

From: Andreas Herrmann <andreas.herrmann3@amd.com> Provide a common function to sign extend a value. Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> --- drivers/net/wireless/ath/ath5k/phy.c | 6 ------ drivers/net/wireless/ath/ath9k/hw.h | 6 ------ drivers/net/wireless/iwlwifi/iwl-4965.c | 16 ---------------- include/linux/bitops.h | 11 +++++++++++ 4 files changed, 11 insertions(+), 28 deletions(-) Recently I needed to sign extend some ...

On Fri, Aug 27, 2010 at 6:16 AM, Andreas Herrmann Note these two are specified slightly differently, so return different values with the same arguments. The ath[59]k version takes the number of bits (1-based) while the other one takes the position of the high order bit (0-based). I think the former is a little more natural but it's a matter of taste. Anyway I personally have no problem with merging them once the above is fixed. I wrote a similar patch when I wrote the ath5k version, ...

The problem with using a non-upstream commit ID like this is that it likely The patch being part of the series is probably sufficient, though a note of A summary of the changes being made is good: ptrace: Fix up the arguments arch_ptrace() in arch FRV Fix up the arguments to arch_ptrace() to take account of the fact that addr and data are now unsigned long rather than long as of a preceding patch in this series. Signed-off-by: ... Note, however, that if the earlier patch ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Russell King <linux@arm.linux.org.uk> --- arch/arm/kernel/ptrace.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c index f99d489..87ca2c7 100644 --- a/arch/arm/kernel/ptrace.c +++ b/arch/arm/kernel/ptrace.c @@ -847,7 +847,8 @@ static ...

That description means nothing. Commit f76671df26ef06321480e702770f88f61272be29 is not upstream. David --

If you introduce two pointers, 'siginfo_t __user *usiginfo' and 'unsigned long __user *datap' instead of just 'datap', you can use get_user/put_user everywhere, which would make the code better readable and faster. Otherwise this change looks good. Arnd --

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> --- arch/ia64/kernel/ptrace.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c index 7c7909f..8848f43 100644 --- a/arch/ia64/kernel/ptrace.c +++ ...

OK. Will combine those. BTW, one thing I wonder is it will have huge CC list of arch maintainers in commit message, so is it usual? or is there other way? -- Regards, Namhyung Kim --

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Haavard Skinnemoen <hskinnemoen@atmel.com> --- arch/avr32/kernel/ptrace.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/avr32/kernel/ptrace.c b/arch/avr32/kernel/ptrace.c index 5e73c25..ecea9b6 100644 --- a/arch/avr32/kernel/ptrace.c +++ b/arch/avr32/kernel/ptrace.c @@ -146,7 +146,8 ...

Despite I don't know how much it can run faster, I just want to keep it as is unless it would be a serious mistake. :-) -- Regards, Namhyung Kim --

Since user space API of ptrace syscall defines @addr and @data as void pointers, it would be more appropriate to define them as unsigned long in kernel. Therefore related functions are changed also. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Namhyung Kim <namhyung@gmail.com> --- include/linux/ptrace.h | 9 ++++++--- include/linux/syscalls.h | 3 ++- kernel/ptrace.c | 16 ++++++++++------ 3 files changed, 18 insertions(+), 10 deletions(-) diff --git ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: David Howells <dhowells@redhat.com> Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> --- arch/mn10300/kernel/ptrace.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/mn10300/kernel/ptrace.c b/arch/mn10300/kernel/ptrace.c index cf847da..4261810 100644 --- ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Chris Zankel <chris@zankel.net> --- arch/xtensa/kernel/ptrace.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/xtensa/kernel/ptrace.c b/arch/xtensa/kernel/ptrace.c index 9d4e1ce..af9ba80 100644 --- a/arch/xtensa/kernel/ptrace.c +++ b/arch/xtensa/kernel/ptrace.c @@ -256,7 +256,8 @@ ...

sounds like these changes should be squashed into one then -mike --

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Chris Metcalf <cmetcalf@tilera.com> --- arch/tile/kernel/ptrace.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c index 7161bd0..704bf11 100644 --- a/arch/tile/kernel/ptrace.c +++ b/arch/tile/kernel/ptrace.c @@ -64,7 +64,8 @@ ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] And removes unnecessary castings. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Chen Liqin <liqin.chen@sunplusct.com> Cc: Lennox Wu <lennox.wu@gmail.com> --- arch/score/kernel/ptrace.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/score/kernel/ptrace.c b/arch/score/kernel/ptrace.c index 174c642..5583618 100644 --- ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Greg Ungerer <gerg@uclinux.org> --- arch/m68knommu/kernel/ptrace.c | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/m68knommu/kernel/ptrace.c b/arch/m68knommu/kernel/ptrace.c index f6be124..835a3ed 100644 --- a/arch/m68knommu/kernel/ptrace.c +++ ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Jeff Dike <jdike@addtoit.com> --- arch/um/kernel/ptrace.c | 5 +++-- arch/um/sys-i386/ptrace.c | 4 ++-- arch/um/sys-x86_64/ptrace.c | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c index e051049..963d82b 100644 --- ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> --- arch/h8300/kernel/ptrace.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/h8300/kernel/ptrace.c b/arch/h8300/kernel/ptrace.c index df11412..23a95f84 100644 --- a/arch/h8300/kernel/ptrace.c +++ b/arch/h8300/kernel/ptrace.c @@ ...

change type of 'datap' variable into void pointer in order to remove unnecessary castings. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> --- arch/x86/kernel/ptrace.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index ea7766a..29c17610 100644 --- a/arch/x86/kernel/ptrace.c +++ ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Also fix misc bug on datap. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> --- arch/cris/arch-v10/kernel/ptrace.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/cris/arch-v10/kernel/ptrace.c b/arch/cris/arch-v10/kernel/ptrace.c index ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> --- arch/sparc/kernel/ptrace_32.c | 3 ++- arch/sparc/kernel/ptrace_64.c | 7 ++++--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/ptrace_32.c b/arch/sparc/kernel/ptrace_32.c index e608f39..e08ba4a 100644 --- ...

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> --- arch/mips/kernel/ptrace.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c index c51b95f..26c29dd 100644 --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -255,7 +255,8 @@ int ...

use new 'datap' variable type of void pointer in order to remove unnecessary castings. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> --- arch/avr32/kernel/ptrace.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/avr32/kernel/ptrace.c b/arch/avr32/kernel/ptrace.c index ecea9b6..4aedcab 100644 --- a/arch/avr32/kernel/ptrace.c +++ b/arch/avr32/kernel/ptrace.c @@ -150,6 +150,7 @@ long arch_ptrace(struct ...

factor out struct fps and remove redundant castings. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> --- arch/sparc/kernel/ptrace_32.c | 54 +++++++++++++++------------------------- arch/sparc/kernel/ptrace_64.c | 8 +++--- 2 files changed, 24 insertions(+), 38 deletions(-) diff --git a/arch/sparc/kernel/ptrace_32.c b/arch/sparc/kernel/ptrace_32.c index e08ba4a..27b9e93 100644 --- a/arch/sparc/kernel/ptrace_32.c +++ ...

use new 'datap' variable in order to remove unnecessary castings. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> --- arch/powerpc/kernel/ptrace.c | 55 +++++++++++++++++++++++------------------- 1 files changed, 30 insertions(+), 25 deletions(-) diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c index e4b6d75..0047bf9 100644 --- a/arch/powerpc/kernel/ptrace.c +++ ...

use new 'addrp' and 'datap' variables type of void pointer in order to remove unnecessary castings. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> --- arch/mips/kernel/ptrace.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c index 26c29dd..c0ab9d2 100644 --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -259,6 +259,8 @@ long ...

If patch 3 breaks all architectures, such that none of them then compile, this is bad. The fixes should be combined into that patch. If it breaks them such that there are warnings, but they still compile, we can probably live with that, but it's still icky. David --

Hello, This patchset tries to cleanup architecture independent/dependent part of ptrace syscall. Specifically it changes prototype of sys_ptrace() to have its arguments @addr and @data to be unsigned long. Since user space API of ptrace() declares them as void pointers, and most of archs consider them unsigned already in their arch_ptrace(), it would be no harmful to change them from (signed) long into unsigned long, IMHO. ptrace() code accesses user area using above arguments frequently, ...

No, not a mistake, your code is fine as it is and not performance critical at all. However, in general using get_user/put_user is preferred over copy_from_user/copy_to_user for scalar values. Arnd --

change type of @addr and @data into unsigned long according to commit f76671df26ef06321480e702770f88f61272be29 [PATCH 03/43] Signed-off-by: Namhyung Kim <namhyung@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> --- arch/alpha/kernel/ptrace.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/alpha/kernel/ptrace.c b/arch/alpha/kernel/ptrace.c index baa9036..e2af5eb ...

From: Adam Jiang <jiang.adam@gmail.com> Add stackoverflow detection to mips arch Signed-off-by: Adam Jiang <jiang.adam@gmail.com> --- arch/mips/Kconfig.debug | 9 +++++++++ arch/mips/kernel/irq.c | 21 +++++++++++++++++++++ 2 files changed, 30 insertions(+), 0 deletions(-) diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug index 43dc279..f437cd1 100644 --- a/arch/mips/Kconfig.debug +++ b/arch/mips/Kconfig.debug @@ -67,6 +67,15 @@ config CMDLINE_OVERRIDE ...

This is resend of a patch that was sent couple of days ago, but I got no response to it. No changes from previous version. --- binfmt_misc: Fix binfmt_misc priority Commit 74641f584da introduced a regression - binfmt_misc is now consulted after binfmt_elf, which will unfortunately break ia32el. ia32 ELF binaries on ia64 used to be matched using binfmt_misc and executed using wrapper. As 32bit binaries are now matched by binfmt_elf before bindmt_misc kicks in, the wrapper is ignored. The ...

Applied, thanks. -- Jean Delvare --

ac->inode is set to null in function ext4_mb_release_group_pa(), and then trace_ext4_mballoc_discard(ac) is called, the kernel will panic. BUG: unable to handle kernel NULL pointer dereference at 000000a4 IP: [<f87e1714>] ftrace_raw_event_ext4__mballoc+0x54/0xc0 [ext4] *pdpt = 0000000000abd001 *pde = 0000000000000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/system/cpu/cpu1/cache/index1/shared_cpu_map Modules linked in: autofs4 sunrpc p4_clockmod ip6t_REJECT nf_conntrack_ipv6 ...

Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk --

Hello, .36-rc2-git4 [ 51.940707] snapshot_ioctl: ioctl '80083307' is deprecated and will be removed soon, update your suspend-to-disk utilities [ 51.940719] Syncing filesystems ... acpi_ds_exec_end_op+0x9b/0x578 [ 54.494374] [<ffffffff81244e5d>] acpi_ps_parse_loop+0x88a/0xa55 [ 54.494380] [ ?arn+0xi_p.4 <f81c>th+00fx2>[493fpiva0x ] 34i_ct [ 54.494492] [<ffffffff810e993d>] sys_ioctl+0x51/0x74 [ 54.494498] [<ffffffff81002002>] system_call_fastpath+0x16/0x1b [ 54.494892] ...

From just looking at it: isn't this patch going to break compiling with CONFIG_K8_NB=n? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

--

On Thu, 26 Aug 2010 20:33:40 +0200 Hi Miklos, My first problem with this that there isn't nearly enough documentation. So I offer the following to fix this problem. Please correct anything that I got glaringly wrong. I don't claim it is at all complete, but touches on the things that I thought were interesting. NeilBrown Hybrid Union Filesystem ======================= This document describes a prototype for a new approach to providing union-filesystem functionality in ...

On Fri, 27 Aug 2010 10:47:39 +0200 I was wondering why you even bothered to fiddle st_ino. Given that lots of other things come from one fs or the other, having the merged directories appear to be from the upper filesystem doesn't seem like a problem. I don't But you never access the xattrs for the lower directory so that shouldn't matter. Have a union for the upper fs would certainly be sufficiently 'interesting' I actually think that your approach can work quite will with either ...

In each case, it appears that the NULL test is not necessary. In the first case, the function pl08x_fill_llis_for_desc is only called in a case where its argument is computed using container_of. In the second case, the function pl08x_tasklet is only used as the second argument of tasklet_init, from which its argument should be the third argument of tasklet_init. But that value is not NULL at the point of calling tasklet_init, in pl08x_dma_init_virtual_channels. The sematic patch that fixes ...

If the NULL test is necessary, the initialization involving a dereference of the tested value should be moved after the NULL test. The sematic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ type T; expression E; identifier i,fld; statement S; @@ - T i = E->fld; + T i; ... when != E when != i if (E == NULL) S + i = E->fld; // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- drivers/staging/tm6000/tm6000-alsa.c | 3 ...

That, I think, is an invalid assumption. congestion_wait is used in some places as a backoff mechanism that waits for some IO work to be done, with congestion disappearing being a indication that progress has been made and so we can retry sooner than the entire timeout. For example, if _xfs_buf_lookup_pages() fails to allocate page cache pages for a buffer, it will kick the xfsbufd to writeback dirty buffers (so they can be freed) and immediately enter congestion_wait(). If there isn't ...

From: Nicholas Bellinger <nab@linux-iscsi.org> This patch adds support for WriteCache emulation using a struct file backend. It also adds support for Forced Unit Access WRITE emulation, and using the TCM callers, can be configured independently via ConfigFS using generic device attributes added in commit ab60b29471. For the WriteCache bit, the fd_do_sync_cache() and fd_do_sync_cache_range() callers for SYNCHRONIZE_CACHE* ops have been added, which are called ...

From: Nicholas Bellinger <nab@linux-iscsi.org> This patch adds support for SYNCHRONIZE_CACHE and SYNCHRONIZE_CACHE_16 CDB emulation using a 32-bit and 64-bit Logical Block Address (LBA) and Number of Blocks Range (converted to bytes by TCM) on a per struct se_cmd + single struct se_task context basis into struct se_subsystem_api backstores based on the received LBA + Range using ->do_sync_cache() and ->do_sync_cache_range() API callers. It adds the the new ...

From: Nicholas Bellinger <nab@linux-iscsi.org> Greetings hch, tejun and Co, This patch series adds WriteCache + FUA Write emulation support into TCM v4 Core and ConfigFS generic code at lio-core-2.6.git/lio-4.0. The series changes the TCM subsystem plugin API at include/target/target_core_transport.h:struct se_subsystem_api that allows SYNCHRONIZE_CACHE emulation to be shared amoungst multiple TCM subsystem plugins (eg: FILEIO, IBLOCK, RAMDISK). This series includes initial support ...

Hello List： 　I have a problem with msgrcv(). I have used msgrcv() in my source to receive messages in a while(1). But it returned an error in errno 514(ERESTARTNOHAND). I search this error in net, and it seems to be should not happen in user program. But it happened in my program, and once only. I didn’t see it happens after that once. My question is how can I make this error happen again? And how can I fix it? I saw RedHat has fixed the problem, but no ...

http://rhn.redhat.com/errata/RHSA-2008-0612.html the website had list the src rpm name. kernel-2.6.18-92.1.10.el5.src.rpm -- Best Regards Lin --

nack. Change the name to system_bus_throughput_pm_qos assuming KBS units and I'll ok it. It needs to be portable and without units I think drivers will start using magic numbers that will break when you go from a devices with 16 to 32 bus with the same clock. We had an email thread about this last year http://lkml.org/lkml/2009/12/31/143 I don't recall solution ever coming out of it. I think you guys didn't like the idea of using units. Further I did post a patch adding something ...

Yeah, I'm planning on rounding up some MSM folks for LPC this year. Power is a big concern for us so it would be good to join the discussion. Initially, I was very keen on the per-device QoS contraints but I've since cooled on it. For our HW, there's not a generic unit that can convey enough data for us to act on. At least not w/o lookup tables, etc., at which point the unit loses it's value and becomes a generic handle. I'm looking forward to a good group discussion on this topic. ...

With this current design, only one system-wide bus would be managed. What if a platform has more than one independently scalable bus? I think the only scalable way to handle this kind of thing is to have per-device QoS constraints that can then be combined/aggregated by parent devices/busses. At LPC this year, I've proposed per-device QoS constraints[1] as a topic for the PM mini-conf. I hope some folks from the MSM camp can be there for these discussions. Kevin --

Hi Linus, Some regression fixes, a couple around the BKL removal, and one in the drm_mm code that was causing SIGBUS errors for some radeon users. Dave. The following changes since commit d03330383c9255cdb184dd33594e89c3542f191b: Merge remote branch 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next into drm-core-next (2010-08-23 08:34:59 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Adam Jackson ...

Applied, thanks. --

Hi all, Changes since 20100826: The ceph tree lost its conflict. The jdelvare-hwmon tree lost its conflict. The net tree lost its build failure but gained another so I used the version from next-20100826 with the 2 commits reverted still. The drivers-x86 tree lost its conflict. A added a patch for a boot failure on PowerPC. ---------------------------------------------------------------------------- I have created today's linux-next tree ...

Oh Lordy. I should stop merging anything that contains "select". I'll take a look at this tomorrow, but I'm about to head away for a week - if anyone has a fix, feel free to find a way to get it merged. (Dmitry, there was a Kconfig issue when I merged your patch, so it's entirely plausible that you're a completely innocent bystander here) -- Matthew Garrett | mjg59@srcf.ucam.org --

Add missing consts to the sys_execve() declaration which result in the following error: arch/sh/kernel/process_32.c:303: error: conflicting types for 'sys_execve' /warthog/nfs/linux-2.6-fscache/arch/sh/include/asm/syscalls_32.h:24: error: previous declaration of 'sys_execve' was here Signed-off-by: David Howells <dhowells@redhat.com> --- arch/sh/include/asm/syscalls_32.h | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/sh/include/asm/syscalls_32.h ...

--- arch/h8300/include/asm/irqflags.h | 43 +++++++++++++++++++++++++++++++++++++ arch/h8300/include/asm/system.h | 24 +-------------------- 2 files changed, 44 insertions(+), 23 deletions(-) create mode 100644 arch/h8300/include/asm/irqflags.h diff --git a/arch/h8300/include/asm/irqflags.h b/arch/h8300/include/asm/irqflags.h new file mode 100644 index 0000000..9617cd5 --- /dev/null +++ b/arch/h8300/include/asm/irqflags.h @@ -0,0 +1,43 @@ +#ifndef _H8300_IRQFLAGS_H +#define ...

--- arch/parisc/include/asm/irqflags.h | 46 ++++++++++++++++++++++++++++++++++++ arch/parisc/include/asm/system.h | 19 +-------------- 2 files changed, 47 insertions(+), 18 deletions(-) create mode 100644 arch/parisc/include/asm/irqflags.h diff --git a/arch/parisc/include/asm/irqflags.h b/arch/parisc/include/asm/irqflags.h new file mode 100644 index 0000000..40442a1 --- /dev/null +++ b/arch/parisc/include/asm/irqflags.h @@ -0,0 +1,46 @@ +#ifndef __PARISC_IRQFLAGS_H +#define ...

--- arch/mips/include/asm/irqflags.h | 53 +++++++++++++++++++++----------------- 1 files changed, 29 insertions(+), 24 deletions(-) diff --git a/arch/mips/include/asm/irqflags.h b/arch/mips/include/asm/irqflags.h index 701ec0b..9ef3b0d 100644 --- a/arch/mips/include/asm/irqflags.h +++ b/arch/mips/include/asm/irqflags.h @@ -17,7 +17,7 @@ #include <asm/hazards.h> __asm__( - " .macro raw_local_irq_enable \n" + " .macro arch_local_irq_enable \n" " .set push \n" ...

--- arch/sh/kernel/irq_32.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/sh/kernel/irq_32.c b/arch/sh/kernel/irq_32.c index e33ab15..14d2477 100644 --- a/arch/sh/kernel/irq_32.c +++ b/arch/sh/kernel/irq_32.c @@ -10,7 +10,7 @@ #include <linux/irqflags.h> #include <linux/module.h> -void notrace raw_local_irq_restore(unsigned long flags) +void notrace arch_local_irq_restore(unsigned long flags) { unsigned long __dummy0, __dummy1; @@ ...

Split the PLL control code from the Blackfin machine-specific cdef headers so that the irqflags functions can be renamed without incurring a header loop. Signed-off-by: David Howells <dhowells@redhat.com> --- .../mach-bf518/include/mach/cdefBF51x_base.h | 50 -------------- arch/blackfin/mach-bf518/include/mach/pll.h | 63 ++++++++++++++++++ .../mach-bf527/include/mach/cdefBF52x_base.h | 50 -------------- arch/blackfin/mach-bf527/include/mach/pll.h | 63 ...

Rename the PC2() symbol in the generic DES crypto module to be prefixed with DES_ to avoid collision with arch code (Blackfin in this case). Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> --- crypto/des_generic.c | 130 +++++++++++++++++++++++++------------------------- 1 files changed, 65 insertions(+), 65 deletions(-) diff --git a/crypto/des_generic.c b/crypto/des_generic.c index 249f903..873818d 100644 --- ...

Fix the IRQ flag handling naming. In linux/irqflags.h under one configuration, it maps: local_irq_enable() -> raw_local_irq_enable() local_irq_disable() -> raw_local_irq_disable() local_irq_save() -> raw_local_irq_save() ... and under the other configuration, it maps: raw_local_irq_enable() -> local_irq_enable() raw_local_irq_disable() -> local_irq_disable() raw_local_irq_save() -> local_irq_save() ... This is quite confusing. There should be one set of names expected of ...

Add a missing dependency (mach/blackfin.h) to asm/irqflags.h so that bfin_read_IMASK() can be used by inline functions. Signed-off-by: David Howells <dhowells@redhat.com> --- arch/blackfin/include/asm/irqflags.h | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/include/asm/irqflags.h b/arch/blackfin/include/asm/irqflags.h index 813a1af..f3ed931 100644 --- a/arch/blackfin/include/asm/irqflags.h +++ b/arch/blackfin/include/asm/irqflags.h @@ -8,6 ...

--- arch/ia64/include/asm/irqflags.h | 94 ++++++++++++++++++++++++++++++++++++++ arch/ia64/include/asm/system.h | 76 ------------------------------- 2 files changed, 94 insertions(+), 76 deletions(-) create mode 100644 arch/ia64/include/asm/irqflags.h diff --git a/arch/ia64/include/asm/irqflags.h b/arch/ia64/include/asm/irqflags.h new file mode 100644 index 0000000..f82d6be --- /dev/null +++ b/arch/ia64/include/asm/irqflags.h @@ -0,0 +1,94 @@ +/* + * IRQ flags defines. + ...

--- arch/powerpc/include/asm/hw_irq.h | 115 +++++++++++++++++++--------------- arch/powerpc/include/asm/irqflags.h | 2 - arch/powerpc/kernel/exceptions-64s.S | 4 + arch/powerpc/kernel/irq.c | 4 + 4 files changed, 69 insertions(+), 56 deletions(-) diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h index bd100fc..4255de6 100644 --- a/arch/powerpc/include/asm/hw_irq.h +++ b/arch/powerpc/include/asm/hw_irq.h @@ -16,42 +16,57 @@ ...

Split the BF532 machine type BFIN_*_FIO_FLAG() functions to their own header file to avoid circular #include problems as these functions require IRQ flag handling, which requires asm/blackfin.h, which otherwise requires the header file that defines these functions. For good measure, also get rid of the inclusion of asm/blackfin.h from mach/cdefBF532.h (which is circular) and defBF532.h (which is included by asm/blackfin.h before including this header). Signed-off-by: David Howells ...

This is due to commit 5a652052fedbd7869572c757dd2ffc2ed420c69d Author: Maxime Bizon <mbizon@freebox.fr> Date: Wed Jul 21 17:21:38 2010 +0200 cfg80211: fix race between sysfs and cfg80211 The rfkill registration needs to be done after dropping all locks in wiphy_register(). Maxime, can you please look at fixing this? [full lockdep report preserved below] johannes --

Hi all, After merging the nert tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/stmmac/stmmac_timer.c: In function 'stmmac_open_ext_timer': drivers/net/stmmac/stmmac_timer.c:60: error: 'CONFIG_RTC_HCTOSYS_DEVICE' undeclared (first use in this function) Maybe exposed by commit ac75791aa943c7953521cb4fa7728bf51f9abd2d ("stmmac: remove dead option in the driver's Kconfig") since presumably we used to not build this driver. I have used the net tree from ...

This patch is an enhanced version of Takashi Iwai's [PATCH] hp_accel: Add quirks for HP ProBook 532x and HP Mini 5102 My HP Mini 5101 works fine with this patch. Confirmed with Tux Racer. Signed-off by: Masanari Iida <standby24x7@gmail.com> diff --git a/drivers/hwmon/hp_accel.c b/drivers/hwmon/hp_accel.c index 36e9575..c5cd3db 100644 --- a/drivers/hwmon/hp_accel.c +++ b/drivers/hwmon/hp_accel.c @@ -222,7 +222,7 @@ static struct dmi_system_id lis3lv02d_dmi_ids[] = { ...

True. I also wanted it but we have to care swap configured but non-enabling still yet system as well as non-swap configured system at that time. If your system is no swap configured, how about this? (It's a not formal proper patch but just quick patch to show the concept). diff --git a/mm/vmscan.c b/mm/vmscan.c index 3109ff7..641c6a6 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1580,6 +1580,11 @@ static void shrink_active_list(unsigned long nr_pages, struct zone *zone, ...

We found the problem on one of our workloads where more TLB flush happens without the change. Kswapd seems to be calling shrink_active_list() which eventually clears access bit of those ptes and does TLB flush with ptep_clear_flush_young(). This system does not have swap configured, and why aging the anon lru in that Lots of TLB flush hurts the performance especially on large smp system. So does it make sense if change it to: + if (nr_swap_pages == 0) + return 0; --

diff --git a/Makefile b/Makefile index 10c5a85..e821f72 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 34 -EXTRAVERSION = .5 +EXTRAVERSION = .6 NAME = Sheep on Meth # *DOCUMENTATION* diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h index 9dcb11e..bf62c44 100644 --- a/arch/arm/include/asm/ptrace.h +++ b/arch/arm/include/asm/ptrace.h @@ -158,15 +158,24 @@ struct pt_regs { */ static inline int ...

diff --git a/Makefile b/Makefile index 554683d..73ab033 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 35 -EXTRAVERSION = .3 +EXTRAVERSION = .4 NAME = Sheep on Meth # *DOCUMENTATION* diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h index 9dcb11e..bf62c44 100644 --- a/arch/arm/include/asm/ptrace.h +++ b/arch/arm/include/asm/ptrace.h @@ -158,15 +158,24 @@ struct pt_regs { */ static inline int ...

How can I know if this laptop is broken or not? According to Jesse's reply, the BIOS lowered the limit, which could explain why it hits the limit more often: intel ips 0000:00:1f.6: Warning: CPU TDP doesn't match expected value (found 25, expected 35) The thermal throttling seems to be also managed by the BIOS (and there are no settings about it on the BIOS setup that I remember): CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 9 MCE banks CPU0: Thermal ...

Perhaps you might try this patch and get a bit more information. It seems a sensible patch and perhaps should be applied anyway. Signed-off-by: Joe Perches <joe@perches.com> --- drivers/platform/x86/intel_ips.c | 58 +++++++++++++++++++++++++++++-------- 1 files changed, 45 insertions(+), 13 deletions(-) diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c index 9024480..73f9ad1 100644 --- a/drivers/platform/x86/intel_ips.c +++ ...

Running with it right now, did not help much: $ dmesg | fgrep 'intel ips' intel ips 0000:00:1f.6: Warning: CPU TDP doesn't match expected value (found 25, expected 35) intel ips 0000:00:1f.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18 intel ips 0000:00:1f.6: IPS driver initialized, MCP temp limit 65535 intel ips 0000:00:1f.6: MCP power limit 65535 exceeded: cpu:8058 + mch:23392829 intel ips 0000:00:1f.6: CPU power limit 0 exceeded: 5675 intel ips 0000:00:1f.6: CPU power limit 0 exceeded: ...

The basic GPIO controllers may be found in various on-board FPGA and ASIC solutions that are used to control board's switches, LEDs, chip-selects, Ethernet/USB PHY power, etc. Usually these controllers do not privide any means of pin setup (in/out/open drain). The driver provides: - Support for 8/16/32/64 bits registers; - Support for GPIO controllers with clear/set registers; - Support for GPIO controllers with a single "data" register; - Support for big endian bits/GPIOs ordering (mostly ...

Fixed, thanks for your bug report. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com --

Yes, thanks! I'll run the test program again before resubmitting. :) -VAL --

Could we split this patch in 2 for better review? One that only moves the code and a 2nd that changes it. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center --

We need empty function stubs for all this functions for the !CONFIG_PERF_EVENTS case returning -ENODEV or so. Otherwise compliation will fail for it. For arm this does not happen because of #ifdefs, but for sh. Again, please first change the code and then move it without functional changes, one patch each. Thanks, -- Advanced Micro Devices, Inc. Operating System Research Center --

Initialization should simply fail with a printk message for this case, implement function stubs for the !CONFIG_PERF_EVENTS case instead in I don't see a reason why this must be included here. It's only for sh_pmu_name() and sh_pmu_num_events(), so the interface looks wrong here. It should be in oprofile_perf.c. The functions With that implementation we always have to touch the code for new cpus. Maybe we derive it from the perf name, e.g. making all lowercase Instead of exporting all ...

This probably needs EXPORT_SYMBOLS*(), but not really sure. Have you compiled oprofile as module? This accessor functions should be generic for all architectures. -- Advanced Micro Devices, Inc. Operating System Research Center --

Hi Robert, I took a look through all of the oprofile_arch_{init,exit} functions and it looks like only ARM needs fixing. Nobody else does any allocation How about something like this? This removes the exit call from the init code and sets pointers to NULL after they have been freed. We still have to do some checking so that we don't try to release a NULL perf event: diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c index 0691176..12253eb 100644 --- ...

The root cause that makes this check necessary is that oprofile_arch_exit() is called though oprofile_arch_init() failed. We should better fix this instead. I have to admit we will then have to We should not return from oprofile_arch_init() with allocated resources if the function fails. To fix duplicate kfrees, we should free it here and then set counter_config to NULL. It should also be freed if for_each_possible_cpu() or op_name_from_perf_id() fails. Also, the pointer should be NULLed ...

Looks good to me know, the code is a lot easier. Please send me a final version. I'm going to apply it on Monday. Thanks Will, -- Advanced Micro Devices, Inc. Operating System Research Center --

For reference, union mounts needs something like this. The current patch set creates a inode_permission() variant for use in the VFS in cases where we may copy up. The superblock of the target is read-only and we have to ignore that - if the topmost parent directory is unioned. Here's the patch, which I suspect needs to be rewritten: commit 72a84672ccf2a923bac120e3ac75ac106d36b4ae Author: Valerie Aurora <vaurora@redhat.com> Date: Sat Mar 20 17:34:53 2010 -0700 VFS: Split ...

You're correct I missed the line where that was being pulled out of the dentry. The better question for me would be why do it this way as opposed to what the union file systems are doing. If neither UnionFS or AUFS are having to make this change so I'd like a much better explination for this change. I'm not seeing enough information in the form of why he designed the prototype this way to justify a change that the other implementations don't seem to need. Dave --

The problem with allowing concurrency is that the moment you want to do that you get the spawner context and error propagation problems. Thus we're limited to spawning a single thread at timer_create() and handling expirations in there. At that point you have to specify what happens to an expiration while the handler is running, will it queue handlers or will you have to carefully craft your handler using timer_getoverrun(). But I really don't understand why POSIX would provide this ...

Why should a single timer fork many threads? Just because a previous thread did not complete before the timer fires again? That's braindamage as all threads call the same function which then needs to be serialized anyway. We really do not need a function which creates tons of threads which get all stuck on the same resource. Thanks, tglx --

The risk is that you end up with always using next-buddy, and we tried that a while back and that didn't work well for some, Mike might remember. Also, when you use timers things like time-outs you really couldn't care less if its handled sooner rather than later. Disk is usually so slow you really don't want to consider it interactive, but then sometimes you might,.. its a really hard problem. The only clear situation is the direct input, that's a direct link between the user and our ...

It could make sense if the workload is mostly CPU-bound and there is only a very short critical section shared between the threads. But I agree that in many cases this will generate an utter contention mess. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com --

I turned it off because it was ripping spread apart badly, and last Yeah, directly linked wakeups using next could be a good thing, but the trouble with using any linkage to the user is that you have to pass it on to reap benefit.. so when do you disconnect? -Mike --

Maybe with the dyn min_vruntime feature proposed in this patchset we should Maybe we could have a timer delay threshold under which we consider the wakeup to be "short" or "long". e.g. a timer firing every ms is very likely to need its wakups to proceed quickly, but if the timer fires every hours, we could not care What we do here is that we pass it on across wakeups, but not across wakups of new threads (so it's not passed across forks). However, AFAIU, this only generates a bias that will ...

Besides pthread_attr_t, thinking of the scheduler/cgroups/etc stuff, I'd think it might be expected to inherit the state of the thread which calls timer_create(). But this is not what glibc does right now, and it is not spelled Why should it ? It seems valid for a workload to result in spawning many threads bound to more than a single core on a multi-core system. So concurrency Setting a thread stack and generating the signal more than once is taken into account in the standard. It leads ...

Hello, Please don't hide scheduler improvements behind obscure CONFIG_SCHED_DEBUG options. If it doesn't make the scheduler better just don't merge it. If it does then it should be enabled by default. Thank you, Indan P.S. Tony Luck seems to be chopped of the CC list. --

That would be a massive resource waste for the normal case where the interval > handler runtime. --

From man timer_create: SIGEV_THREAD Upon timer expiration, invoke sigev_notify_function as if it were the start function of a new thread. (Among the implementa‐ tion possibilities here are that each timer notification could result in the creation of a new thread, or that a single thread is created to receive all notifications.) The function is invoked with sigev_value as its ...

These are problems you get only when you allow spawning any number of threads. If, instead, you create a thread pool at timer creation, then you can allow With my statement above in mind, it's true that we'd have to handle what happens when the thread pool is exhausted. But couldn't we simply increment an overrun counter from userland ? (It might be a different counter than kernel space kept Higher abstraction API vs low-level control. A long running battle. ;) Thanks, Mathieu -- ...

That does not change my opinion on that much. As I said before I strongly object to implement special handling for a particular wakeup scenario as this will open a can of worms for all other special cases and workloads. Thanks, tglx --

Appreciated - thanks! Sam --

Sure. Will provide one and also explain the other sections that I am familiar with. Thanks for your feedback! --

Yeah the stupid sleeping feels wrong. However there are ~20 congestion_wait() callers spread randomly in VM, FS and block drivers. Many of them may be added by rule of thumb, however what if some of them happen to depend on the old stupid sleeping behavior? Obviously you've done extensive tests on the page reclaim paths, however that's far from enough to cover the wider changes made by this patch. We may have to do the conversions case by case. Converting to congestion_wait_check() (see ...

I am taking this direction now. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

No, I mean do not change the too_many_isolated() related code at all :) And to use congestion_wait_check() in other places that we can prove there is a problem that can be rightly fixed by changing to Thanks, Fengguang --

I always suffer from understanding your comment. Apparently, my eyes have a problem. ;( This patch is dependent of Mel's series. With changing congestion_wait with just return when no congestion, it would have CPU hogging in too_many_isolated. I think it would apply in Li's congestion_wait_check, too. If no change is current congestion_wait, we doesn't need this patch. Still, maybe I can't understand your comment. Sorry. -- Kind regards, Minchan Kim --

This is what I've done. I dropped the patch again and am using wait_iff_congested(). I left the too_many_isolated() callers as congestion_wait(). -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Hello, But we have sg_mark_end(&sgl[nents-1]) in sg_init_table(). I think explicit end marking in __sg_alloc_table() is redundant. Thanks. -- tejun --

Well the problem we were seeing manifested itself when we called free_fn on a NULL value. This was a naive attempt at avoiding that. If the logic in __sg_alloc_table is corrected, I agree that we shouldn't You are right about prv possibly being NULL here. Sorry for not catching that earlier; however, I don't think prv will be marked as an end in the previous iteration. According to my read it will only get marked if left is equal to 0, in which case the while loop exits. Perhaps something ...

On Fri, 27 Aug 2010 11:35:06 +0900 Thank you very much for your information. Some questions. Is "tmpfile" created on a normal filesystem(e.g. ext3) or tmpfs ? And, how long does it likely to take to cause this problem ? I've run it on RHEL6-based kernel/ext3 for about one hour, but I cannot reproduce it yet. Thanks, Daisuke Nishimura. --

On Fri, 27 Aug 2010 12:39:48 +0900 Hmm...I'll dig more. Maybe I need to use stock kernel rather than -mm... Thanks, -Kame --

Hi. On Thu, 26 Aug 2010 16:51:55 +0100 (BST) The commit had caused a bug about rmdir, but it was fixed by the commit 88703267. What cgroup subsystem did you mount where the directory existed you tried to rmdir() first ? If you mounted several subsystems on the same hierarchy, can you mount them separately to narrow down the cause ? Thanks, Daisuke Nishimura. --

Much better, thank you. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

Hi Guenter, So far, most hwmon driver authors decided to ignore such errors, or limited their handling to logging the issue, mainly because the caching mechanism makes handling of such errors tough. Now I admit that the approach you took in the jc42 driver is interesting. I never considered having a single error value being returned by the update function the way you did. This has the obvious drawback that transient I/O errors cause _all_ sensor values to be unavailable, which is ...

Good point, I had missed this implementation detail. But this cuts both ways: if there are too many transient errors (like the W83L785TS-S had) the update function may keep failing forever, even though each value In all honesty, I can't remember any such device. In general, failing sensors are reported through data flags, not low-level errors. The only two drivers I know which needed special error handling are w83l785ts and thinkpad_acpi - the latter isn't I2C-based so there's no register I ...

cat /sys/kernel/todo cat /sys/module/*/todo -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

If this is the case, we already have queue congested. removing congestion_wait() might cause regression but either your change or the congestion_wait_check() should not have the regression, as we do check if the bdi is congested. Thanks, Shaohua --

Then waiting on congestion was the totally wrong thing to do. We were effectively calling sleep(HZ/10) and magically this was helping in some undefined manner. Do you know *which* called of congestion_wait() was What were the results? I'm preparing a full series incorporating a Do you know why because leaving in random sleeps() hardly seems to be Probably because it was scanning more but not finding what it needed. There is a condition other than congestion it is having trouble with. ...

this guy: http://git.kernel.org/?p=linux/kernel/git/vapier/blackfin.git;a=commitdiff;h=8e289204d... -mike --

hello Peter, Thanks for your patch, but I still could reproduce the problem with your patch. Thanks, --

Hi Peter, Thanks for you take care of it, I have got the root cause of it now. It is the kgdb using hw_breakpoint_layer's API problem, and I have a RFC patch for it.(maybe it is not correctly), I will contact with Jason to fix this problem. Thank you very much, --

You say you're booting -git4 but you're running kernel is Linux next from Aug. 26th Can you confirm you see this boot failure with Linus's tree NOT linux next? Adding linux-ppc and linux-next lists. Yours Tony --

This will fix your problem: http://patchwork.ozlabs.org/patch/62757/ Please CC linuxppc-dev@ozlabs.org for pwoerpc bug reports. ) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu .2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu Aug 26 10:55:01 I --

Not at all! My laptop had been recently booted (see the timings in the dmesg) and it was basically idle: just a couple xterms and WindowMaker running, Could it be that the memory card had some bad block and btrfs could not recover from the failure? --

That's exactly correct, I thought it prevented reuse of the slab entry, not only of the whole slab... SLAB_DESTROY_BY_RCU is a lot more tricky to use than I though... However at the light of this, I think page_lock_anon_vma could have returned a freed and reused anon_vma well before the anon-vma changes. The anon_vma could have been freed after the first page_mapped check succeed but before taking the spinlock. I think, it worked fine because the rmap walks are robust enough just not to ...

No. Between rcu_read_lock and rcu_read_unlock, once we've done the first (original) page_mapped test to make sure that this isn't just a long-stale page->mapping left over in there, SLAB_DESTROY_BY_RCU ensures that the slab page on which this "struct anon_vma" resides cannot be freed and reused for some other purpose e.g. a page of user data. But that piece of slab holding this "struct anon_vma" is liable to be freed and reused for another struct anon_vma at any point, until Yes, but RCU is ...

rmap_walk_anon isn't stable without the anon_vma->root->lock. This is because it only locks the local anon_vma and but the "vma" can be still modified under it in vma_adjust, so vma_address can fail and migration will crash. swapping is not issue as it's ok to miss a pte once in a while if the vma is under vma_adjust by the time the VM tries to unmap the page. See the anon_vma_lock added as well to vma_adjust (without it, it'd be just an useless exercise, but instead it's really plugging a ...

I do not see any check after we have taken the lock to verify that we You then are using an object from the anon_vma (the pointer) without a lock! This is unstable therefore unless there are other constraints. The anon_vma->lock must be taken before derefencing that pointer. The page may have been unmapped and mapped again between the two checks. Unlikely but I do not see a second check (*after* taking the lock) in the patch and the way the lock is taken can be a problem in itself. --

Argh. Right. Looked like a global to me. Did not see the earlier local def. If you still use a pointer then what does insure that the root pointer was not changed after the ACCESS_ONCE? The free semantics of an anon_vma? Since there is no lock taken before the mapped check none of the earlier reads from the anon vma structure nor the page mapped check necessarily reflect a single state of the anon_vma. --

No second version of the patch, no. As I said already, it's that second page_mapped check which gives the guarantee that the anon_vma Yes, unlikely but possible. (Well, actually, is it possible? It can be unmapped on exit without any lock, but unmapping for pageout would require the page lock, would insert a swp_entry_t, and mapping again would go to do_swap_page which would again require the page lock. But never mind that, let's assume there is a way it can be unmapped and mapped ...

The version field of the input_id struct is a 16-bit number that can be used to code device-specific version information, and is retrievable via EVIOCGID. Perhaps one could code the firmware version in there. Henrik --

If this sysfs node should really be added (see EVIO), it is probably better if it returns the same format for all devices. If all numbers are zero, that is Henrik --

This is incomplete. Error handling in this function is totally broken. -- Jean Delvare --

--

No the groups are used for increasingly larger accumulations of cpus, the first group is the singleton group which contains on the one cpu in question, after that we start following the machine topology, hyper-threads, multi-core, package, node etc. until the last group spans the whole machine. The dynamic cpu_power computation comes from RT tasks, when we load-balance SCHED_OTHER tasks, we want each cpu to have an equal amount of pending work, however when one CPU is say 50% busy with RT ...

There's a large three lettered company that's promoting cpu hotplug use for power management, they hotplug at an astonishing rate. I've been saying hotplug isn't for that, and its a terrible slow path and disrupts your whole machine etc.. they don't seem to care much. The trouble seems to be that some smaller chips are now also wanting to use hotplug for PM because they want to safe silicon and not make their chips symmetric or crap like that... Its all really sad, and I'd prefer to keep ...

I have tested this patch on a 16cpus Netburst server. The predefined hardware/cache events work well. Thanks, --

An update: I've set up an ext4 barrier testing in KVM - run fsstress, kill KVM at some random moment and check that the filesystem is consistent (kvm is run in cache=writeback mode to simulate disk cache). About 70 runs without journal_async_commit passed fine, now I'm running some tests with the option enabled and the first few rounds passed OK as well. Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

Introduces -S/--show_functions option for perf-probe. This lists function names in a File. If no file is specified, then lists functions in the current running kernel. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> --- Changelog from V11: accomodate name change dso_fprintf_symbols_by_name. Changelog from V10: As suggested by Arnaldo, filtering is now based on sym.binding. Changelog from V9: Filter labels, weak, and local binding functions from listing as suggested by ...

Wouldnt it negate the purpose of common knob? Because people would still have go and select UPROBE_EVENTS, I think when Frederic asked for a common knob, he was looking at enabling both or disabling both and an option to selectively select one of the tracers. -- Thanks and Regards Srikar --

Hmm, I think this just seems an enhancement of dynamic events, and also you can enable it by default on some point. I mean, eventually, there will be only "Enable dynamic events" Yeah, but I'd like to ask Frederic that he expected disabling KPROBE_EVENT by default too, even though it changes current default config. Thank you, --

Hello... -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

-- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --

It may be better to move the generic __v7_setup here and have a specific entry for ARM Ltd cores (mask 0xff0f0000 and value 0x410f0000). In general, I would have liked a different way (still ID-based) of handling such issues without duplicating the whole structure. But I see this becoming the standard as proc-v6.S follows it as well. -- Catalin --

So my opinion is to not add any specific msm code but make the __v7_setup skip the ACTLR bit setting. Then add an entry for Cortex-A9 Maybe they don't do anything with those bits and writing to them is harmless. They'll complain if their code stops working but it is usually unlikely that people implementing their own v7MP would use the same bits in ACTLR as Cortex-A9. I'm not sure whether someone licensing and manufacturing a Cortex-A9 would use the same manufacturer id (TI folks would know ...

The SMP/nAMP bit is something specific to the ARM11MPCore and Cortex-A9 processors produced by ARM. If you core doesn't need this, it should use a default __v7_setup without any additional bits being set. I'm not aware of other MP ARM processors produced by other companies Yes, I know and I'm not saying that you should change it in this patch. It's just that I would have liked to only duplicate the setup function rather than the whole procinfo structure. -- Catalin --

On Thu, 26 Aug 2010 20:29:01 -0300 It's not the kind of thing you want to quieten since in most cases it is Probably better to ratelimit it. Being told it occurs is important, being told every five seconds is indeed excessive. Alan --

I liked this version until I realized that userspace doesn't have aligned_u64 as a valid type. I'm feeling more like my old version of the patch. Anyone have thoughts or comments? -Eric --

GPL, please... and spread the news to the codeaurora people so we don't get this over and over and over again. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

This is a rather bizarre argument as because of this situation 1) the code is duplicated between the initramfs and the real disk 2) the initramfs has to be rebuild each time a new kernel is done 3) The tmpdevfs is also a dupplicate somehow Never mind. -- eric --

From: Stephen Hemminger <shemminger@vyatta.com> Agreed, this problem is in the infiniband layer and should be fixed there. But I fear there is a real potential blocker for this, if the infiniband layer can't checksum transmit packets in hardware we cannot legitimately add SG support. Paged SKBs can have references to page cache pages and similar. These can be updated asynchronously to the transmit, there is no locking at all to freeze the contents, and therefore full checksum offload ...

> Infiniband device driver needs to be fixed to do SG and checksum offload. > Otherwise it is insane to try and run large MTU over it. I even wonder if > the dev_change_mtu() function should reject > PAGESIZE mtu for devices > that don't do scatter/gather or at least a raise a warning. It's not possible to "fix" the driver to do checksum offload, since the underlying hardware does not support it. Theoretically we could handle SG but of course there's no point in that without checksum ...

MEIF is a Nokia proprietary protocol. The link above points to a page, which describes how you can get hold of the MEIF specification. Regards, --

Personally I'd add the new clock_adjtime interface, since it parallels the gettimeofday/clock_gettime() interface levels. Trying to multiplex This in most ways makes the most sense to me, since if CLOCK_REALTIME is But yes, this is another possibly valid interpretation. I don't prefer this one, but that doesn't make it invalid. And so with the new interface, and the possibility of multiple non-synced clocks, there are Not exactly. Its abstracted out a step. MONOTONIC_RAW was added as ...

Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk --

From: Jason Baron <jbaron@redhat.com> Add a workqueue chapter to the traceopint docbook. Current book is at: http://www.kernel.org/doc/htmldocs/tracepoint/ Signed-off-by: Jason Baron <jbaron@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org> --- Applied w/ patch description update. Thanks. Documentation/DocBook/tracepoint.tmpl | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/tracepoint.tmpl ...

I found the problem: in ata_sff_pio_stack: struct ata_queued_cmd *qc = ap->port_task_data; has been replaced by: /* qc can be NULL if timeout occurred */ qc = ata_qc_from_tag(ap, ap->link.active_tag); if (!qc) return; That does not work in case of port multipler, because the link to look at is not ap->link. ap->link.active_tag is ATA_POISON. I will submit a patch where I re-introduce port_task_data, this time containing the link to to look at. Gwendal. --

Huh. hpet was not what I would have expected. So first, two experiments: 1) Does booting with "clock=acpi_pm" cause the issue to disappear? 2) Does booting with "nohz=off" cause the issue to disappear? Venkatesh: You have any experience with HPETs that halt in idle? thanks -john --

Yes, this would be the best workaround for cpus where the detection logic does not work properly. But I think Don found a solution already. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center --

It seems to be the same counter. I wonder if the act of processing it 'intel_save_and_restart' cleared the status bit on the perfselX bit but not in the global status register. Thus it triggered again and we accidentally cleared it when we ack'd later in the code. Cheers, Don --

Yes, this just throws away all unknown nmis after a perf nmi. It disables unknown nmi detection on this cpu type. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center --

The status masks seem to be identical, 0x1 (and when I forced pmc0 Heh. Not sure why it isn't working then. Then again you shouldn't need It would be a nice to have that way we wouldn't have to 'eat' all these extra nmis. But I guess it isn't working correctly. Cheers, Don --

Yeah, I can do that. The other patch was just a proof of concept to see what others thought. What is funny is that this problem was masked by the perf_event_nmi_handler swallowing all the nmis. I wonder if we were losing events as a result of this bug too because if you think about it, we processed the first event, a second event came in and we accidentally ack'd it, thus dropping it on the floor. Now I wonder how the event was ever reloaded, unless it was by accident because of how the ...

Can you resend all three updated patches? Thanks Yinghai --

I'm not sure what you mean by "natural alignment". If 1M alignment of a 64K buffer is natural then yes, presented API requires alignment to be natural. In short, alignment must be a power of two and is never less then a PAGE_SIZE but can be more Yes. I hope to came up with a CMA version that will allow reserved spec to be reused by the rest of memory management code. For now, I won't respond to your suggestions regarding the use of page allocator but I hope to write something later today ...

The side effect of increasing MAX_ORDER is that page allocations get more expensive since the buddy tree gets larger, yielding more Right, once we can explicitly free the pages we want, crossing MAX_ORDER isn't too hard like you say, we can simply continue with freeing the next in order page. --

Yes, we should probably change the name before making this an actual kernel API, John made some better suggestions. For kvm-kmod, the following conversion should work: static inline u64 get_kernel_ns(void) { struct timespec ts; WARN_ON(preemptible()); ktime_get_ts(&ts); monotonic_to_bootbased(&ts); return timespec_to_ns(&ts); } The only real point to getnsboottime is to stop the unnecessary conversions, but looking at it now, it doesn't appear to actually ...

Prior to the x86_64 / i386 merge, CPU_STARTING didn't work the same way / exist in the x86_64 code... most of this is historical guesswork. At some point, the 32/64 versions of the code in smpboot.c got merged and now it does. Binary searching around my tree shows this timeframe: 2.6.11? - 2.6.23 : silver age ; i386 and x86_64 merge underway | 2.6.24 : bronze age ; i386 and x86_64 deprecated | 2.6.26 : iron age; smpboot_32.c / smpboot_64.c merge \ 2.6.28 : ...

It just dawned on me where we are going to have problems. We have things other than syscall filter rules that can cause us to want the collected audit info. Namely SELinux (or other LSM) denials. Crap. So the change in audit_alloc() should probably be conditionalized on more than just audit_n_rules(). Not exactly sure what that is though. It might also make our syscall entry/exit speedups not as great of an idea as I thought. I need to look for other audit users to see how these ...

Hello, So you suggest to revert 309caa9cc6ff39d261264ec4ff10e29489afc8f8 or at least restrict it to ARMv6+ and fix the problem during the next merge window? Russell? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --

Hello, In my case the machine in question is an ARMv5, the hardware restriction is on ARMv6+ only. You could argue that so the breaking patch for arm should only break ARMv6, but I don't think this is sensible from a maintainers POV. We need an API that works independant of the machine that runs the code. And it's good to let developers that don't have the full range of machines supported by the kernel at hand notice when they introduce an incompatibility. Best regards Uwe -- ...

Hey, I think this isn't about "responsiblity". Someone in arm-land found that the way dma memory allocation worked for some time doesn't work anymore on new generation chips. As pointing out this problem was expected to find some matches it was merged in the merge window. One such match is the current usage of the DMA API that doesn't currently offer a way to do it right, so it needs a patch, no? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König ...

To "break the current code" is simply not possible. Sorry to oppose. As you have written it "extend the DMA API", so if you do not use the new API (and no current code is using it) you cannot "break the current code". Thanks, --

Hello, I'm still trying to find out what you actually suggest we should do now. Maybe this is a request for a minimal "fix" without the cleanups Guennadi did? That is only patches 2(?), 4 and 5 of the series? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --

Hi Philippe, I have no problem with the m68knommu part. I can push that into the m68knommu git tree. Or if the m68k guys are happy I can put the whole thing there? Regards -- ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, ...

My suggestion was actually to have a new syscall with the existing structure, and pass a clockid_t value to it, similar to your Yes, that's exactly what the padding is for. Instead of timespec, you can probably have a extra values for replacing the existing ppm values with ppb values. Arnd --

Multiple PLLs, at least with containers and certain classes of system you want different containers in different timespaces, especially when doing high precision stuff where you need your system tracking say a local master clock for syncing musical instruments and sound events while Put the clock type in the new fields. It becomes u16 clock_type; [clock type specific data] saves having to guess. Alan --

In message: <20100827140205.GA3293@riccoc20.at.omicron.at> Except for leap seconds, this is true. However, Unix time isn't UTC either. Unix time is UTC that pretends leap seconds just don't exist. POSIX enshrined this long ago, and nobody is going to change that any time soon. I don't believe IEEEv2 propagates leap seconds, does it? Warner --

The amount of time a thread has been granted by the kernel is really not connected to the real passage of time, at least not in a direct This one comes from commit 2d42244ae71d6c7b0884b5664cf2eda30fb2ae68 and is surely a special case, unrelated to the other clock ids. The commit message mentions that this was added to help the btime.sf.net project. That project does not seem to have had any activity since 2007. If we can justify adding a clock id in this case, surely we can These were ...

In this case I don't think you can. Their divergence is rather difficult to handle unless you have a GPS to hand. But all this talk of "PTP this" and "PTP that" is not helpful. Any interface for additional time sources should be generic with PTP being one use case. Alan --

Which seems fine to me too - its an implementation detail of that time Not only that but consumers of different time synchronizations will need to be able to describe which time source they want to talk about from a Something like /sys/class/timesource/<name>/... at which point we don't have to enumerate them all, add special system calls and then fret about the fact you can't access them from things like shell scripts. The fact SYS5.4 Unix and SuS got obsessed with numbering ...

Okay, I really meant "for PTP hardware clocks". In general the discussion is about supporting a kind of hardware and not about the PTP network protocol. In fact, the hardware clocks and clock servo loops are not at all part of the IEEE 1588 standard. Sorry for causing confusion, but please understand "a hardware clock with timestamping capabilities than can be used for PTP support" whenever I wrote "PTP" or "PTP clock." Well, what I just said is not entirely true. In fact, most of the ...

I'm not opposed to adding a clock id, I just want it to be generic enough to make sense. So while MONOTONIC_RAW it was spurred into being from btime, it isn't a CLOCK_BTIME interface. I've also been pushing the RADClock folks to use it since it avoids the ugly raw hardware access they want to get access to a constant freq counter. In addition, I've used it to monitor freq adjustments done by Right, but what they represent and how its different from CLOCK_REALTIME Right. So ...

I wasn't suggesting adding the clock multiplexing to the timex, just using the timex to specify the adjustments in the clock_adjtime call. So I was asking why a timex was not suitable instead of using just the The existing struct timeval in the timex can be also used as a timespec. Again, I think you misunderstood my suggestion. I was suggesting I think using the timex struct covers most of the existing knowledge of what is needed. thanks -john --

----- Original Message ----- From: "Grant Likely" <grant.likely@secretlab.ca> To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com> Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "David Brownell" <dbrownell@users.sourceforge.net>; <spi-devel-general@lists.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de> Sent: Saturday, August 14, 2010 3:49 PM How can the driver detect ...

Hi Mike, Do we have any proof to wipe that fear? If retrying on flush failure is safe on all storages used with multipath (e.g. SCSI, CCISS, DASD, etc), then current dm-mpath should be fine in the real world. But I'm afraid if there is a storage where something like below can happen: - a flush command is returned as error to mpath because a part of cache has physically broken at the time or so, then that part of data loses and the size of the cache is shrunk by the ...

On Thu, 26 Aug 2010 18:02:46 +0200 As I wrote, the DMA API simply wasn't designed in that way (let architectures to clip the mask), I guess. If it was, dma_set_coherent_mask might return the actual mask. --

On Mon, 9 Aug 2010 07:33:57 -0700 (PDT) Actually you can do mount -o remount /dev/whatever The changelog forgot to tell us why this is a useful thing to add. `mount -o remount' is surely a Linux-specific side-effect and there's really no guarantee that Linux will always retain that side-effect. OTOH FS_IOC_SYNCFS is linux-specific. If we're going to add something like this then it will need to be documented in manpages. Supposedly, a cc to linux-api@vger.kernel.org will help ...

Patches which don't have any changelog. This patch was sent with no As I indicated. The title tells us what the patch does but didn't tell us *why* it does it. Apparently it is preparatory work for some other Recently, I assume - it wasn't in this morning's linux-next. --

Ah, stupid me, I see, just checked the patch. The point is, some time ago (about one year ago ... but certainly after the ucb1400 was split into multiple chunks and ucb1400-gpio was added), there was no way to pass platform data to devices attached to ac97 bus. That's why there was that function "ucb1400_gpio_set_data()". That's not true anymore, we can just pass the pdata through the ac97 bus to the mfd part of ucb1400 driver (ucb1400-core), which then registers the gpio part of ...

Hi Mauro, Have you merged these 2 patches? I'm seeing very similar build errors in linux-next 20100827: ERROR: "get_rc_map" [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: "ir_input_unregister" [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: "ir_raw_event_store_edge" [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: "__ir_input_register" [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: "ir_raw_event_handle" [drivers/media/video/saa7134/saa7134.ko] ...

--

--

--

I reproduced the problem with the Tejun's patch applied, so I'm now quite sure the problem is related to the suspend of controller ports (which is done by scheduling SCSI error handling on the controller). Anyway, below is a new version of my patch that plays a bit nicer with the resume code. Can you please check if it still fixes the problem for you? Thanks, Rafael --- From: Rafael J. Wysocki <rjw@sisk.pl> Subject: SATA / AHCI: Do not play with the link PM during suspend to RAM ...

On Fri, 27 Aug 2010 20:49:39 +0100 erk, doing this via link ordering isn't nice. It would be better to express this dependency via initcall levels - core_initcall() or something. --

Might be related to Dan Carpenter's suggestion that the spacing for that line should change to: kunmap_atomic(((void *)sgbuffer) - sg->offset, KM_BIO_SRC_IRQ); -- Chris Ball <cjb@laptop.org> <http://printf.net/> One Laptop Per Child --

Hi Daniel, Looks like this patch got dropped because of the missing modifications to arch/arm/mach-omap2/mmc-twl4030.c. Are we still interested in the patch otherwise, and can anyone help with that? -- Chris Ball <cjb@laptop.org> <http://printf.net/> One Laptop Per Child --