commit 616b99aeaaf585e29029e15a2b81a4d92672ead2 Author: Greg Kroah-Hartman Date: Thu Jan 28 15:21:45 2010 -0800 Linux 2.6.27.45 commit ad9888834c693ec18a9c218409fa3c21a5e30c17 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 244e540e0c37b917a62e56e733c10fb7c85767ce Author: Christian Borntraeger Date: Thu Jan 21 12:19:07 2010 +0100 KVM: S390: fix potential array overrun in intercept handling commit 062d5e9b0d714f449b261bb522eadaaf6f00f438 upstream. kvm_handle_sie_intercept uses a jump table to get the intercept handler for a SIE intercept. Static code analysis revealed a potential problem: the intercept_funcs jump table was defined to contain (0x48 >> 2) entries, but we only checked for code > 0x48 which would cause an off-by-one array overflow if code == 0x48. Use the compiler and ARRAY_SIZE to automatically set the limits. Signed-off-by: Christian Borntraeger Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit f653e714dfd24c86d63e6f661a61cd167a2535e6 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 4fbebe26d7a5eed6c1900bf2142b68af7df38462 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 5b3363926eed5839fdc84055d20f9153980d4b5f 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 29691f9ead70fb43b39defe6503e2a8e1de12dad 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 76c5f486172fd061715f21c926d61f7e83ea6377 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 951e8ab57d5a08fd083997e5bf674c3d0e81abff 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 4d3b891bdf8a0cf1ef02938aea9fc353ce2a4b68 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 b3f881085c970a6c59d3e594e58278a4a00122da 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 5051769bea011902cf5f76c92bbb33accb015306 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 3282903d24c660f40f497d868fce151448320715 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