commit a47d3602bf588087b2db080f9268e7dc0433fc86 Author: Greg Kroah-Hartman Date: Thu Apr 1 15:56:18 2010 -0700 Linux 2.6.31.13 commit d2a8d874c18f492e34e00026d38b432abdbe282f Author: Dean Nelson Date: Mon Mar 29 22:03:00 2010 +0200 hwmon: (coretemp) Add missing newline to dev_warn() message commit 4d7a5644e4adfafe76c2bd8ee168e3f3b5dae3a8 upstream. Add missing newline to dev_warn() message string. This is more of an issue with older kernels that don't automatically add a newline if it was missing from the end of the previous line. Signed-off-by: Dean Nelson Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 231c18f9ed7fa9e5557fa8afd525e934e628bddf Author: Jan Beulich Date: Mon Mar 15 10:11:15 2010 +0000 x86: Fix placement of FIX_OHCI1394_BASE commit ff30a0543e9a6cd732582063e7cae951cdb7acf2 upstream. Ever for 32-bit with sufficiently high NR_CPUS, and starting with commit 789d03f584484af85dbdc64935270c8e45f36ef7 also for 64-bit, the statically allocated early fixmap page tables were not covering FIX_OHCI1394_BASE, leading to a boot time crash when "ohci1394_dma=early" was used. Despite this entry not being a permanently used one, it needs to be moved into the permanent range since it has to be close to FIX_DBGP_BASE and FIX_EARLYCON_MEM_BASE. Reported-bisected-and-tested-by: Justin P. Mattock Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=14487 Signed-off-by: Jan Beulich LKML-Reference: <4B9E15D30200007800034D23@vpn.id2.novell.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 194d2386083401a8a82379870a1fef7c24ca8723 Author: Alan Stern Date: Sat Mar 6 15:04:03 2010 -0500 USB: fix usbfs regression commit 7152b592593b9d48b33f8997b1dfd6df9143f7ec upstream. This patch (as1352) fixes a bug in the way isochronous input data is returned to userspace for usbfs transfers. The entire buffer must be copied, not just the first actual_length bytes, because the individual packets will be discontiguous if any of them are short. Reported-by: Markus Rechberger Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 33d1d989b77ecddd5d26f23b3a1cbc90f8aae2b7 Author: KOSAKI Motohiro Date: Tue Mar 23 13:35:33 2010 -0700 doc: add the documentation for mpol=local commit 5574169613b40b85d6f4c67208fa4846b897a0a1 upstream. commit 3f226aa1c (mempolicy: support mpol=local tmpfs mount option) added new mpol=local mount option. but it didn't add a documentation. This patch does it. Signed-off-by: KOSAKI Motohiro Cc: Ravikiran Thirumalai Cc: Christoph Lameter Cc: Mel Gorman Acked-by: Lee Schermerhorn Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2fe815df411731f1ef4938345488d951cea5f4fa Author: KOSAKI Motohiro Date: Tue Mar 23 13:35:32 2010 -0700 tmpfs: cleanup mpol_parse_str() commit 926f2ae04f183098cf9a30521776fb2759c8afeb upstream. mpol_parse_str() made lots 'err' variable related bug. Because it is ugly and reviewing unfriendly. This patch simplifies it. Signed-off-by: KOSAKI Motohiro Cc: Ravikiran Thirumalai Cc: Christoph Lameter Cc: Mel Gorman Acked-by: Lee Schermerhorn Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6c5e69f3f760bc93eba06eb7776ff205cc129708 Author: KOSAKI Motohiro Date: Tue Mar 23 13:35:31 2010 -0700 tmpfs: handle MPOL_LOCAL mount option properly commit 12821f5fb942e795f8009ece14bde868893bd811 upstream. commit 71fe804b6d5 (mempolicy: use struct mempolicy pointer in shmem_sb_info) added mpol=local mount option. but its feature is broken since it was born. because such code always return 1 (i.e. mount failure). This patch fixes it. Signed-off-by: KOSAKI Motohiro Cc: Ravikiran Thirumalai Cc: Christoph Lameter Cc: Mel Gorman Acked-by: Lee Schermerhorn Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4fbd4ab7b17a71132fbf9a21ffeee6e1a25f070e Author: KOSAKI Motohiro Date: Tue Mar 23 13:35:30 2010 -0700 tmpfs: mpol=bind:0 don't cause mount error. commit d69b2e63e9172afb4d07c305601b79a55509ac4c upstream. Currently, following mount operation cause mount error. % mount -t tmpfs -ompol=bind:0 none /tmp Because commit 71fe804b6d5 (mempolicy: use struct mempolicy pointer in shmem_sb_info) corrupted MPOL_BIND parse code. This patch restore the needed one. Signed-off-by: KOSAKI Motohiro Cc: Ravikiran Thirumalai Cc: Christoph Lameter Cc: Mel Gorman Acked-by: Lee Schermerhorn Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b221c4ef88aa82fdfcab9e98cca34a1173584bbf Author: Ravikiran G Thirumalai Date: Tue Mar 23 13:35:28 2010 -0700 tmpfs: fix oops on mounts with mpol=default commit 413b43deab8377819aba1dbad2abf0c15d59b491 upstream. Fix an 'oops' when a tmpfs mount point is mounted with the mpol=default mempolicy. Upon remounting a tmpfs mount point with 'mpol=default' option, the mount code crashed with a null pointer dereference. The initial problem report was on 2.6.27, but the problem exists in mainline 2.6.34-rc as well. On examining the code, we see that mpol_new returns NULL if default mempolicy was requested. This 'NULL' mempolicy is accessed to store the node mask resulting in oops. The following patch fixes it. Signed-off-by: Ravikiran Thirumalai Signed-off-by: KOSAKI Motohiro Cc: Christoph Lameter Cc: Mel Gorman Acked-by: Lee Schermerhorn Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4940b4acdfa806dba2115902632b7eb9c0c1b5fd Author: Francesco Lavra Date: Thu Dec 31 08:47:11 2009 -0300 V4L/DVB (13961): em28xx-dvb: fix memleak in dvb_fini() commit 19f48cb105b7fa18d0dcab435919a3a29b7a7c4c upstream. this patch fixes a memory leak which occurs when an em28xx card with DVB extension is unplugged or its DVB extension driver is unloaded. In dvb_fini(), dev->dvb must be freed before being set to NULL, as is done in dvb_init() in case of error. Note that this bug is also present in the latest stable kernel release. Signed-off-by: Francesco Lavra Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b2f2bf429aa7da6e0c06f38f44583690f1c4dce3 Author: Neil Horman Date: Fri Mar 5 13:44:16 2010 -0800 coredump: suppress uid comparison test if core output files are pipes commit 76595f79d76fbe6267a51b3a866a028d150f06d4 upstream. Modify uid check in do_coredump so as to not apply it in the case of pipes. This just got noticed in testing. The end of do_coredump validates the uid of the inode for the created file against the uid of the crashing process to ensure that no one can pre-create a core file with different ownership and grab the information contained in the core when they shouldn' tbe able to. This causes failures when using pipes for a core dumps if the crashing process is not root, which is the uid of the pipe when it is created. The fix is simple. Since the check for matching uid's isn't relevant for pipes (a process can't create a pipe that the uermodehelper code will open anyway), we can just just skip it in the event ispipe is non-zero Reverts a pipe-affecting change which was accidentally made in : commit c46f739dd39db3b07ab5deb4e3ec81e1c04a91af : Author: Ingo Molnar : AuthorDate: Wed Nov 28 13:59:18 2007 +0100 : Commit: Linus Torvalds : CommitDate: Wed Nov 28 10:58:01 2007 -0800 : : vfs: coredumping fix Signed-off-by: Neil Horman Cc: Andi Kleen Cc: Oleg Nesterov Cc: Alan Cox Cc: Al Viro Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit f57c82ec2ac34010d2b23fd1a6e20ca4a63b044d Author: Andreas Schwab Date: Sat Jan 30 10:20:59 2010 +0000 powerpc: TIF_ABI_PENDING bit removal commit 94f28da8409c6059135e89ac64a0839993124155 upstream. Here are the powerpc bits to remove TIF_ABI_PENDING now that set_personality() is called at the appropriate place in exec. Signed-off-by: Andreas Schwab Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman Signed-off-by: Stefan Bader commit 8646c7696b11177ca210f71c24a57872589ee871 Author: Linus Torvalds Date: Tue Feb 2 12:37:44 2010 -0800 Fix 'flush_old_exec()/setup_new_exec()' split commit 7ab02af428c2d312c0cf8fb0b01cc1eb21131a3d upstream. Commit 221af7f87b9 ("Split 'flush_old_exec' into two functions") split the function at the point of no return - ie right where there were no more error cases to check. That made sense from a technical standpoint, but when we then also combined it with the actual personality setting going in between flush_old_exec() and setup_new_exec(), it needs to be a bit more careful. In particular, we need to make sure that we really flush the old personality bits in the 'flush' stage, rather than later in the 'setup' stage, since otherwise we might be flushing the _new_ personality state that we're just setting up. So this moves the flags and personality flushing (and 'flush_thread()', which is the arch-specific function that generally resets lazy FP state etc) of the old process into flush_old_exec(), so that it doesn't affect any state that execve() is setting up for the new process environment. This was reported by Michal Simek as breaking his Microblaze qemu environment. Reported-and-tested-by: Michal Simek Cc: Peter Anvin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Stefan Bader commit 38616b6b68bb1f964f86e09548bef944147eaad0 Author: H. Peter Anvin Date: Thu Jan 28 22:14:43 2010 -0800 x86: get rid of the insane TIF_ABI_PENDING bit commit 05d43ed8a89c159ff641d472f970e3f1baa66318 upstream. Now that the previous commit made it possible to do the personality setting at the point of no return, we do just that for ELF binaries. And suddenly all the reasons for that insane TIF_ABI_PENDING bit go away, and we can just make SET_PERSONALITY() just do the obvious thing for a 32-bit compat process. Everything becomes much more straightforward this way. Signed-off-by: H. Peter Anvin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Stefan Bader commit f3f66f8afd79d1b5d5d89a7a608945f045e1efe4 Author: David Miller Date: Thu Jan 28 21:42:02 2010 -0800 sparc: TIF_ABI_PENDING bit removal commit 94673e968cbcce07fa78dac4b0ae05d24b5816e1 upstream. Here are the sparc bits to remove TIF_ABI_PENDING now that set_personality() is called at the appropriate place in exec. Signed-off-by: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Stefan Bader commit daba0e9518f116e040d89a9b9e5b3dcb9d27e912 Author: Linus Torvalds Date: Thu Jan 28 22:14:42 2010 -0800 Split 'flush_old_exec' into two functions commit 221af7f87b97431e3ee21ce4b0e77d5411cf1549 upstream. 'flush_old_exec()' is the point of no return when doing an execve(), and it is pretty badly misnamed. It doesn't just flush the old executable environment, it also starts up the new one. Which is very inconvenient for things like setting up the new personality, because we want the new personality to affect the starting of the new environment, but at the same time we do _not_ want the new personality to take effect if flushing the old one fails. As a result, the x86-64 '32-bit' personality is actually done using this insane "I'm going to change the ABI, but I haven't done it yet" bit (TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the personality, but just the "pending" bit, so that "flush_thread()" can do the actual personality magic. This patch in no way changes any of that insanity, but it does split the 'flush_old_exec()' function up into a preparatory part that can fail (still called flush_old_exec()), and a new part that will actually set up the new exec environment (setup_new_exec()). All callers are changed to trivially comply with the new world order. Signed-off-by: H. Peter Anvin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Stefan Bader commit 60c10feaaec148452f1ee18505f5c2dc205f800d Author: Jiri Slaby Date: Wed Feb 10 20:55:16 2010 +0100 x86, ia32_aout: do not kill argument mapping commit 318f6b228ba88a394ef560efc1bfe028ad5ae6b6 upstream. Do not set current->mm->mmap to NULL in 32-bit emulation on 64-bit load_aout_binary after flush_old_exec as it would destroy already set brpm mapping with arguments. Introduced by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba mm: variable length argument support where the argument mapping in bprm was added. [ hpa: this is a regression from 2.6.22... time to kill a.out? ] Signed-off-by: Jiri Slaby LKML-Reference: <1265831716-7668-1-git-send-email-jslaby@suse.cz> Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Ollie Wild Cc: x86@kernel.org Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit d539e5576605d048e6aeb21cbe3a8e71dc5eea81 Author: Yinghai Lu Date: Wed Feb 10 01:20:05 2010 -0800 x86: Fix SCI on IOAPIC != 0 commit 18dce6ba5c8c6bd0f3ab4efa4cbdd698dab5c40a upstream. Thomas Renninger reported on IBM x3330 booting a latest kernel on this machine results in: PCI: PCI BIOS revision 2.10 entry at 0xfd61c, last bus=1 PCI: Using configuration type 1 for base access bio: create slab at 0 ACPI: SCI (IRQ30) allocation failed ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20090903/evevent-161) ACPI: Unable to start the ACPI Interpreter Later all kind of devices fail... and bisect it down to this commit: commit b9c61b70075c87a8612624736faf4a2de5b1ed30 x86/pci: update pirq_enable_irq() to setup io apic routing it turns out we need to set irq routing for the sci on ioapic1 early. -v2: make it work without sparseirq too. -v3: fix checkpatch.pl warning, and cc to stable Reported-by: Thomas Renninger Bisected-by: Thomas Renninger Tested-by: Thomas Renninger Signed-off-by: Yinghai Lu LKML-Reference: <1265793639-15071-2-git-send-email-yinghai@kernel.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 4d87fb8a9ef88ef05b9e7ceb2bc0f86019fe1578 Author: Martin Fuzzey Date: Thu Feb 11 10:50:31 2010 -0300 V4L/DVB: Video : pwc : Fix regression in pwc_set_shutter_speed caused by bad constant => sizeof conversion. commit 53f68607caba85db9a73846ccd289e4b7fa96295 upstream. Regression was caused by my commit 6b35ca0d3d586b8ecb8396821af21186e20afaf0 which determined message size using sizeof rather than hardcoded constants. Unfortunately pwc_set_shutter_speed reuses a 2 byte buffer for a one byte message too so the sizeof was bogus in this case. All other uses of sizeof checked and are ok. Acked-by: Laurent Pinchart Signed-off-by: Martin Fuzzey Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c25e75ba38178843bd885f227d285eec53202dca Author: Kashyap, Desai Date: Wed Dec 16 18:50:06 2009 +0530 mpt2sas: Delete volume before HBA detach. commit d7384b28afb2bf2b7be835ddc8c852bdc5e0ce1c upstream. The driver hangs when doing `rmmod mpt2sas` if there are any IR volumes present.The hang is due the scsi midlayer trying to access the IR volumes after the driver releases controller resources. Perhaps when scsi_remove_host is called,the scsi mid layer is sending some request. This doesn't occur for bare drives becuase the driver is already reporting those drives deleted prior to calling mpt2sas_base_detach. To solve this issue, we need to delete the volumes as well. Signed-off-by: Kashyap Desai Reviewed-by: Eric Moore Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e6abd25776543a369117d0903ccedbc7a324d68f Author: Stanislaw Gruszka Date: Tue Feb 2 15:34:50 2010 +0100 airo: fix setting zero length WEP key commit f09c256375c7cf1e112b8ef6306cdd313490d7c0 upstream. Patch prevents call set_wep_key() with zero key length. That fix long standing regression since commit c0380693520b1a1e4f756799a0edc379378b462a "airo: clean up WEP key operations". Additionally print call trace when someone will try to use improper parameters, and remove key.len = 0 assignment, because it is in not possible code path. Reported-by: Chris Siebenmann Bisected-by: Chris Siebenmann Tested-by: Chris Siebenmann Cc: Dan Williams Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 54b663bdc94f94bf4d77566ec42d30d22b68ff8f Author: Pallipadi, Venkatesh Date: Wed Feb 10 10:35:31 2010 -0800 ACPI: Be in TS_POLLING state during mwait based C-state entry commit d306ebc28649b89877a22158fe0076f06cc46f60 upstream. ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using the write to the monitored address to wake up mwait'ing CPU. This patch changes the code to retain TS_POLLING bit if we are entering an mwait based deep C-state. The patch has been verified to reduce the number of resched IPIs in general and also improves the performance/power on workloads with low system utilization (i.e., when mwait based deep C-states are being used). Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f" http://marc.info/?l=linux-kernel&m=126441481427331&w=4 Reported-by: Lin Ming Tested-by: Alex Shi Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 354a8d03e60a13600346babc1a78ecce4075f917 Author: Dick Hollenbeck Date: Wed Dec 9 12:31:34 2009 -0800 serial: 8250: add serial transmitter fully empty test commit bca476139d2ded86be146dae09b06e22548b67f3 upstream. When controlling an industrial radio modem it can be necessary to manipulate the handshake lines in order to control the radio modem's transmitter, from userspace. The transmitter should not be turned off before all characters have been transmitted. serial8250_tx_empty() was reporting that all characters were transmitted before they actually were. === Discovered in parallel with more testing and analysis by Kees Schoenmakers as follows: I ran into an NetMos 9835 serial pci board which behaves a little different than the standard. This type of expansion board is very common. "Standard" 8250 compatible devices clear the 'UART_LST_TEMT" bit together with the "UART_LSR_THRE" bit when writing data to the device. The NetMos device does it slightly different I believe that the TEMT bit is coupled to the shift register. The problem is that after writing data to the device and very quickly after that one does call serial8250_tx_empty, it returns the wrong information. My patch makes the test more robust (and solves the problem) and it does not affect the already correct devices. Alan: We may yet need to quirk this but now we know which chips we have a way to do that should we find this breaks some other 8250 clone with dodgy THRE. Signed-off-by: Dick Hollenbeck Signed-off-by: Alan Cox Cc: Kees Schoenmakers Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 6590bda22d4fd456ddbf8e70077e247d3014c333 Author: Laurent Pinchart Date: Wed Feb 10 13:32:49 2010 +0100 class: Free the class private data in class_release commit 18d19c96457d172d913510c083bc7411ed40cb10 upstream. Fix a memory leak by freeing the memory allocated in __class_register for the class private data. Signed-off-by: Laurent Pinchart Acked-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit a0a4650a9de3ceab90cd3b0588843886513bae77 Author: Larry Finger Date: Tue Feb 2 10:08:19 2010 -0600 b43: Fix throughput regression commit b6c3f5be7c6ac3375f44de4545c1ffe216b34022 upstream. Commit c7ab5ef9bcd281135c21b4732c9be779585181be entitled "b43: implement short slot and basic rate handling" reduced the transmit throughput for my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling portion is OK, the problem is in the short slot handling. Prior to this change, the short slot enable/disable routines were never called. Experimentation showed that the critical part was changing the value at offset 0x0010 in the shared memory. This is supposed to contain the 802.11 Slot Time in usec, but if it is changed from its initial value of zero, performance is destroyed. On the other hand, changing the value in the MMIO register corresponding to the Interframe Slot Time increased performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic improvement of the transmit rate from 5.3 to 19.0 Mb/s. Other changes in the patch include removal of the magic number for the MMIO register, and allowing the slot time to be set for any PHY operating in the 2.4 GHz band. Previously, the routine was executed only for G PHYs. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 84b5d069f2e9900fe2fce04a3b31cf62cbd28d20 Author: Jody Bruchon Date: Sat Feb 6 10:46:26 2010 -0500 ALSA: hda-intel: Avoid divide by zero crash commit fed08d036f2aabd8d0c684439de37f8ebec2bbc2 upstream. On my AMD780V chipset, hda_intel.c can crash the kernel with a divide by zero for as-yet unknown reasons. A simple check for zero prevents it, though the problem that causes it remains. Since the workaround is harmless and won't affect anyone except victims of this bug, it should be safe; moreover, because this crash can be triggered by a user-mode application, there are denial of service implications on the systems affected by the bug without the patch. Signed-off-by: Jody Bruchon Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c855efe3b0b6d38df11e7773abf3c4c46af126ad Author: Ben Hutchings Date: Sun Aug 23 16:59:04 2009 +0100 drm/r128: Add test for initialisation to all ioctls that require it commit 7dc482dfeeeefcfd000d4271c4626937406756d7 upstream. Almost all r128's private ioctls require that the CCE state has already been initialised. However, most do not test that this has been done, and will proceed to dereference a null pointer. This may result in a security vulnerability, since some ioctls are unprivileged. This adds a macro for the common initialisation test and changes all ioctl implementations that require prior initialisation to use that macro. Also, r128_do_init_cce() does not test that the CCE state has not been initialised already. Repeated initialisation may lead to a crash or resource leak. This adds that test. Signed-off-by: Ben Hutchings Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 1161237e66e5530a5e473fe40105cc727c6ed770 Author: Jeff Layton Date: Fri Feb 5 13:14:00 2010 -0500 cifs: fix length calculation for converted unicode readdir names commit f12f98dba6ea1517cd7fbb912208893b9c014c15 upstream. cifs_from_ucs2 returns the length of the converted name, including the length of the NULL terminator. We don't want to include the NULL terminator in the dentry name length however since that'll throw off the hash calculation for the dentry cache. I believe that this is the root cause of several problems that have cropped up recently that seem to be papered over with the "noserverino" mount option. More confirmation of that would be good, but this is clearly a bug and it fixes at least one reproducible problem that was reported. This patch fixes at least this reproducer in this kernel.org bug: http://bugzilla.kernel.org/show_bug.cgi?id=15088#c12 Reported-by: Bjorn Tore Sund Acked-by: Dave Kleikamp Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5ee251e7438aa1bc21700c7550796221ece7592e Author: Trond Myklebust Date: Mon Feb 8 09:32:27 2010 -0500 NFS: Fix a bug in nfs_fscache_release_page() commit 2c1740098c708b465e87637b237feb2fd98f129a upstream. Not having an fscache cookie is perfectly valid if the user didn't mount with the fscache option. This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=15234 Signed-off-by: Trond Myklebust Acked-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 236638ad883fec47a3db42d823a80483733143a5 Author: Jan Beulich Date: Mon Sep 21 17:03:05 2009 -0700 mm: replace various uses of num_physpages by totalram_pages commit 4481374ce88ba8f460c8b89f2572027bd27057d0 upstream. Sizing of memory allocations shouldn't depend on the number of physical pages found in a system, as that generally includes (perhaps a huge amount of) non-RAM pages. The amount of what actually is usable as storage should instead be used as a basis here. Some of the calculations (i.e. those not intending to use high memory) should likely even use (totalram_pages - totalhigh_pages). Signed-off-by: Jan Beulich Acked-by: Rusty Russell Acked-by: Ingo Molnar Cc: Dave Airlie Cc: Kyle McMartin Cc: Jeremy Fitzhardinge Cc: Pekka Enberg Cc: Hugh Dickins Cc: "David S. Miller" Cc: Patrick McHardy Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1c5b7aee1288404afff343354e7b4ff32f3fb5f0 Author: Al Viro Date: Tue Feb 16 18:09:36 2010 +0000 fix LOOKUP_FOLLOW on automount "symlinks" commit ac278a9c505092dd82077a2446af8f9fc0d9c095 upstream. Make sure that automount "symlinks" are followed regardless of LOOKUP_FOLLOW; it should have no effect on them. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 610370eb6f789cce3c79b3d07eef825939ad5a6b Author: Wei Yongjun Date: Wed Oct 14 20:54:03 2009 +0800 inotify: fix coalesce duplicate events into a single event in special case commit 3de0ef4f2067da58fa5126d821a56dcb98cdb565 upstream. If we do rename a dir entry, like this: rename("/tmp/ino7UrgoJ.rename1", "/tmp/ino7UrgoJ.rename2") rename("/tmp/ino7UrgoJ.rename2", "/tmp/ino7UrgoJ") The duplicate events should be coalesced into a single event. But those two events do not be coalesced into a single event, due to some bad check in event_compare(). It can not match the two NULL inodes as the same event. Signed-off-by: Wei Yongjun Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 2e776c1424b3c276c8cf6775f7e0b2f1ef42e624 Author: Andreas Gruenbacher Date: Thu Oct 15 00:13:23 2009 +0200 dnotify: ignore FS_EVENT_ON_CHILD commit 945526846a84c00adac1efd1c6befdaa77039623 upstream. Mask off FS_EVENT_ON_CHILD in dnotify_handle_event(). Otherwise, when there is more than one watch on a directory and dnotify_should_send_event() succeeds, events with FS_EVENT_ON_CHILD set will trigger all watches and cause spurious events. This case was overlooked in commit e42e2773. #define _GNU_SOURCE #include #include #include #include #include #include #include #include static void create_event(int s, siginfo_t* si, void* p) { printf("create\n"); } static void delete_event(int s, siginfo_t* si, void* p) { printf("delete\n"); } int main (void) { struct sigaction action; char *tmpdir, *file; int fd1, fd2; sigemptyset (&action.sa_mask); action.sa_flags = SA_SIGINFO; action.sa_sigaction = create_event; sigaction (SIGRTMIN + 0, &action, NULL); action.sa_sigaction = delete_event; sigaction (SIGRTMIN + 1, &action, NULL); # define TMPDIR "/tmp/test.XXXXXX" tmpdir = malloc(strlen(TMPDIR) + 1); strcpy(tmpdir, TMPDIR); mkdtemp(tmpdir); # define TMPFILE "/file" file = malloc(strlen(tmpdir) + strlen(TMPFILE) + 1); sprintf(file, "%s/%s", tmpdir, TMPFILE); fd1 = open (tmpdir, O_RDONLY); fcntl(fd1, F_SETSIG, SIGRTMIN); fcntl(fd1, F_NOTIFY, DN_MULTISHOT | DN_CREATE); fd2 = open (tmpdir, O_RDONLY); fcntl(fd2, F_SETSIG, SIGRTMIN + 1); fcntl(fd2, F_NOTIFY, DN_MULTISHOT | DN_DELETE); if (fork()) { /* This triggers a create event */ creat(file, 0600); /* This triggers a create and delete event (!) */ unlink(file); } else { sleep(1); rmdir(tmpdir); } return 0; } Signed-off-by: Andreas Gruenbacher Signed-off-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 0a550150a43ec8dfe49171e9e736e6d7b8b7fa8b Author: Jean Delvare Date: Thu Apr 1 15:55:49 2010 -0700 hwmon: (w83781d) Request I/O ports individually for probing commit b0bcdd3cd0adb85a7686b396ba50493871b1135c upstream. Different motherboards have different PNP declarations for W83781D/W83782D chips. Some declare the whole range of I/O ports (8 ports), some declare only the useful ports (2 ports at offset 5) and some declare fancy ranges, for example 4 ports at offset 4. To properly handle all cases, request all ports individually for probing. After we have determined that we really have a W83781D or W83782D chip, the useful port range will be requested again, as a single block. I did not see a board which needs this yet, but I know of one for lm78 driver and I'd like to keep the logic of these two drivers in sync. Signed-off-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit e4f176e9356dcd7155d91456b4d8e2fe1b85edbe Author: Jean Delvare Date: Thu Apr 1 15:55:48 2010 -0700 hwmon: (lm78) Request I/O ports individually for probing commit 197027e6ef830d60e10f76efc8d12bf3b6c35db5 upstream. Different motherboards have different PNP declarations for LM78/LM79 chips. Some declare the whole range of I/O ports (8 ports), some declare only the useful ports (2 ports at offset 5) and some declare fancy ranges, for example 4 ports at offset 4. To properly handle all cases, request all ports individually for probing. After we have determined that we really have an LM78 or LM79 chip, the useful port range will be requested again, as a single block. This fixes the driver on the Olivetti M3000 DT 540, at least. Signed-off-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 04bd6922cb0f89cd3d2e6ac86792ef59d77c2b9f Author: Hans de Goede Date: Thu Apr 1 15:55:48 2010 -0700 hwmon: (fschmd) Fix a memleak on multiple opens of /dev/watchdog commit c453615f77aa51593c1c9c9031b4278797d3fd19 upstream. When /dev/watchdog gets opened a second time we return -EBUSY, but we already have got a kref then, so we end up leaking our data struct. Signed-off-by: Hans de Goede Signed-off-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 659cba5bf3d94e8e95b4d474e31886c1451cb9be Author: Ray Copeland Date: Thu Apr 1 15:55:47 2010 -0700 hwmon: (adt7462) Wrong ADT7462_VOLT_COUNT commit 85f8d3e5faea8bd36c3e5196f8334f7db45e19b2 upstream. The #define ADT7462_VOLT_COUNT is wrong, it should be 13 not 12. All the for loops that use this as a limit count are of the typical form, "for (n = 0; n < ADT7462_VOLT_COUNT; n++)", so to loop through all voltages w/o missing the last one it is necessary for the count to be one greater than it is. (Specifically, you will miss the +1.5V 3GPIO input with count = 12 vs. 13.) Signed-off-by: Ray Copeland Acked-by: "Darrick J. Wong" Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 692a97fe93dca8fd1e80f2d0baffa3aade767110 Author: Laurent Pinchart Date: Fri Oct 9 20:55:23 2009 -0300 V4L/DVB (13155): uvcvideo: Add a module parameter to set the streaming control timeout commit b232a012adfea9f535702e8296ea6b76e691f436 upstream The default streaming control timeout was found by Ondrej Zary to be too low for some Logitech webcams. With kernel 2.6.22 and newer they would timeout during initialization unles the audio function was initialized before the video function. Add a module parameter to set the streaming control timeout and increase the default value from 1000ms to 3000ms to fix the above problem. Thanks to Ondrej Zary for investigating the issue and providing an initial patch. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Brandon Philips Signed-off-by: Greg Kroah-Hartman commit d8d6782349be3b550ebe438794c327b7373ce54e Author: Jean Delvare Date: Thu Apr 1 15:55:46 2010 -0700 i2c-tiny-usb: Fix on big-endian systems commit 1c010ff8912cbc08d80e865aab9c32b6b00c527d upstream. The functionality bit vector is always returned as a little-endian 32-bit number by the device, so it must be byte-swapped to the host endianness. On the other hand, the delay value is handled by the USB stack, so no byte swapping is needed on our side. This fixes bug #15105: http://bugzilla.kernel.org/show_bug.cgi?id=15105 Reported-by: Jens Richter Signed-off-by: Jean Delvare Tested-by: Jens Richter Cc: Till Harbaum Cc: stable@kernel.org Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 8859bd1aef1f4030afe5aac41b685e13f31c60fb Author: Wolfram Sang Date: Thu Apr 1 15:55:45 2010 -0700 i2c/pca: Don't use *_interruptible commit 22f8b2695eda496026623020811cae34590ee3d7 upstream. Unexpected signals can disturb the bus-handling and lock it up. Don't use interruptible in 'wait_event_*' and 'wake_*' as in commits dc1972d02747d2170fb1d78d114801f5ecb27506 (for cpm), 1ab082d7cbd0f34e39a5396cc6340c00bc5d66ef (for mpc), b7af349b175af45f9d87b3bf3f0a221e1831ed39 (for omap). Signed-off-by: Wolfram Sang Signed-off-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit b1b624d1b57be13651a0470017106f5c27d056d7 Author: Thadeu Lima de Souza Cascardo Date: Thu Apr 1 15:55:45 2010 -0700 i2c: Do not use device name after device_unregister commit c556752109794a5ff199b80a1673336b4df8433a upstream. dev_dbg outputs dev_name, which is released with device_unregister. This bug resulted in output like this: i2c Xy2�0: adapter [SMBus I801 adapter at 1880] unregistered The right output would be: i2c i2c-0: adapter [SMBus I801 adapter at 1880] unregistered Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit acbf8a14113c8abeb10a21cefc551d03bdd8f3f7 Author: Greg KH Date: Mon Feb 15 17:37:46 2010 -0800 USB: usbfs: only copy the actual data received commit d4a4683ca054ed9917dfc9e3ff0f7ecf74ad90d6 upstream We need to only copy the data received by the device to userspace, not the whole kernel buffer, which can contain "stale" data. Thanks to Marcus Meissner for pointing this out and testing the fix. Reported-by: Marcus Meissner Tested-by: Marcus Meissner Cc: Alan Stern Cc: Linus Torvalds Cc: stable Signed-off-by: Greg Kroah-Hartman Acked-by: Jeff Mahoney commit 97fde87ccff1bf623631c58a1f032533983cb090 Author: Linus Torvalds Date: Tue Feb 16 20:35:07 2010 -0800 USB: usbfs: properly clean up the as structure on error paths commit ddeee0b2eec2a51b0712b04de4b39e7bec892a53 upstream USB: usbfs: properly clean up the as structure on error paths I notice that the processcompl_compat() function seems to be leaking the 'struct async *as' in the error paths. I think that the calling convention is fundamentally buggered. The caller is the one that did the "reap_as()" to get the as thing, the caller should be the one to free it too. Freeing it in the caller also means that it very clearly always gets freed, and avoids the need for any "free in the error case too". From: Linus Torvalds Cc: Alan Stern Cc: Marcus Meissner Cc: stable Signed-off-by: Greg Kroah-Hartman Acked-by: Jeff Mahoney commit c89094b689c85b9e6c2fcf97e0c7d81620e46f79 Author: Linus Torvalds Date: Sun Feb 7 10:11:23 2010 -0800 Fix race in tty_fasync() properly commit 80e1e823989ec44d8e35bdfddadbddcffec90424 upstream. This reverts commit 703625118069 ("tty: fix race in tty_fasync") and commit b04da8bfdfbb ("fnctl: f_modown should call write_lock_irqsave/ restore") that tried to fix up some of the fallout but was incomplete. It turns out that we really cannot hold 'tty->ctrl_lock' over calling __f_setown, because not only did that cause problems with interrupt disables (which the second commit fixed), it also causes a potential ABBA deadlock due to lock ordering. Thanks to Tetsuo Handa for following up on the issue, and running lockdep to show the problem. It goes roughly like this: - f_getown gets filp->f_owner.lock for reading without interrupts disabled, so an interrupt that happens while that lock is held can cause a lockdep chain from f_owner.lock -> sighand->siglock. - at the same time, the tty->ctrl_lock -> f_owner.lock chain that commit 703625118069 introduced, together with the pre-existing sighand->siglock -> tty->ctrl_lock chain means that we have a lock dependency the other way too. So instead of extending tty->ctrl_lock over the whole __f_setown() call, we now just take a reference to the 'pid' structure while holding the lock, and then release it after having done the __f_setown. That still guarantees that 'struct pid' won't go away from under us, which is all we really ever needed. Reported-and-tested-by: Tetsuo Handa Acked-by: Greg Kroah-Hartman Acked-by: Américo Wang Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 51d5fe4109bff13686634a408988547e2d1b3add Author: Greg Kroah-Hartman Date: Tue Jan 26 15:04:02 2010 -0800 fnctl: f_modown should call write_lock_irqsave/restore commit b04da8bfdfbbd79544cab2fadfdc12e87eb01600 upstream. Commit 703625118069f9f8960d356676662d3db5a9d116 exposed that f_modown() should call write_lock_irqsave instead of just write_lock_irq so that because a caller could have a spinlock held and it would not be good to renable interrupts. Cc: Eric W. Biederman Cc: Al Viro Cc: Alan Cox Cc: Tavis Ormandy Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds commit 4bd80d995548d3b3ee059e61f01a4196fae7d9d3 Author: Serge E. Hallyn Date: Tue Dec 15 16:47:27 2009 -0800 ipc ns: fix memory leak (idr) commit 7d6feeb287c61aafa88f06345387b1188edf4b86 upstream. We have apparently had a memory leak since 7ca7e564e049d8b350ec9d958ff25eaa24226352 "ipc: store ipcs into IDRs" in 2007. The idr of which 3 exist for each ipc namespace is never freed. This patch simply frees them when the ipcns is freed. I don't believe any idr_remove() are done from rcu (and could therefore be delayed until after this idr_destroy()), so the patch should be safe. Some quick testing showed no harm, and the memory leak fixed. Caught by kmemleak. Signed-off-by: Serge E. Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Acked-by: Nick Piggin Signed-off-by: Greg Kroah-Hartman commit b453242d287012673d7f089b15cee032941a6838 Author: Mart Raudsepp Date: Fri Jul 24 13:45:41 2009 -0300 V4L/DVB: af9015: add new USB ID for KWorld PlusTV Dual DVB-T Stick (DVB-T 399U) commit c92f056308c4a77a833e1cc1e16c1b68974483a6 upstream. Add new USB ID (1b80:e400) for KWorld PlusTV Dual DVB-T Stick (DVB-T 399U). The model number on the devices sticker label is "KW-DVB-T 399UR". Signed-off-by: Mart Raudsepp Acked-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1f3a1f385336c324df07fdf420637f88bd3c137c Author: Neil Turton Date: Wed Dec 23 13:47:13 2009 +0000 sfc: Fix DMA mapping cleanup in case of an error in TSO commit a7ebd27a13757248863cd61e541af7fa9e7727ee upstream. We need buffer->len to remain valid to work out the correct address to be unmapped. We therefore need to clear buffer->len after the unmap operation. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 769c57aa2e772496797ef662a367af30be6a7aea Author: Karel Zak Date: Mon Nov 23 09:29:13 2009 +0100 partitions: use sector size for EFI GPT commit 7d13af3279985f554784a45cc961f706dbcdbdd1 upstream. Currently, kernel uses strictly 512-byte sectors for EFI GPT parsing. That's wrong. UEFI standard (version 2.3, May 2009, 5.3.1 GUID Format overview, page 95) defines that LBA is always based on the logical block size. It means bdev_logical_block_size() (aka BLKSSZGET) for Linux. This patch removes static sector size from EFI GPT parser. The problem is reproducible with the latest GNU Parted: # modprobe scsi_debug dev_size_mb=50 sector_size=4096 # ./parted /dev/sdb print Model: Linux scsi_debug (scsi) Disk /dev/sdb: 52.4MB Sector size (logical/physical): 4096B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 24.6kB 3002kB 2978kB primary 2 3002kB 6001kB 2998kB primary 3 6001kB 9003kB 3002kB primary # blockdev --rereadpt /dev/sdb # dmesg | tail -1 sdb: unknown partition table <---- !!! with this patch: # blockdev --rereadpt /dev/sdb # dmesg | tail -1 sdb: sdb1 sdb2 sdb3 Signed-off-by: Karel Zak Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5f8978c54b5b7968a99ff3b113589f57acab009a Author: Karel Zak Date: Mon Nov 23 09:29:58 2009 +0100 partitions: read whole sector with EFI GPT header commit 87038c2d5bda2418fda8b1456a0ae81cc3ff5bd8 upstream. The size of EFI GPT header is not static, but whole sector is allocated for the header. The HeaderSize field must be greater than 92 (= sizeof(struct gpt_header) and must be less than or equal to the logical block size. It means we have to read whole sector with the header, because the header crc32 checksum is calculated according to HeaderSize. For more details see UEFI standard (version 2.3, May 2009): - 5.3.1 GUID Format overview, page 93 - Table 13. GUID Partition Table Header, page 96 Signed-off-by: Karel Zak Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3454b339ede358e99d1b96d4295d6e5952d65bb2 Author: Sebastian Kapfer Date: Fri Jan 15 10:11:22 2010 -0800 Input: ALPS - add interleaved protocol support (Dell E6x00 series) commit 1d9f26262aef6d63ff65eba0fd5f1583f342b69b upstream Properly handle version of the protocol where standard PS/2 packets from trackpoint are stuffed into middle (byte 3-6) of the standard ALPS packets when both the touchpad and trackpoint are used together. The patch is based on work done by Matthew Chapman and additional research done by David Kubicek and Erik Osterholm: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610 Many thanks to David Kubicek for his efforts in researching fine points of this new version of the protocol, especially interaction between pad and stick in these models. Cc: Andy Isaacson Signed-off-by: Sebastian Kapfer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 120f90d1e9fda2948117e93eefc5caa6a6209b3c Author: Yongseok Koh Date: Tue Jan 19 17:33:49 2010 +0900 vmalloc: remove BUG_ON due to racy counting of VM_LAZY_FREE commit 88f5004430babb836cfce886d5d54c82166f8ba4 upstream. In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and then vmap_lazy_nr is increased atomically. But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr is counted by checking VM_LAZY_FREE is set to va->flags. After counting the variable nr, kernel reads vmap_lazy_nr atomically and checks a BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent vmap_lazy_nr from being negative. The problem is that, if interrupted right after marking VM_LAZY_FREE, increment of vmap_lazy_nr can be delayed. Consequently, BUG_ON condition can be met because nr is counted more than vmap_lazy_nr. It is highly probable when vmalloc/vfree are called frequently. This scenario have been verified by adding delay between marking VM_LAZY_FREE and increasing vmap_lazy_nr in free_unmap_area_noflush(). Even the vmap_lazy_nr is for checking high watermark, it never be the strict watermark. Although the BUG_ON condition is to prevent vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable. So, it could go down to negative value temporarily. Consequently, removing the BUG_ON condition is proper. A possible BUG_ON message is like the below. kernel BUG at mm/vmalloc.c:517! invalid opcode: 0000 [#1] SMP EIP: 0060:[] EFLAGS: 00010297 CPU: 3 EIP is at __purge_vmap_area_lazy+0x144/0x150 EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Call Trace: [] free_unmap_vmap_area_noflush+0x69/0x70 [] remove_vm_area+0x22/0x70 [] __vunmap+0x45/0xe0 [] vmalloc+0x2c/0x30 Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31 EIP: [] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c [ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ] Signed-off-by: Yongseok Koh Reviewed-by: Minchan Kim Cc: Nick Piggin Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1eb2d343a6e035836bc8dbe9a4c9e5679fefa656 Author: Ryan May Date: Wed Jan 6 10:09:25 2010 -0600 USB: fix usbstorage for 2770:915d delivers no FAT commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream. Resolves kernel.org bug 14914. Remove entry for 2770:915d (usb digital camera with mass storage support) from unusual_devs.h. The fix triggered by the entry causes the file system on the camera to be completely inaccessible (no partition table, the device is not mountable). The patch works, but let me clarify a few things about it. All the patch does is remove the entry for this device from the drivers/usb/storage/unusual_devs.h, which is supposed to help with a problem with the device's reported size (I think). I'm pretty sure it was originally added for a reason, so I'm not sure removing it won't cause other problems to reappear. Also, I should note that this unusual_devs.h entry was present (and activating workarounds) in 2.6.29, but in that version everything works fine. Starting with 2.6.30, things no longer work. Signed-off-by: Ryan May Cc: Rohan Hart Signed-off-by: Greg Kroah-Hartman commit 7fdd4f780b0b7241d57ed3263f59c9133ff4c6f5 Author: Suresh Siddha Date: Mon Oct 26 13:21:32 2009 -0800 x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled commit 2992e545ea006992ec9dc91c4fa996ce1e15f921 upstream. Thomas Schlichter reported: > X.org uses libpciaccess which tries to mmap with write combining enabled via > /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the > kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded > mapping with write combining enabled and does not set up suited MTRR entries. > ;-( Instead of silently mapping pci mmap region as UC minus in the case of !pat_enabled and wc request, we can return error. Eric Anholt mentioned that caller (like X) typically follows up with UC minus pci mmap request and if there is a free mtrr slot, caller will manage adding WC mtrr. Jesse Barnes says: > Older versions of libpciaccess will behave better if we do it that way > (iirc it only allocates an MTRR if the resource_wc file doesn't exist or > fails to get mapped). Reported-by: Thomas Schlichter Signed-off-by: Thomas Schlichter Signed-off-by: Suresh Siddha Acked-by: Eric Anholt Acked-by: Jesse Barnes Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit d3f1c54adc9e1b127d569d2b947d54d273315e26 Author: James Bottomley Date: Thu Nov 26 09:50:20 2009 -0600 SCSI: enclosure: fix oops while iterating enclosure_status array commit cc9b2e9f6603190c009e5d2629ce8e3f99571346 upstream. Based on patch originally by Jeff Mahoney enclosure_status is expected to be a NULL terminated array of strings but isn't actually NULL terminated. When writing an invalid value to /sys/class/enclosure/.../.../status, it goes off the end of the array and Oopses. Fix by making the assumption true and adding NULL at the end. Reported-by: Artur Wojcik Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 14a2fe817f8ca96cbe718165ec1ffba025ddc556 Author: Johan Hovold Date: Wed Jan 6 15:48:42 2010 -0800 usb: serial: fix memory leak in generic driver commit 2591530204a76fecc843529ade56afe865dd2657 upstream. Fix a regression introduced by commit 715b1dc01fe44537e8fce9566e4bb48d6821d84b ("USB: usb_debug, usb_generic_serial: implement multi urb write"). URB transfer buffer was never freed when using multi-urb writes. Currently the only driver enabling multi-urb writes is usb_debug. Signed-off-by: Johan Hovold Cc: Greg KH Acked-by: Jason Wessel Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 70f176dfdcb13ee263a08c851ea5cd1747aab39c Author: Alan Stern Date: Tue Dec 22 23:16:32 2009 -0500 USB: fix bitmask merge error commit a91b593edd4b3e8aa91f671b763b27b8119eb49d upstream. This patch adds a mask bit which was mistakenly omitted from the as1311 patch (usb-storage: add BAD_SENSE flag). Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 4f0e35f03db2673dc86ee940dcaab5f8f422dc81 Author: Alan Stern Date: Fri Jan 8 11:18:20 2010 -0500 USB: EHCI & UHCI: fix race between root-hub suspend and port resume commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream. This patch (as1321) fixes a problem with EHCI and UHCI root-hub suspends: If the suspend occurs while a port is trying to resume, the resume doesn't finish and simply gets lost. When remote wakeup is enabled, this is undesirable behavior. The patch checks first to see if any port resumes are in progress, and if they are then it fails the root-hub suspend with -EBUSY. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 16505a92d463c96d223091fa35f9d084c0813606 Author: Alan Stern Date: Fri Jan 8 11:17:55 2010 -0500 USB: EHCI: fix handling of unusual interrupt intervals commit 1b9a38bfa6e664ff02511314f5586d711c83cc91 upstream. This patch (as1320) fixes two problems related to interrupt-URB scheduling in ehci-hcd. URBs with an interval of 2 or 4 microframes aren't handled. For the time being, the patch reduces to interval to 1 uframe. URBs are constrained to have an interval no larger than 1024 frames by usb_submit_urb(). But some EHCI controllers allow use of a schedule as short as 256 frames; for these controllers we may have to decrease the interval to the actual schedule length. The second problem isn't very significant since few devices expose interrupt endpoints with an interval larger than 256 frames. But the first problem is critical; it will prevent the kernel from working with devices having interrupt intervals of 2 or 4 uframes. Signed-off-by: Alan Stern Tested-by: Glynn Farrow Signed-off-by: Greg Kroah-Hartman commit 63821748fb4f6d65b4b92ba90b88bf989a512a5d Author: Oliver Neukum Date: Tue Jan 12 12:32:50 2010 +0100 USB: Don't use GFP_KERNEL while we cannot reset a storage device commit acbe2febe71abb2360b008e9ab3ee5c44169f78c upstream. Memory allocations with GFP_KERNEL can cause IO to a storage device which can fail resulting in a need to reset the device. Therefore GFP_KERNEL cannot be safely used between usb_lock_device() and usb_unlock_device(). Replace by GFP_NOIO. Signed-off-by: Oliver Neukum Cc: Alan Stern Signed-off-by: Greg Kroah-Hartman commit bb4ac89de4a2755a3aacbc252f503957ca00109d Author: Greg Kroah-Hartman Date: Thu Jan 14 10:33:19 2010 -0800 USB: add speed values for USB 3.0 and wireless controllers commit b132b04e193908a94d95065d0628f8fb0159cc55 upstream. These controllers say "unknown" for their speed in sysfs, which obviously isn't correct. Reported-by: Kurt Garloff Cc: Sarah Sharp Cc: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 09524c55c1748d21ab45b4e9e4419b42d669685b Author: Alan Stern Date: Fri Jan 8 11:18:38 2010 -0500 USB: add missing delay during remote wakeup commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream. This patch (as1330) fixes a bug in khbud's handling of remote wakeups. When a device sends a remote-wakeup request, the parent hub (or the host controller driver, for directly attached devices) begins the resume sequence and notifies khubd when the sequence finishes. At this point the port's SUSPEND feature is automatically turned off. However the device needs an additional 10-ms resume-recovery time (TRSMRCY in the USB spec). Khubd does not wait for this delay if the SUSPEND feature is off, and as a result some devices fail to behave properly following a remote wakeup. This patch adds the missing delay to the remote-wakeup path. It also extends the resume-signalling delay used by ehci-hcd and uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use for non-remote-wakeup resumes). The extra time appears to help some devices. Signed-off-by: Alan Stern Cc: Rickard Bellini Signed-off-by: Greg Kroah-Hartman commit 4bbb96c37a538469960a95333a4f1bf74efedc94 Author: Greg Kroah-Hartman Date: Thu Dec 17 07:07:19 2009 -0800 tty: fix race in tty_fasync commit 703625118069f9f8960d356676662d3db5a9d116 upstream. We need to keep the lock held over the call to __f_setown() to prevent a PID race. Thanks to Al Viro for pointing out the problem, and to Travis for making us look here in the first place. Cc: Eric W. Biederman Cc: Al Viro Cc: Alan Cox Cc: Linus Torvalds Cc: Tavis Ormandy Cc: Jeff Dike Cc: Julien Tinnes Cc: Matt Mackall Signed-off-by: Greg Kroah-Hartman commit c17975de81fa9937c2b5827ead464f044b30f9c2 Author: Matthew Garrett Date: Wed Dec 9 12:31:37 2009 -0800 serial: 8250_pnp: use wildcard for serial Wacom tablets commit 6d34855d9aa281f72c533ecb827405139d1b0fe9 upstream. Wacom claims that the WACF namespace will always be devoted to serial Wacom tablets. Remove the existing entries and add a wildcard to avoid having to update the kernel every time they add a new device. Signed-off-by: Ping Cheng Signed-off-by: Matthew Garrett Tested-by: Ping Cheng Cc: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f321f60bd07c223fb240bad680ba519fda82873c Author: Alan Cox Date: Mon Jan 4 16:26:50 2010 +0000 nozomi: quick fix for the close/close bug commit eeec32a731631a9bad9abb21c626b9f2840bee0d upstream. Nozomi goes wrong if you get the sequence open open close [stuff] close which turns out to occur on some ppp type setups. This is a quick patch up for the problem. It's not really fixing Nozomi which completely fails to implement tty open/close semantics and all the other needed stuff. Doing it right is a rather more invasive patch set and not one that will backport. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 12761d772b9d9bdccfb7610538e90de2be15a3f7 Author: Dan Carpenter Date: Tue Jan 19 12:34:32 2010 +0300 ecryptfs: use after free commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream. The "full_alg_name" variable is used on a couple error paths, so we shouldn't free it until the end. Signed-off-by: Dan Carpenter Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 1f19180adb1711a88c9f60bce99d8f8442fa2981 Author: Erez Zadok Date: Thu Dec 3 13:35:27 2009 -0500 ecryptfs: initialize private persistent file before dereferencing pointer commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream. Ecryptfs_open dereferences a pointer to the private lower file (the one stored in the ecryptfs inode), without checking if the pointer is NULL. Right afterward, it initializes that pointer if it is NULL. Swap order of statements to first initialize. Bug discovered by Duckjin Kang. Signed-off-by: Duckjin Kang Signed-off-by: Erez Zadok Cc: Dustin Kirkland Cc: Al Viro Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 954eec71d4436334622f2549d647c036a8763828 Author: Jan Kara Date: Thu Dec 17 15:27:06 2009 -0800 reiserfs: truncate blocks not used by a write commit ec8e2f7466ca370f5e09000ca40a71759afc9ac8 upstream. It can happen that write does not use all the blocks allocated in write_begin either because of some filesystem error (like ENOSPC) or because page with data to write has been removed from memory. We truncate these blocks so that we don't have dangling blocks beyond i_size. Cc: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5cae244ff0fa273001a56e2ce62cd18ff2b6d5a3 Author: Suresh Siddha Date: Mon Jan 18 12:10:48 2010 -0800 x86, apic: use physical mode for IBM summit platforms commit dfea91d5a7c795fd6f4e1a97489a98e4e767463e upstream. Chris McDermott from IBM confirmed that hurricane chipset in IBM summit platforms doesn't support logical flat mode. Irrespective of the other things like apic_id's, total number of logical cpu's, Linux kernel should default to physical mode for this system. The 32-bit kernel does so using the OEM checks for the IBM summit platform. Add a similar OEM platform check for the 64bit kernel too. Otherwise the linux kernel boot can hang on this platform under certain bios/platform settings. Signed-off-by: Suresh Siddha Tested-by: Ananth N Mavinakayanahalli Cc: Chris McDermott Cc: Yinghai Lu Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 841e7fc166701dcd2eec3c470492e3ee1c0d0b92 Author: KOSAKI Motohiro Date: Fri Jan 15 17:01:18 2010 -0800 page allocator: update NR_FREE_PAGES only when necessary commit 6ccf80eb15ccaca4d3f1ab5162b9ded5eecd9971 upstream. commit f2260e6b (page allocator: update NR_FREE_PAGES only as necessary) made one minor regression. if __rmqueue() was failed, NR_FREE_PAGES stat go wrong. this patch fixes it. Signed-off-by: KOSAKI Motohiro Cc: Mel Gorman Reviewed-by: Minchan Kim Reported-by: Huang Shijie Reviewed-by: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 48dd705726e90a55b544ee1666e94501058e47df Author: Bryn M. Reeves Date: Thu Nov 12 18:31:54 2009 +0000 megaraid_sas: remove sysfs poll_mode_io world writeable permissions commit bb7d3f24c71e528989501617651b669fbed798cb upstream. /sys/bus/pci/drivers/megaraid_sas/poll_mode_io defaults to being world-writable, which seems bad (letting any user affect kernel driver behavior). This turns off group and user write permissions, so that on typical production systems only root can write to it. Signed-off-by: Bryn M. Reeves Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e4dc0141438ad95e3fbd8389168c83013f7fa767 Author: Tamas Vincze Date: Fri Jan 15 17:01:10 2010 -0800 edac: i5000_edac critical fix panic out of bounds commit 118f3e1afd5534c15f9701f33514186cfc841a27 upstream. EDAC MC0: INTERNAL ERROR: channel-b out of range (4 >= 4) Kernel panic - not syncing: EDAC MC0: Uncorrected Error (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. This happens because FERR_NF_FBD bit 28 is not updated on i5000. Due to that, both bits 28 and 29 may be equal to one, returning channel = 3. As this value is invalid, EDAC core generates the panic. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14568 Signed-off-by: Tamas Vincze Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Doug Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3ed2f40b8784eb1f2f6b4fd7d4a7aff5732ebfe6 Author: Eric Paris Date: Fri Jan 15 12:12:25 2010 -0500 inotify: only warn once for inotify problems commit 976ae32be45a736acd49215a7e4771ff91f161c3 upstream. inotify will WARN() if it finds that the idr and the fsnotify internals somehow got out of sync. It was only supposed to do this once but due to this stupid bug it would warn every single time a problem was detected. Signed-off-by: Eric Paris Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 06e66e5a5be3025cdf7a8c7027f9cbd9c754e463 Author: Eric Paris Date: Fri Jan 15 12:12:24 2010 -0500 inotify: do not reuse watch descriptors commit 9e572cc9877ee6c43af60778f6b8d5ba0692d935 upstream. Since commit 7e790dd5fc937bc8d2400c30a05e32a9e9eef276 ("inotify: fix error paths in inotify_update_watch") inotify changed the manor in which it gave watch descriptors back to userspace. Previous to this commit inotify acted like the following: inotify_add_watch(X, Y, Z) = 1 inotify_rm_watch(X, 1); inotify_add_watch(X, Y, Z) = 2 but after this patch inotify would return watch descriptors like so: inotify_add_watch(X, Y, Z) = 1 inotify_rm_watch(X, 1); inotify_add_watch(X, Y, Z) = 1 which I saw as equivalent to opening an fd where open(file) = 1; close(1); open(file) = 1; seemed perfectly reasonable. The issue is that quite a bit of userspace apparently relies on the behavior in which watch descriptors will not be quickly reused. KDE relies on it, I know some selinux packages rely on it, and I have heard complaints from other random sources such as debian bug 558981. Although the man page implies what we do is ok, we broke userspace so this patch almost reverts us to the old behavior. It is still slightly racey and I have patches that would fix that, but they are rather large and this will fix it for all real world cases. The race is as follows: - task1 creates a watch and blocks in idr_new_watch() before it updates the hint. - task2 creates a watch and updates the hint. - task1 updates the hint with it's older wd - task removes the watch created by task2 - task adds a new watch and will reuse the wd originally given to task2 it requires moving some locking around the hint (last_wd) but this should solve it for the real world and be -stable safe. As a side effect this patch papers over a bug in the lib/idr code which is causing a large number WARN's to pop on people's system and many reports in kerneloops.org. I'm working on the root cause of that idr bug seperately but this should make inotify immune to that issue. Signed-off-by: Eric Paris Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit beceb39d42a6f6b0d799c809c4795b75bc5b79f4 Author: Christian Schuerer-Waldheim Date: Wed Jan 6 14:49:57 2010 +0100 HID: add device IDs for new model of Apple Wireless Keyboard commit 23aeb61e7e1f02fb0f3b8f9e798e75537ca1731d upstream. Added device IDs for the new model of the Apple Wireless Keyboard (November 2009). Signed-off-by: Christian Schuerer-Waldheim Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ef90f00fb08ab96a273cb6c078bf1c6e75856375 Author: Takashi Iwai Date: Mon Dec 28 12:24:22 2009 +0100 ALSA: usb-audio - Avoid Oops after disconnect commit 78b8d5d2ee280c463908fd75f3bdf246bcb6ac8d upstream. As the release of substreams may be done asynchronously from the disconnection, close callback needs to check the shutdown flag before actually accessing the usb interface. Reference: Novell bnc#505027 http://bugzilla.novell.com/show_bug.cgi?id=565027 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 53fc82f62490a22d0bc547ab3191710ea10d9482 Author: Avi Kivity Date: Tue Nov 24 15:20:15 2009 +0200 KVM: x86 emulator: limit instructions to 15 bytes commit eb3c79e64a70fb8f7473e30fa07e89c1ecc2c9bb upstream While we are never normally passed an instruction that exceeds 15 bytes, smp games can cause us to attempt to interpret one, which will cause large latencies in non-preempt hosts. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit fdbb0a82d730de057e525f7aaee6add60286b324 Author: Evgeniy Polyakov Date: Tue Feb 2 15:58:48 2010 -0800 connector: Delete buggy notification code. commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 upstream. On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote: > > There are at least two ways to fix it: using a big cannon and a small > > one. The former way is to disable notification registration, since it is > > not used by anyone at all. Second way is to check whether calling > > process is root and its destination group is -1 (kind of priveledged > > one) before command is dispatched to workqueue. > > Well if no one is using it, removing it makes the most sense, right? > > No objection from me, care to make up a patch either way for this? Getting it is not used, let's drop support for notifications about (un)registered events from connector. Another option was to check credentials on receiving, but we can always restore it without bugs if needed, but genetlink has a wider code base and none complained, that userspace can not get notification when some other clients were (un)registered. Kudos for Sebastian Krahmer , who found a bug in the code. Signed-off-by: Evgeniy Polyakov Acked-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 888cafa05c94bccef4d7ceba7228dda7ae06f2fc Author: Xiaotian Feng Date: Thu Jan 7 11:22:44 2010 +0800 clockevent: Don't remove broadcast device when cpu is dead commit ea9d8e3f45404d411c00ae67b45cc35c58265bb7 upstream. Marc reported that the BUG_ON in clockevents_notify() triggers on his system. This happens because the kernel tries to remove an active clock event device (used for broadcasting) from the device list. The handling of devices which can be used as per cpu device and as a global broadcast device is suboptimal. The simplest solution for now (and for stable) is to check whether the device is used as global broadcast device, but this needs to be revisited. [ tglx: restored the cpuweight check and massaged the changelog ] Reported-by: Marc Dionne Tested-by: Marc Dionne Signed-off-by: Xiaotian Feng LKML-Reference: <1262834564-13033-1-git-send-email-dfeng@redhat.com> Signed-off-by: Thomas Gleixner Acked-by: Jeff Mahoney Signed-off-by: Greg Kroah-Hartman commit 98e4c05d2401863414cb5183e4d844ad061598ef Author: Luis R. Rodriguez Date: Mon Jan 4 10:40:39 2010 -0500 ath5k: Fix eeprom checksum check for custom sized eeproms commit 359207c687cc8f4f9845c8dadd0d6dabad44e584 upstream. Commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 enabled EEPROM checksum checks to avoid bogus bug reports but failed to address updating the code to consider devices with custom EEPROM sizes. Devices with custom sized EEPROMs have the upper limit size stuffed in the EEPROM. Use this as the upper limit instead of the static default size. In case of a checksum error also provide back the max size and whether or not this was the default size or a custom one. If the EEPROM is busted we add a failsafe check to ensure we don't loop forever or try to read bogus areas of hardware. This closes bug 14874 http://bugzilla.kernel.org/show_bug.cgi?id=14874 Cc: stable@kernel.org Cc: David Quan Cc: Stephen Beahm Reported-by: Joshua Covington Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville commit 9b44bbd3b08c8b9c7ae764465239886ca4d94827 Author: Sergey Matyukevich Date: Tue Feb 2 13:43:59 2010 -0800 rtc-fm3130: add missing braces commit f4b5162820de60204afa5c8639335f4931b7fb0c upstream. Add missing braces for multiline 'if' statements in fm3130_probe. Signed-off-by: Sergey Matyukevich Signed-off-by: Alessandro Zummo Cc: Sergey Lapin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 06ec11b10dfe1560540ed3488d5727d587c3d601 Author: Jiri Slaby Date: Thu Nov 19 17:16:37 2009 +0100 resource: add helpers for fetching rlimits commit 3e10e716abf3c71bdb5d86b8f507f9e72236c9cd upstream. We want to be sure that compiler fetches the limit variable only once, so add helpers for fetching current and maximal resource limits which do that. Add them to sched.h (instead of resource.h) due to circular dependency sched.h->resource.h->task_struct Alternative would be to create a separate res_access.h or similar. Signed-off-by: Jiri Slaby Cc: James Morris Cc: Heiko Carstens Cc: Andrew Morton Cc: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e8772825003228c6c5dd94af7238a1b1fc12ec68 Author: Thomas Renninger Date: Mon Dec 14 11:44:15 2009 +0100 CPUFREQ: Fix use after free of struct powernow_k8_data commit 557a701c16553b0b691dbb64ef30361115a80f64 upstream. Easy fix for a regression introduced in 2.6.31. On managed CPUs the cpufreq.c core will call driver->exit(cpu) on the managed cpus and powernow_k8 will free the core's data. Later driver->get(cpu) function might get called trying to read out the current freq of a managed cpu and the NULL pointer check does not work on the freed object -> better set it to NULL. ->get() is unsigned and must return 0 as invalid frequency. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14391 Signed-off-by: Thomas Renninger Tested-by: Michal Schmidt Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman commit b7f7ed5565c30f4e1058d7c97c49fe52e0136ee9 Author: Stephen M. Cameron Date: Fri Feb 5 13:14:04 2010 +0100 cciss: Make cciss_seq_show handle holes in the h->drv[] array commit 531c2dc70d339c5dfa8c3eb628c3459dc6f3a075 upstream. It is possible (and expected) for there to be holes in the h->drv[] array, that is, some elements may be NULL pointers. cciss_seq_show needs to be made aware of this possibility to avoid an Oops. To reproduce the Oops which this fixes: 1) Create two "arrays" in the Array Configuratino Utility and several logical drives on each array. 2) cat /proc/driver/cciss/cciss* in an infinite loop 3) delete some of the logical drives in the first "array." Signed-off-by: Stephen M. Cameron Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 77e4ffd96c3120efc81e1060606b0ea31b84e50b Author: Mika Westerberg Date: Tue Jan 26 17:47:05 2010 +0200 UBI: fix volume creation input checking commit c5ce5b46af76f52dea21f467397d24c4ae6cb3ff upstream. Do not use an unchecked variable UBI_IOCMKVOL ioctl. Signed-off-by: Mika Westerberg Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 84e39bcb1418095afb6918226276e1f4785b8329 Author: Jiri Slaby Date: Fri Aug 28 10:47:16 2009 +0200 SECURITY: selinux, fix update_rlimit_cpu parameter commit 17740d89785aeb4143770923d67c293849414710 upstream. Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in selinux_bprm_committing_creds, since update_rlimit_cpu expects RLIMIT_CPU limit. Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that. Signed-off-by: Jiri Slaby Acked-by: James Morris Cc: Stephen Smalley Cc: Eric Paris Cc: David Howells Signed-off-by: Greg Kroah-Hartman commit b2547d0901583d4cb381a66a771087dd29174faf Author: Mikael Pettersson Date: Sat Jan 23 22:36:29 2010 +0100 futex_lock_pi() key refcnt fix commit 5ecb01cfdf96c5f465192bdb2a4fd4a61a24c6cc upstream. This fixes a futex key reference count bug in futex_lock_pi(), where a key's reference count is incremented twice but decremented only once, causing the backing object to not be released. If the futex is created in a temporary file in an ext3 file system, this bug causes the file's inode to become an "undead" orphan, which causes an oops from a BUG_ON() in ext3_put_super() when the file system is unmounted. glibc's test suite is known to trigger this, see . The bug is a regression from 2.6.28-git3, namely Peter Zijlstra's 38d47c1b7075bd7ec3881141bb3629da58f88dab "[PATCH] futex: rely on get_user_pages() for shared futexes". That commit made get_futex_key() also increment the reference count of the futex key, and updated its callers to decrement the key's reference count before returning. Unfortunately the normal exit path in futex_lock_pi() wasn't corrected: the reference count is incremented by get_futex_key() and queue_lock(), but the normal exit path only decrements once, via unqueue_me_pi(). The fix is to put_futex_key() after unqueue_me_pi(), since 2.6.31 this is easily done by 'goto out_put_key' rather than 'goto out'. Signed-off-by: Mikael Pettersson Acked-by: Peter Zijlstra Acked-by: Darren Hart Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit b17fccf557c60799e5d3881a5c83da4a34869a10 Author: Thomas Gleixner Date: Tue Feb 2 11:40:27 2010 +0100 futex: Handle user space corruption gracefully commit 51246bfd189064079c54421507236fd2723b18f3 upstream. If the owner of a PI futex dies we fix up the pi_state and set pi_state->owner to NULL. When a malicious or just sloppy programmed user space application sets the futex value to 0 e.g. by calling pthread_mutex_init(), then the futex can be acquired again. A new waiter manages to enqueue itself on the pi_state w/o damage, but on unlock the kernel dereferences pi_state->owner and oopses. Prevent this by checking pi_state->owner in the unlock path. If pi_state->owner is not current we know that user space manipulated the futex value. Ignore the mess and return -EINVAL. This catches the above case and also the case where a task hijacks the futex by setting the tid value and then tries to unlock it. Reported-by: Jermome Marchand Signed-off-by: Thomas Gleixner Acked-by: Darren Hart Acked-by: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 4f7ce5b4140026b628cdc8ec983616efba2f1cd0 Author: Thomas Gleixner Date: Wed Feb 3 09:33:05 2010 +0100 futex: Handle futex value corruption gracefully commit 59647b6ac3050dd964bc556fe6ef22f4db5b935c upstream. The WARN_ON in lookup_pi_state which complains about a mismatch between pi_state->owner->pid and the pid which we retrieved from the user space futex is completely bogus. The code just emits the warning and then continues despite the fact that it detected an inconsistent state of the futex. A conveniant way for user space to spam the syslog. Replace the WARN_ON by a consistency check. If the values do not match return -EINVAL and let user space deal with the mess it created. This also fixes the missing task_pid_vnr() when we compare the pi_state->owner pid with the futex value. Reported-by: Jermome Marchand Signed-off-by: Thomas Gleixner Acked-by: Darren Hart Acked-by: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 45468a60ffdcc00758b849e651adc2329c86fd85 Author: Linus Torvalds Date: Fri Feb 5 16:16:50 2010 -0800 Fix potential crash with sys_move_pages commit 6f5a55f1a6c5abee15a0e878e5c74d9f1569b8b0 upstream. We incorrectly depended on the 'node_state/node_isset()' functions testing the node range, rather than checking it explicitly. That's not reliable, even if it might often happen to work. So do the proper explicit test. Reported-by: Marcus Meissner Acked-and-tested-by: Brice Goglin Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman