Fix incorrect comment in io_apic_64.c No broadcasting happens. Signed-off-by: Andi Kleen <ak@linux.intel.com> --- arch/x86/kernel/io_apic_64.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux/arch/x86/kernel/io_apic_64.c =================================================================== --- linux.orig/arch/x86/kernel/io_apic_64.c +++ linux/arch/x86/kernel/io_apic_64.c @@ -911,8 +911,7 @@ static void __init setup_IO_APIC_irqs(vo } /* - * Set up the 825...

Hi, I noticed that the [kswapd0] thread was eating 3-7% cpu time but no swapspace has been used yet. This is with a just booted 2.6.25.4 system, currently with some disk i/o going on. So I figured that kswapd might not be responsible for "swapping" after all, although the name suggests it. Grep'ing Documentation/ for kswapd did not reveal much. Is the paper from Kanoj[0] still valid for 2.6 kernels? The SGI page referenced in Documentation/kernel-docs.txt is down, but there's a .txt version...

From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] ata: fix sleep-while-holding-spinlock in sata_nv blk_queue_bounce_limit() is a sleeping function, so reorganize the code a little to not call it while holding a spinlock. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- drivers/ata/sata_nv.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c index 858f706..a7bc56d 100644 --- a/dri...

Thanks for reporting this. Al already reported it and a fix is in ocfs2.git. We change the name entirely so that grep of user_stack doesn't match it at all. Joel -- "Nobody loves me, Nobody seems to care. Troubles and worries, people, You know I've had my share." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 --

Greetings all, The LIO-Target Core v3.0.0 tree has been imported from v2.9-STABLE from Linux-iSCSI.org source tree repositories into kernel.org git, and is building w/ v2.6.26-rc3. It can be found at: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary I will be continuing the cleanup activies for upstream, which so far has included the removal of legacy unused engine level mirroring/replication bits (as we are using LIO-DRBD or LIO-NR1 w/ MD for this now), and a few LINU...

Here are some patches against your 2.6.26-rc3-git tree. They fix a race condition when device_create is called. At that point in time sysfs files can be created automatically by the class or the driver subsystem, and if those files are opened before the device specific data is set, oopses can happen. This was found and reported for the bdi subsystem by Arthur Jones and he verified that these patches fix the problem. I then went and audited all users of the api and found other places where this...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/core/hcd.c | 6 +++--- 1 files changed, 3 insertions(+), ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Cornelia Huck <cornel...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/uio/uio.c | 7 +++-...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/leds/led-class.c | ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/video/display/d...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_vargs(). Many thanks to Arthur Jones <ajones@riverbed.com> for reporting the bug, and testing patches out. Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Arthur Jones <ajones@riv...

x86: don't read maxlvt before checking if APIC is mapped A check for unmapped apic was added before reading maxlvt but the early read of maxlvt wasn't removed. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Index: linux-2.6.25.noarch/arch/x86/kernel/apic_64.c =================================================================== --- linux-2.6.25.noarch.orig/arch/x86/kernel/apic_64.c +++ linux-2.6.25.noarch/arch/x86/kernel/apic_64.c @@ -524,7 +524,7 @@ int setup_profiling_timer(unsigned in...

eCryptfs would really like to have read-write access to all files in the lower filesystem. Right now, the persistent lower file may be opened read-only if the attempt to open it read-write fails. One way to keep from having to do that is to have a privileged kthread that can open the lower persistent file on behalf of the user opening the eCryptfs file; this patch implements this functionality. This patch will properly allow a less-privileged user to open the eCryptfs file, followed by a more-privi...

Linus, please pull from: master.kernel.org:/pub/scm/linux/kernel/git/djbw/async_tx.git fixes to receive: Christophe Jaillet (1): iop-adma: fixup some kzalloc/memset confusions Zhang Wei (1): fsldma: update the fsldma driver MAINTAINERS info MAINTAINERS | 6 ++++-- drivers/dma/iop-adma.c | 6 ++---- 2 files changed, 6 insertions(+), 6 deletions(-) Just a maintainer update and some simple cleanups of the iop-adma driver. Thanks, Dan Full log: com...

Hello Steven, Do you recognise these warnings? I do not know (yet) if these are ARM specific... CC kernel/rtmutex.o kernel/rtmutex.c: In function 'rt_write_fastlock': kernel/rtmutex.c:1582: warning: initialization makes pointer from integer without a cast kernel/rtmutex.c: In function 'rt_write_fasttrylock': kernel/rtmutex.c:1622: warning: initialization makes pointer from integer without a cast If so, do you have a fix for it? Regards, Remy --

Ah, I guess ARM is a bit more critical of chpxchg than x86 is. I'll add a patch for 2.6.24.7-rt9 (which I plan on releasing soon). It will have some minor clean ups. -- Steve --

There is the "Z" constraint, which matches either an indirect or an indexed memory address. That should fit here. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." --

'Z' will never emit a non-zero constant displacement. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." --

The current accessors should provide all the necessary ordering guarantees... Ben. --

It looks like we rely on -fno-strict-aliasing to prevent reordering ordinary memory accesses (such as to DMA descriptors) past the I/O access. It won't prevent reordering of memory reads around an I/O read, though, which could be a problem if the I/O read result determines the validity of the DMA buffer. IMHO, a memory clobber would be better. -Scott --

What about memory obtained from dma_alloc_coherent()? We still need a sync and a compiler barrier. The current I/O accessors have the former, but not the latter. -Scott --

From: Scott Wood <scottwood@freescale.com> The __volatile__ in the asm construct disallows movement of the inline asm relative to statements surrounding it. The only reason barrier() in kernel.h needs a memory clobber is because of a bug in ancient versions of gcc. In fact, I think that memory clobber might even be removable. --

From: Scott Wood <scottwood@freescale.com> Indeed, and even the GCC manual is clear about this. --

As far as I could tell, no other arch has a full memory clobber. I can see the argument for changing the Linux model to be stricter and less efficient, but easier to program for. Not that I entirely agree with it. But I don't see a good reason for why powerpc should be different than everything else. --