commit 08bc43274a5d49224065a6f170f6c7d83befee09 Author: Greg Kroah-Hartman Date: Sun Aug 16 14:30:06 2009 -0700 Linux 2.6.27.30 commit 75a171628ce5a670db5adbf59270fb3d2fe673fa Author: Trond Myklebust Date: Wed Aug 12 09:12:30 2009 -0400 NFS: Fix an O_DIRECT Oops... commit 1ae88b2e446261c038f2c0c3150ffae142b227a2 upstream. We can't call nfs_readdata_release()/nfs_writedata_release() without first initialising and referencing args.context. Doing so inside nfs_direct_read_schedule_segment()/nfs_direct_write_schedule_segment() causes an Oops. We should rather be calling nfs_readdata_free()/nfs_writedata_free() in those cases. Looking at the O_DIRECT code, the "struct nfs_direct_req" is already referencing the nfs_open_context for us. Since the readdata and writedata structures carry a reference to that, we can simplify things by getting rid of the extra nfs_open_context references, so that we can replace all instances of nfs_readdata_release()/nfs_writedata_release(). Reported-by: Catalin Marinas Signed-off-by: Trond Myklebust Tested-by: Catalin Marinas Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b70cadcb8e5bd341dfc2e88a749d7110bfc8200d Author: Linus Torvalds Date: Thu Aug 13 08:28:36 2009 -0700 Make sock_sendpage() use kernel_sendpage() commit e694958388c50148389b0e9b9e9e8945cf0f1b98 upstream. kernel_sendpage() does the proper default case handling for when the socket doesn't have a native sendpage implementation. Now, arguably this might be something that we could instead solve by just specifying that all protocols should do it themselves at the protocol level, but we really only care about the common protocols. Does anybody really care about sendpage on something like Appletalk? Not likely. Acked-by: David S. Miller Acked-by: Julien TINNES Acked-by: Tavis Ormandy Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 60634e4b830850bb38016f1e6a7a7358eba8118c Author: Oleg Nesterov Date: Fri Jul 10 03:27:38 2009 +0200 mm_for_maps: shift down_read(mmap_sem) to the caller commit 00f89d218523b9bf6b522349c039d5ac80aa536d upstream. mm_for_maps() takes ->mmap_sem after security checks, this looks strange and obfuscates the locking rules. Move this lock to its single caller, m_start(). Signed-off-by: Oleg Nesterov Acked-by: Serge Hallyn Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit a79c30e57c0eac03aae8be4649958f8592141d20 Author: Oleg Nesterov Date: Tue Jun 23 21:25:32 2009 +0200 mm_for_maps: simplify, use ptrace_may_access() commit 13f0feafa6b8aead57a2a328e2fca6a5828bf286 upstream. It would be nice to kill __ptrace_may_access(). It requires task_lock(), but this lock is only needed to read mm->flags in the middle. Convert mm_for_maps() to use ptrace_may_access(), this also simplifies the code a little bit. Also, we do not need to take ->mmap_sem in advance. In fact I think mm_for_maps() should not play with ->mmap_sem at all, the caller should take this lock. With or without this patch, without ->cred_guard_mutex held we can race with exec() and get the new ->mm but check old creds. Signed-off-by: Oleg Nesterov Reviewed-by: Serge Hallyn Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 3e16ba377737c5815cd1d6315c3cffe9c6e388ad Author: Alan Stern Date: Thu Jul 30 15:28:14 2009 -0400 USB: usbfs: fix -ENOENT error code to be -ENODEV commit 01105a246345f011fde64d24a601090b646e9e4c upstream. This patch (as1272) changes the error code returned when an open call for a USB device node fails to locate the corresponding device. The appropriate error code is -ENODEV, not -ENOENT. Signed-off-by: Alan Stern CC: Kay Sievers Signed-off-by: Greg Kroah-Hartman commit 11c1ac9a64dd2d3ff5a7dc3bce57acf61bd8cd7f Author: Rogerio Brito Date: Thu Aug 6 15:20:19 2009 -0700 USB: storage: include Prolific Technology USB drive in unusual_devs list commit c15e3ca1d822abba78c00b1ffc3e7b382a50396e upstream. Add a quirk entry for the Leading Driver UD-11 usb flash drive. As Alan Stern told me, the device doesn't deal correctly with the locking media feature of the device, and this patch incorporates it. Compiled, tested, working. Signed-off-by: Rogerio Brito Cc: Phil Dibowitz Cc: Alan Stern Cc: Robert Hancock Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7ee7545fb1657b2ea03217a1d1b8735f104206a0 Author: Dhaval Vasa Date: Fri Aug 7 17:26:49 2009 +0530 USB: ftdi_sio: add product_id for Marvell OpenRD Base, Client commit 50d0678e2026c18e4147f0b16b5853113659b82d upstream. reference: http://www.open-rd.org Signed-off-by: Dhaval Vasa Signed-off-by: Greg Kroah-Hartman commit 3855ccabe0fdf825164826afcff618033ed83355 Author: Marko Hänninen Date: Fri Jul 31 22:32:39 2009 +0300 USB: ftdi_sio: add vendor and product id for Bayer glucose meter serial converter cable commit c47aacc67a3d26dfab9c9b8965975ed2b2010b30 upstream. Attached patch adds USB vendor and product IDs for Bayer's USB to serial converter cable used by Bayer blood glucose meters. It seems to be a FT232RL based device and works without any problem with ftdi_sio driver when this patch is applied. See: http://winglucofacts.com/cables/ Signed-off-by: Marko Hänninen Signed-off-by: Greg Kroah-Hartman commit 0517d13f5206dcb7c09087ee3d7e522fdc9af2e3 Author: Michael Buesch Date: Wed Jul 29 11:39:03 2009 +0200 USB: devio: Properly do access_ok() checks commit 18753ebc8a98efe0e8ff6167afb31cef220c8e50 upstream. access_ok() checks must be done on every part of the userspace structure that is accessed. If access_ok() on one part of the struct succeeded, it does not imply it will succeed on other parts of the struct. (Does depend on the architecture implementation of access_ok()). This changes the __get_user() users to first check access_ok() on the data structure. Signed-off-by: Michael Buesch Cc: Pete Zaitcev Signed-off-by: Greg Kroah-Hartman commit 58d92bedd89043cf0ade84a902130078dc9094b8 Author: Linus Torvalds Date: Thu Aug 6 15:09:34 2009 -0700 flat: fix uninitialized ptr with shared libs commit 3440625d78711bee41a84cf29c3d8c579b522666 upstream. The new credentials code broke load_flat_shared_library() as it now uses an uninitialized cred pointer. Reported-by: Bernd Schmidt Tested-by: Bernd Schmidt Cc: Mike Frysinger Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 165e5c818c62d7315229fef15c06ed937bd6d04a Author: Eric Dumazet Date: Thu Aug 6 15:09:28 2009 -0700 execve: must clear current->clear_child_tid commit 9c8a8228d0827e0d91d28527209988f672f97d28 upstream. While looking at Jens Rosenboom bug report (http://lkml.org/lkml/2009/7/27/35) about strange sys_futex call done from a dying "ps" program, we found following problem. clone() syscall has special support for TID of created threads. This support includes two features. One (CLONE_CHILD_SETTID) is to set an integer into user memory with the TID value. One (CLONE_CHILD_CLEARTID) is to clear this same integer once the created thread dies. The integer location is a user provided pointer, provided at clone() time. kernel keeps this pointer value into current->clear_child_tid. At execve() time, we should make sure kernel doesnt keep this user provided pointer, as full user memory is replaced by a new one. As glibc fork() actually uses clone() syscall with CLONE_CHILD_SETTID and CLONE_CHILD_CLEARTID set, chances are high that we might corrupt user memory in forked processes. Following sequence could happen: 1) bash (or any program) starts a new process, by a fork() call that glibc maps to a clone( ... CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID ...) syscall 2) When new process starts, its current->clear_child_tid is set to a location that has a meaning only in bash (or initial program) context (&THREAD_SELF->tid) 3) This new process does the execve() syscall to start a new program. current->clear_child_tid is left unchanged (a non NULL value) 4) If this new program creates some threads, and initial thread exits, kernel will attempt to clear the integer pointed by current->clear_child_tid from mm_release() : if (tsk->clear_child_tid && !(tsk->flags & PF_SIGNALED) && atomic_read(&mm->mm_users) > 1) { u32 __user * tidptr = tsk->clear_child_tid; tsk->clear_child_tid = NULL; /* * We don't check the error code - if userspace has * not set up a proper pointer then tough luck. */ << here >> put_user(0, tidptr); sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0); } 5) OR : if new program is not multi-threaded, but spied by /proc/pid users (ps command for example), mm_users > 1, and the exiting program could corrupt 4 bytes in a persistent memory area (shm or memory mapped file) If current->clear_child_tid points to a writeable portion of memory of the new program, kernel happily and silently corrupts 4 bytes of memory, with unexpected effects. Fix is straightforward and should not break any sane program. Reported-by: Jens Rosenboom Acked-by: Linus Torvalds Signed-off-by: Eric Dumazet Signed-off-by: Oleg Nesterov Cc: Peter Zijlstra Cc: Sonny Rao Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Ulrich Drepper Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9ac3664242f11fb38ea5029712bc77ee317fe38c Author: Eric Sandeen Date: Thu Aug 6 15:07:37 2009 -0700 compat_ioctl: hook up compat handler for FIEMAP ioctl commit 69130c7cf96ea853dc5be599dd6a4b98907d39cc upstream. The FIEMAP_IOC_FIEMAP mapping ioctl was missing a 32-bit compat handler, which means that 32-bit suerspace on 64-bit kernels cannot use this ioctl command. The structure is nicely aligned, padded, and sized, so it is just this simple. Tested w/ 32-bit ioctl tester (from Josef) on a 64-bit kernel on ext4. Signed-off-by: Eric Sandeen Cc: Cc: Mark Lord Cc: Arnd Bergmann Cc: Josef Bacik Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 32c987dd4d271c3ec49da10a07ce33aaa76721ca Author: Greg Kroah-Hartman Date: Tue Feb 24 23:52:24 2009 -0800 asix: new device ids commit fef7cc0893146550b286b13c0e6e914556142730 upstream. This patch adds two new device ids to the asix driver. One comes directly from the asix driver on their web site, the other was reported by Armani Liao as needed for the MSI X320 to get the driver to work properly for it. Reported-by: Armani Liao Signed-off-by: Greg Kroah-Hartman Signed-off-by: David S. Miller commit 941afb2843070a0af16fb56d09f3e2364ff94cf8 Author: Mark Langsdorf Date: Sun Jul 5 15:50:52 2009 -0500 x86: enable GART-IOMMU only after setting up protection methods commit fe2245c905631a3a353504fc04388ce3dfaf9d9e upstream. The current code to set up the GART as an IOMMU enables GART translations before it removes the aperture from the kernel memory map, sets the GART PTEs to UC, sets up the guard and scratch pages, or does a wbinvd(). This leaves the possibility of cache aliasing open and can cause system crashes. Re-order the code so as to enable the GART translations only after all safeguards are in place and the tlb has been flushed. AMD has tested this patch on both Istanbul systems and 1st generation Opteron systems with APG enabled and seen no adverse effects. Istanbul systems with HT Assist enabled sometimes see MCE errors due to cache artifacts with the unmodified code. Signed-off-by: Mark Langsdorf Cc: Joerg Roedel Cc: akpm@linux-foundation.org Cc: jbarnes@virtuousgeek.org Signed-off-by: Ingo Molnar commit 91b129d1013e5ce7977f323a69d82bd0ad54b439 Author: Stefan Richter Date: Wed Jul 29 21:27:39 2009 +0200 firewire: sbp2: add support for disks >2 TB (and 16 bytes long CDBs) Commit af2719415a5ceae06f2a6d33e78b555e64697fc8 upstream. Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 57d89e280061b8c1d994baa4ba1535239d198d54 Author: Stefan Richter Date: Wed Jul 29 21:29:13 2009 +0200 ieee1394: sbp2: add support for disks >2 TB (and 16 bytes long CDBs) Commit ebbb16bffa646f853899ef3fdc0ac7abab888703 upstream. Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 2614443191474e4c8619bf59665f9ef820e5276c Author: Helge Deller Date: Wed Jul 29 23:17:20 2009 +0200 parisc: ensure broadcast tlb purge runs single threaded commit e82a3b75127188f20c7780bec580e148beb29da7 upstream parisc: ensure broadcast tlb purge runs single threaded The TLB flushing functions on hppa, which causes PxTLB broadcasts on the system bus, needs to be protected by irq-safe spinlocks to avoid irq handlers to deadlock the kernel. The deadlocks only happened during I/O intensive loads and triggered pretty seldom, which is why this bug went so long unnoticed. Signed-off-by: Helge Deller [edited to use spin_lock_irqsave on UP as well since we'd been locking there all this time anyway, --kyle] Signed-off-by: Kyle McMartin Signed-off-by: Greg Kroah-Hartman commit 04101e4e4ef4ff5035ce5ad4510db02eb54c4985 Author: H. Peter Anvin Date: Mon Aug 3 16:33:40 2009 -0700 x86: fix assembly constraints in native_save_fl() commit f1f029c7bfbf4ee1918b90a431ab823bed812504 upstream. From Gabe Black in bugzilla 13888: native_save_fl is implemented as follows: 11static inline unsigned long native_save_fl(void) 12{ 13 unsigned long flags; 14 15 asm volatile("# __raw_save_flags\n\t" 16 "pushf ; pop %0" 17 : "=g" (flags) 18 : /* no input */ 19 : "memory"); 20 21 return flags; 22} If gcc chooses to put flags on the stack, for instance because this is inlined into a larger function with more register pressure, the offset of the flags variable from the stack pointer will change when the pushf is performed. gcc doesn't attempt to understand that fact, and address used for pop will still be the same. It will write to somewhere near flags on the stack but not actually into it and overwrite some other value. I saw this happen in the ide_device_add_all function when running in a simulator I work on. I'm assuming that some quirk of how the simulated hardware is set up caused the code path this is on to be executed when it normally wouldn't. A simple fix might be to change "=g" to "=r". Reported-by: Gabe Black Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit b2d13246b6eb439aee5baf8552b9463b553b5bc9 Author: Giacomo Lozito Date: Mon Jul 13 23:23:33 2009 +0200 USB: storage: raise timeout in usb_stor_Bulk_max_lun commit 7a777919bbeec3eac1d7904a728a60e9c2bb9c67 upstream. Requests to get max LUN, for certain USB storage devices, require a longer timeout before a correct reply is returned. This happens for a Realtek USB Card Reader (0bda:0152), which has a max LUN of 3 but is set to 0, thus losing functionality, because of the timeout occurring too quickly. Raising the timeout value fixes the issue and might help other devices to return a correct max LUN value as well. Signed-off-by: Giacomo Lozito Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit cbebf4050409023207a162e67e8a473538314d5b Author: Henrique de Moraes Holschuh Date: Sat Aug 1 12:04:17 2009 -0300 thinkpad-acpi: disable broken bay and dock subdrivers commit 550e7fd8afb7664ae7cedb398c407694e2bf7d3c upstream. Currently, the ThinkPad-ACPI bay and dock drivers are completely broken, and cause a NULL pointer derreference in kernel mode (and, therefore, an OOPS) when they try to issue events (i.e. on dock, undock, bay ejection, etc). OTOH, the standard ACPI dock driver can handle the hotplug bays and docks of the ThinkPads just fine (including batteries) as of 2.6.27. In fact, it does a much better job of it than thinkpad-acpi ever did. It is just not worth the hassle to find a way to fix this crap without breaking the (deprecated) thinkpad-acpi dock/bay ABI. This is old, deprecated code that sees little testing or use. As a quick fix suitable for -stable backports, mark the thinkpad-acpi bay and dock subdrivers as BROKEN in Kconfig. The dead code will be removed by a later patch. This fixes bugzilla #13669, and should be applied to 2.6.27 and later. Signed-off-by: Henrique de Moraes Holschuh Reported-by: Joerg Platte Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 16fe15dbef13d99bc137ceedf0c0328316b4cbdf Author: Peter Oberparleiter Date: Tue Jul 14 17:56:15 2009 +0200 sysfs: fix hardlink count on device_move commit 0f58b44582001c8bcdb75f36cf85ebbe5170e959 upstream. Update directory hardlink count when moving kobjects to a new parent. Fixes the following problem which occurs when several devices are moved to the same parent and then unregistered: > ls -laF /sys/devices/css0/defunct/ > total 0 > drwxr-xr-x 4294967295 root root 0 2009-07-14 17:02 ./ > drwxr-xr-x 114 root root 0 2009-07-14 17:02 ../ > drwxr-xr-x 2 root root 0 2009-07-14 17:01 power/ > -rw-r--r-- 1 root root 4096 2009-07-14 17:01 uevent Signed-off-by: Peter Oberparleiter Signed-off-by: Greg Kroah-Hartman commit 93b9fd4cd1e3fdaadc3b685fb938ec134a0cfb2f Author: Mel Gorman Date: Wed Jul 29 15:02:04 2009 -0700 page-allocator: preserve PFN ordering when __GFP_COLD is set commit e084b2d95e48b31aa45f9c49ffc6cdae8bdb21d4 upstream. Fix a post-2.6.24 performace regression caused by 3dfa5721f12c3d5a441448086bee156887daa961 ("page-allocator: preserve PFN ordering when __GFP_COLD is set"). Narayanan reports "The regression is around 15%. There is no disk controller as our setup is based on Samsung OneNAND used as a memory mapped device on a OMAP2430 based board." The page allocator tries to preserve contiguous PFN ordering when returning pages such that repeated callers to the allocator have a strong chance of getting physically contiguous pages, particularly when external fragmentation is low. However, of the bulk of the allocations have __GFP_COLD set as they are due to aio_read() for example, then the PFNs are in reverse PFN order. This can cause performance degration when used with IO controllers that could have merged the requests. This patch attempts to preserve the contiguous ordering of PFNs for users of __GFP_COLD. Signed-off-by: Mel Gorman Reported-by: Narayananu Gopalakrishnan Tested-by: Narayanan Gopalakrishnan Cc: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f74ad8bec9d9de38c622d3cbfea5edd371a632eb Author: John Stoffel Date: Tue Aug 4 22:10:17 2009 +0200 Make SCSI SG v4 driver enabled by default and remove EXPERIMENTAL dependency, since udev depends on BSG commit 14d9fa352592582e457cf75022202766baac1348 upstream. Make Block Layer SG support v4 the default, since recent udev versions depend on this to access serial numbers and other low level info properly. This should be backported to older kernels as well, since most distros have enabled this for a long time. Signed-off-by: John Stoffel Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 25029e626276e1dc5dd58436d230b84b49a38e71 Author: Tom Peng Date: Wed Jul 1 20:37:26 2009 +0800 SCSI: libsas: reuse the original port when hotplugging phys in wide ports commit 5381837f125cc62ad703fbcdfcd7566fc81fd404 upstream. There's a hotplug problem in the way libsas allocates ports: it loops over the available ports first trying to add to an existing for a wide port and otherwise allocating the next free port. This scheme only works if the port array is packed from zero, which fails if a port gets hot unplugged and the array becomes sparse. In that case, a new port is formed even if there's a wide port it should be part of. Fix this by creating two loops over all the ports: the first to see if the phy should be part of a wide port and the second to form a new port in an empty port slot. Signed-off-by: Tom Peng Signed-off-by: Jack Wang Signed-off-by: Lindar Liu Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit dd2d70a7ba542030c152cdc224d3d303e9b6e21a Author: Michele Jr De Candia Date: Tue Jul 28 16:33:03 2009 +0200 i2c/tsl2550: Fix lux value in dark environment commit 96f699ad09c8b3c55cd229506a9add0047838e3e upstream. I've tested TSL2550 driver and I've found a bug: when light is off, returned value from tsl2550_calculate_lux function is -1 when it should be 0 (sensor correctly read that light was off). I think the bug is that a zero c0 value (approximated value of ch0) is misinterpreted as an error. Signed-off-by: Michele Jr De Candia Acked-by: Rodolfo Giometti Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 49a8cf1d49e9c956fcbc999018126804309887d7 Author: Jean Delvare Date: Tue Jul 28 16:31:39 2009 +0200 hwmon: (smsc47m1) Differentiate between LPC47M233 and LPC47M292 commit 1b54ab450b180eaeeb0eee6f0f64349246a22c14 upstream. The SMSC LPC47M233 and LPC47M292 chips have the same device ID but are not compatible. Signed-off-by: Jean Delvare Cc: Juerg Haefliger Acked-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 7514a6632bbf548999869dc7d873f52ddf917856 Author: Eric Sandeen Date: Wed Jul 29 15:02:16 2009 -0700 hugetlbfs: fix i_blocks accounting commit e4c6f8bed01f9f9a5c607bd689bf67e7b8a36bd8 upstream. As reported in Red Hat bz #509671, i_blocks for files on hugetlbfs get accounting wrong when doing something like: $ > foo $ date > foo date: write error: Invalid argument $ /usr/bin/stat foo File: `foo' Size: 0 Blocks: 18446744073709547520 IO Block: 2097152 regular ... This is because hugetlb_unreserve_pages() is unconditionally removing blocks_per_huge_page(h) on each call rather than using the freed amount. If there were 0 blocks, it goes negative, resulting in the above. This is a regression from commit a5516438959d90b071ff0a484ce4f3f523dc3152 ("hugetlb: modular state for hugetlb page size") which did: - inode->i_blocks -= BLOCKS_PER_HUGEPAGE * freed; + inode->i_blocks -= blocks_per_huge_page(h); so just put back the freed multiplier, and it's all happy again. Signed-off-by: Eric Sandeen Acked-by: Andi Kleen Cc: William Lee Irwin III Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman