commit e34454757fb87ecac1f76e4169cff6b74ba7ec44 Author: Chris Wright Date: Mon Apr 27 10:37:11 2009 -0700 Linux 2.6.29.2 commit 5f9645212515279c4876ff0200fe7fa51dfb57ce Author: Brian Haley Date: Mon Apr 13 00:11:30 2009 -0700 Bonding: fix zero address hole bug in arp_ip_target list upstream commit: 5a31bec014449dc9ca994e4c1dbf2802b7ca458a Fix a zero address hole bug in the bonding arp_ip_target list that was causing the bond to ignore ARP replies (bugz 13006). Instead of just setting the array entry to zero, we now copy any additional entries down one slot, putting the zero entry at the end. With this change we can now have all the loops that walk the array stop when they hit a zero since there will be no addresses after it. Changes are based in part on code fragment provided in kernel: bugzilla 13006: http://bugzilla.kernel.org/show_bug.cgi?id=13006 by Steve Howard Signed-off-by: Brian Haley Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 9fc79ab9a371b45166d80ef18411ea47cf8e3195 Author: Michal Schmidt Date: Tue Apr 14 15:16:55 2009 -0700 skge: fix occasional BUG during MTU change upstream commit: d119b3927994e3d620d6adb0dd1ea6bf24427875 The BUG_ON(skge->tx_ring.to_use != skge->tx_ring.to_clean) in skge_up() was sometimes observed when setting MTU. skge_down() disables the TX queue, but then reenables it by mistake via skge_tx_clean(). Fix it by moving the waking of the queue from skge_tx_clean() to the other caller. And to make sure start_xmit is not in progress on another CPU, skge_down() should call netif_tx_disable(). The bug was reported to me by Jiri Jilek whose Debian system sometimes failed to boot. He tested the patch and the bug did not happen anymore. Signed-off-by: Michal Schmidt Acked-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 24016c735e651f179692432f18176348caeb82b0 Author: Eric Paris Date: Tue Apr 21 21:20:02 2009 +0000 scsi: mpt: suppress debugobjects warning upstream commit: b298cecb3deddf76d60022473a57f1cb776cbdcd Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13133 ODEBUG: object is on stack, but not annotated ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:253 __debug_object_init+0x1f3/0x276() Hardware name: VMware Virtual Platform Modules linked in: mptspi(+) mptscsih mptbase scsi_transport_spi ext3 jbd mbcache Pid: 540, comm: insmod Not tainted 2.6.28-mm1 #2 Call Trace: [] warn_slowpath+0x74/0x8a [] ? start_critical_timing+0x96/0xb7 [] ? _spin_unlock_irqrestore+0x2f/0x3c [] ? trace_hardirqs_off_caller+0x18/0xaf [] ? trace_hardirqs_off+0xb/0xd [] ? _spin_unlock_irqrestore+0x2f/0x3c [] ? release_console_sem+0x1a5/0x1ad [] __debug_object_init+0x1f3/0x276 [] debug_object_init+0x13/0x17 [] init_timer+0x10/0x1a [] mpt_config+0x1c1/0x2b7 [mptbase] [] ? kmalloc+0x8/0xa [mptbase] [] ? kmalloc+0x8/0xa [mptbase] [] mpt_do_ioc_recovery+0x950/0x1212 [mptbase] [] ? __lock_acquire+0xa69/0xacc [] ? _spin_unlock_irqrestore+0x36/0x3c [] ? _spin_unlock_irq+0x22/0x26 [] ? string+0x2b/0x76 [] ? vsnprintf+0x338/0x7b3 [] ? __lock_acquire+0xa69/0xacc [] ? _spin_unlock_irqrestore+0x2f/0x3c [] ? __lock_acquire+0xa69/0xacc [] ? debug_check_no_locks_freed+0xeb/0x105 [] ? _spin_unlock_irqrestore+0x36/0x3c [] ? debug_check_no_locks_freed+0x2a/0x105 [] ? lock_release_holdtime+0x43/0x48 [] ? up_read+0x16/0x29 [] ? pci_get_slot+0x66/0x72 [] mpt_attach+0x881/0x9b1 [mptbase] [] mptspi_probe+0x11/0x354 [mptspi] Noticing that every caller of mpt_config has its CONFIGPARMS struct declared on the stack and thus the &pCfg->timer is always on the stack I changed init_timer() to init_timer_on_stack() and it seems to have shut up..... Cc: "Moore, Eric Dean" Cc: James Bottomley Cc: Thomas Gleixner Acked-by: "Desai, Kashyap" Cc: [2.6.29.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 5a9b5af39e948919f272867516faa61c093124f6 Author: Akinobu Mita Date: Tue Apr 21 21:20:04 2009 +0000 hugetlbfs: return negative error code for bad mount option upstream commit: c12ddba09394c60e1120e6997794fa6ed52da884 This fixes the following BUG: # mount -o size=MM -t hugetlbfs none /huge hugetlbfs: Bad value 'MM' for mount option 'size=MM' ------------[ cut here ]------------ kernel BUG at fs/super.c:996! Due to BUG_ON(!mnt->mnt_sb); in vfs_kern_mount(). Also, remove unused #include Cc: William Irwin Cc: Signed-off-by: Akinobu Mita Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 52f8cf35ef8716fbcb00ffe3a680d2a4c54e412d Author: Trond Myklebust Date: Tue Apr 21 21:20:08 2009 +0000 NFS: Fix the XDR iovec calculation in nfs3_xdr_setaclargs upstream commit: 8340437210390676f687633a80e3748c40885dc8 Commit ae46141ff08f1965b17c531b571953c39ce8b9e2 (NFSv3: Fix posix ACL code) introduces a bug in the calculation of the XDR header iovec. In the case where we are inlining the acls, we need to adjust the length of the iovec req->rq_svec, in addition to adjusting the total buffer length. Tested-by: Leonardo Chiquitto Tested-by: Suresh Jayaraman Signed-off-by: Trond Myklebust Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit d6af2381754182d727fb4682e785f56ae8508210 Author: Herbert Xu Date: Tue Apr 21 04:31:50 2009 -0700 gso: Fix support for linear packets upstream commit: 2f181855a0b3c2b39314944add7b41c15647cf86 When GRO/frag_list support was added to GSO, I made an error which broke the support for segmenting linear GSO packets (GSO packets are normally non-linear in the payload). These days most of these packets are constructed by the tun driver, which prefers to allocate linear memory if possible. This is fixed in the latest kernel, but for 2.6.29 and earlier it is still the norm. Therefore this bug causes failures with GSO when used with tun in 2.6.29. Reported-by: James Huang Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 0702b646e5bdc16af64ef6f663e5275a02bf40cd Author: Shaohua Li Date: Mon Apr 20 10:08:35 2009 +1000 agp: zero pages before sending to userspace upstream commit: 59de2bebabc5027f93df999d59cc65df591c3e6e CVE-2009-1192 AGP pages might be mapped into userspace finally, so the pages should be set to zero before userspace can use it. Otherwise there is potential information leakage. Signed-off-by: Shaohua Li Signed-off-by: Dave Airlie Signed-off-by: Chris Wright commit 7b0e3850488bbd218b6ea4cc0e5c6e549995a6f7 Author: Marcelo Tosatti Date: Sun Apr 19 18:05:04 2009 +0000 virtio: fix suspend when using virtio_balloon upstream commit: 84a139a985300901dfad99bd93c7345d180af860 Break out of wait_event_interruptible() if freezing has been requested, in the vballoon thread. Without this change vballoon refuses to stop and the system can't suspend. Signed-off-by: Marcelo Tosatti Signed-off-by: Rusty Russell Cc: stable@kernel.org Signed-off-by: Chris Wright commit cbe8fe4ae7f8bcc410c105810b263abf24439a53 Author: Samuel Thibault Date: Sun Apr 19 18:05:02 2009 +0000 Revert "console ASCII glyph 1:1 mapping" upstream commit: c0b7988200a82290287c6f4cd49585007f73175a This reverts commit 1c55f18717304100a5f624c923f7cb6511b4116d. Ingo Brueckl was assuming that reverting to 1:1 mapping for chars >= 128 was not useful, but it happens to be: due to the limitations of the Linux console, when a blind user wants to read BIG5 on it, he has no other way than loading a font without SFM and let the 1:1 mapping permit the screen reader to get the BIG5 encoding. Signed-off-by: Samuel Thibault Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit fb1c95cd6b1b0522bf0f7bedc0e1abc3b05d0607 Author: Dmitry Torokhov Date: Mon Apr 13 15:27:49 2009 -0700 Input: gameport - fix attach driver code upstream commit: 4ced8e7cb990a2c3bbf0ac7f27b35c890e7ce895 The commit 6902c0bead4ce266226fc0c5b3828b850bdc884a that moved driver registration out of kgameportd thread was incomplete and did not add the code necessary to actually attach driver to already registered devices, rectify that. Signed-off-by: Dmitry Torokhov Signed-off-by: Chris Wright commit bc7bc5df2deb79df8f3686c81e2e5f43710efb18 Author: Pallipadi, Venkatesh Date: Sat Apr 18 11:08:04 2009 +0200 x86, PAT: Remove page granularity tracking for vm_insert_pfn maps upstream commit: 4b065046273afa01ec8e3de7da407e8d3599251d This change resolves the problem of too many single page entries in pat_memtype_list and "freeing invalid memtype" errors with i915, reported here: http://marc.info/?l=linux-kernel&m=123845244713183&w=2 Remove page level granularity track and untrack of vm_insert_pfn. memtype tracking at page granularity does not scale and cleaner approach would be for the driver to request a type for a bigger IO address range or PCI io memory range for that device, either at mmap time or driver init time and just use that type during vm_insert_pfn. This patch just removes the track/untrack of vm_insert_pfn. That means we will be in same state as 2.6.28, with respect to these APIs. Newer APIs for the drivers to request a memtype for a bigger region is coming soon. [ Impact: fix Xorg startup warnings and hangs ] Reported-by: Arkadiusz Miskiewicz Tested-by: Arkadiusz Miskiewicz Signed-off-by: Venkatesh Pallipadi Signed-off-by: Suresh Siddha Cc: Jesse Barnes LKML-Reference: <20090408223716.GC3493@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright commit e8c4851a2ad9c7ada702141e621f127cb203c41e Author: Amit Shah Date: Fri Apr 17 19:40:13 2009 -0300 KVM: is_long_mode() should check for EFER.LMA upstream commit: 41d6af119206e98764b4ae6d264d63acefcf851e is_long_mode currently checks the LongModeEnable bit in EFER instead of the LongModeActive bit. This is wrong, but we survived this till now since it wasn't triggered. This breaks guests that go from long mode to compatibility mode. This is noticed on a solaris guest and fixes bug #1842160 Signed-off-by: Amit Shah Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit 7c3dbe6360ed32c9433524b7744d58ece1b605ad Author: Amit Shah Date: Fri Apr 17 19:40:12 2009 -0300 KVM: VMX: Update necessary state when guest enters long mode upstream commit: 401d10dee083bda281f2fdcdf654080313ba30ec setup_msrs() should be called when entering long mode to save the shadow state for the 64-bit guest state. Using vmx_set_efer() in enter_lmode() removes some duplicated code and also ensures we call setup_msrs(). We can safely pass the value of shadow_efer to vmx_set_efer() as no other bits in the efer change while enabling long mode (guest first sets EFER.LME, then sets CR0.PG which causes a vmexit where we activate long mode). With this fix, is_long_mode() can check for EFER.LMA set instead of EFER.LME and 5e23049e86dd298b72e206b420513dbc3a240cd9 can be reverted. Signed-off-by: Amit Shah Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit 18020173f9665487de72c53eca76a1689f2afb48 Author: Weidong Han Date: Fri Apr 17 19:40:11 2009 -0300 KVM: fix kvm_vm_ioctl_deassign_device upstream commit: 4a906e49f103c2e544148a209ba1db316510799f only need to set assigned_dev_id for deassignment, use match->flags to judge and deassign it. Acked-by: Mark McLoughlin Signed-off-by: Weidong Han Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit a6d2078da9aeb83f21277573b240290fa196b5f9 Author: Joerg Roedel Date: Fri Apr 17 19:40:10 2009 -0300 KVM: MMU: handle compound pages in kvm_is_mmio_pfn upstream commit: fc5659c8c6b6c4e02ac354b369017c1bf231f347 The function kvm_is_mmio_pfn is called before put_page is called on a page by KVM. This is a problem when when this function is called on some struct page which is part of a compund page. It does not test the reserved flag of the compound page but of the struct page within the compount page. This is a problem when KVM works with hugepages allocated at boot time. These pages have the reserved bit set in all tail pages. Only the flag in the compount head is cleared. KVM would not put such a page which results in a memory leak. Signed-off-by: Joerg Roedel Acked-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit fc66cf4790189b5ec4f8b9e8aacc8d37cc8e3daa Author: Avi Kivity Date: Fri Apr 17 19:40:09 2009 -0300 KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked upstream commit: 4780c65904f0fc4e312ee2da9383eacbe04e61ea While the PIT is masked the guest cannot ack the irq, so the reinject logic will never allow the interrupt to be injected. Fix by resetting the reinjection counters on unmask. Unbreaks Xen. Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit 6f771da5da5f0b8e04b7003c823af6fdb00c57e5 Author: Avi Kivity Date: Fri Apr 17 19:40:08 2009 -0300 KVM: Interrupt mask notifiers for ioapic upstream commit: 75858a84a6207f5e60196f6bbd18fde4250e5759 Allow clients to request notifications when the guest masks or unmasks a particular irq line. This complements irq ack notifications, as the guest will not ack an irq line that is masked. Currently implemented for the ioapic only. Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit 1350e5c4945999cd31c6bdf050fb1b161c283d3c Author: Avi Kivity Date: Fri Apr 17 19:40:07 2009 -0300 KVM: Add CONFIG_HAVE_KVM_IRQCHIP upstream commit: 5d9b8e30f543a9f21a968a4cda71e8f6d1c66a61 Two KVM archs support irqchips and two don't. Add a Kconfig item to make selecting between the two models easier. Signed-off-by: Avi Kivity Signed-off-by: Chris Wright commit fda28853bc4bc053ef2fafb5c7d2a26e6ce4b4bf Author: Andrea Arcangeli Date: Fri Apr 17 19:40:06 2009 -0300 KVM: Fix missing smp tlb flush in invlpg upstream commit: 4539b35881ae9664b0e2953438dd83f5ee02c0b4 When kvm emulates an invlpg instruction, it can drop a shadow pte, but leaves the guest tlbs intact. This can cause memory corruption when swapping out. Without this the other cpu can still write to a freed host physical page. tlb smp flush must happen if rmap_remove is called always before mmu_lock is released because the VM will take the mmu_lock before it can finally add the page to the freelist after swapout. mmu notifier makes it safe to flush the tlb after freeing the page (otherwise it would never be safe) so we can do a single flush for multiple sptes invalidated. Cc: stable@kernel.org Signed-off-by: Andrea Arcangeli Acked-by: Marcelo Tosatti Signed-off-by: Avi Kivity [mtosatti: backport to 2.6.29] Signed-off-by: Chris Wright commit 35fe207a082d775b0bbaac3f49a9dc2d7c02779c Author: Alan Stern Date: Fri Apr 17 21:20:03 2009 +0000 USB: usb-storage: augment unusual_devs entry for Simple Tech/Datafab upstream commit: e4813eec8d47c8299d968bd5349dc881fa481c26 This patch (as1227) adds the MAX_SECTORS_64 flag to the unusual_devs entry for the Simple Tech/Datafab controller. This fixes Bugzilla #12882. Signed-off-by: Alan Stern Reported-and-tested-by: binbin Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 4be149f9b684906505d49932fd18e1f17721b30f Author: Oliver Neukum Date: Fri Apr 17 21:20:06 2009 +0000 USB: fix oops in cdc-wdm in case of malformed descriptors upstream commit: e13c594f3a1fc2c78e7a20d1a07974f71e4b448f cdc-wdm needs to ignore extremely malformed descriptors. Signed-off-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 082240d79158decfc9918b96487da38a750b4d1d Author: Peter Korsgaard Date: Fri Apr 17 21:20:07 2009 +0000 USB: ftdi_sio: add vendor/project id for JETI specbos 1201 spectrometer upstream commit: ae27d84351f1f3568118318a8c40ff3a154bd629 Signed-off-by: Peter Korsgaard Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 5c435c37e2652e5d066dc81fcc108a0dffbdb33d Author: Jonathan McDowell Date: Fri Apr 17 21:20:10 2009 +0000 usb gadget: fix ethernet link reports to ethtool upstream commit: 237e75bf1e558f7330f8deb167fa3116405bef2c The g_ether USB gadget driver currently decides whether or not there's a link to report back for eth_get_link based on if the USB link speed is set. The USB gadget speed is however often set even before the device is enumerated. It seems more sensible to only report a "link" if we're actually connected to a host that wants to talk to us. The patch below does this for me - tested with the PXA27x UDC driver. Signed-off-by: Jonathan McDowell Signed-off-by: David Brownell Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright commit 0857bb06065b5c5a51d205c4c04ec1202e27d399 Author: Ingo Molnar Date: Wed Apr 15 23:15:14 2009 +0200 x86: disable X86_PTRACE_BTS for now upstream commit: d45b41ae8da0f54aec0eebcc6f893ba5f22a1e8e Oleg Nesterov found a couple of races in the ptrace-bts code and fixes are queued up for it but they did not get ready in time for the merge window. We'll merge them in v2.6.31 - until then mark the feature as CONFIG_BROKEN. There's no user-space yet making use of this so it's not a big issue. Cc: Signed-off-by: Ingo Molnar [chrisw: trivial 2.6.29 backport] Signed-off-by: Chris Wright commit 43fce3f341cbe7c6d7a58699655b954bb4f7689c Author: FUJITA Tomonori Date: Mon Apr 6 20:55:06 2009 +0000 SCSI: sg: fix q->queue_lock on scsi_error_handler path upstream commit: 015640edb1f346e0b2eda703587c4cd1c310ec1d sg_rq_end_io() is called via rq->end_io. In some rare cases, sg_rq_end_io calls blk_put_request/blk_rq_unmap_user (when a program issuing a command has gone before the command completion; e.g. by interrupting a program issuing a command before the command completes). We can't call blk_put_request/blk_rq_unmap_user in interrupt so the commit c96952ed7031e7c576ecf90cf95b8ec099d5295a uses execute_in_process_context(). The problem is that scsi_error_handler() calls rq->end_io too. We can't call blk_put_request/blk_rq_unmap_user too in this path (we hold q->queue_lock). To avoid the above problem, in these rare cases, this patch always uses schedule_work() instead of execute_in_process_context(). Signed-off-by: FUJITA Tomonori Acked-by: Douglas Gilbert Cc: Stable Tree Signed-off-by: James Bottomley Signed-off-by: Chris Wright commit 74c646d9ca31798ec2bf862f5b7e1737b543d066 Author: FUJITA Tomonori Date: Wed Feb 4 11:36:27 2009 +0900 SCSI: sg: avoid blk_put_request/blk_rq_unmap_user in interrupt upstream commit: c96952ed7031e7c576ecf90cf95b8ec099d5295a This fixes the following oops: http://marc.info/?l=linux-kernel&m=123316111415677&w=2 You can reproduce this bug by interrupting a program before a sg response completes. This leads to the special sg state (the orphan state), then sg calls blk_put_request in interrupt (rq->end_io). The above bug report shows the recursive lock problem because sg calls blk_put_request in interrupt. We could call __blk_put_request here instead however we also need to handle blk_rq_unmap_user here, which can't be called in interrupt too. In the orphan state, we don't need to care about the data transfer (the program revoked the command) so adding 'just free the resource' mode to blk_rq_unmap_user is a possible option. I prefer to avoid complicating the blk mapping API when possible. I change the orphan state to call sg_finish_rem_req via execute_in_process_context. We hold sg_fd->kref so sg_fd doesn't go away until keventd_wq finishes our work. copy_from_user/to_user fails so blk_rq_unmap_user just frees the resource without the data transfer. Signed-off-by: FUJITA Tomonori Acked-by: Douglas Gilbert Signed-off-by: James Bottomley Signed-off-by: Chris Wright commit d4845ceede8c4087233198d2847b788a4e6f65b5 Author: Tony Battersby Date: Tue Jan 20 17:00:09 2009 -0500 SCSI: sg: fix races with ioctl(SG_IO) upstream commit: a2dd3b4cea335713b58996bb07b3abcde1175f47 sg_io_owned needs to be set before the command is sent to the midlevel; otherwise, a quickly-completing command may cause a different CPU to see "srp->done == 1 && !srp->sg_io_owned", which would lead to incorrect behavior. Check srp->done and set srp->orphan while holding rq_list_lock to prevent races with sg_rq_end_io(). There is no need to check sfp->closed from read/write/ioctl/poll/etc. since the kernel guarantees that this won't happen. The usefulness of sg_srp_done() was questionable before; now it is definitely not needed. Signed-off-by: Tony Battersby Acked-by: Douglas Gilbert Signed-off-by: James Bottomley Signed-off-by: Chris Wright commit b21c6d2897cd455fa396f4041a0c8165784e949f Author: Tony Battersby Date: Wed Jan 21 14:45:50 2009 -0500 SCSI: sg: fix races during device removal upstream commit: c6517b7942fad663cc1cf3235cbe4207cf769332 sg has the following problems related to device removal: * opening a sg fd races with removing a device * closing a sg fd races with removing a device * /proc/scsi/sg/* access races with removing a device * command completion races with removing a device * command completion races with closing a sg fd * can rmmod sg with active commands These problems can cause kernel oopses, memory-use-after-free, or double-free errors. This patch fixes these problems by using krefs to manage the lifetime of sg_device and sg_fd. Each command submitted to the midlevel holds a reference to sg_fd until the completion callback. This ensures that sg_fd doesn't go away if the fd is closed with commands still outstanding. sg_fd gets the reference of sg_device (with scsi_device) and also makes sure that the sg module doesn't go away. /proc/scsi/sg/* functions don't play nicely with krefs because they give information about sg_fds which have been closed but not yet freed due to still having outstanding commands and sg_devices which have been removed but not yet freed due to still being referenced by one or more sg_fds. To deal with this safely without removing functionality, /proc functions now access sg_device and sg_fd while holding a lock instead of using kref_get()/kref_put(). Signed-off-by: Tony Battersby Acked-by: Douglas Gilbert Signed-off-by: James Bottomley [chrisw: big for -stable, helps fix real bug, and made it through rc2 upstream] Signed-off-by: Chris Wright commit 14be1689c96842bd93cbcda4cb0bd4c5cc15a5a0 Author: Hugh Dickins Date: Thu Apr 16 21:45:05 2009 +0000 mm: pass correct mm when growing stack upstream commit: 05fa199d45c54a9bda7aa3ae6537253d6f097aa9 Tetsuo Handa reports seeing the WARN_ON(current->mm == NULL) in security_vm_enough_memory(), when do_execve() is touching the target mm's stack, to set up its args and environment. Yes, a UMH_NO_WAIT or UMH_WAIT_PROC call_usermodehelper() spawns an mm-less kernel thread to do the exec. And in any case, that vm_enough_memory check when growing stack ought to be done on the target mm, not on the execer's mm (though apart from the warning, it only makes a slight tweak to OVERCOMMIT_NEVER behaviour). Reported-by: Tetsuo Handa Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit d683876908060916ada0091d1db3b09afccb1517 Author: Sergei Shtylyov Date: Tue Apr 14 18:39:14 2009 +0400 pata_hpt37x: fix HPT370 DMA timeouts upstream commit: 265b7215aed36941620b65ecfff516200fb190c1 The libata driver has copied the code from the IDE driver which caused a post 2.4.18 regression on many HPT370[A] chips -- DMA stopped to work completely, only causing timeouts. Now remove hpt370_bmdma_start() for good... Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Chris Wright commit 2a3403fd95cbf6f548198be0fd37a056d12a56fe Author: Sergei Shtylyov Date: Sat Apr 18 17:42:19 2009 +0200 hpt366: fix HPT370 DMA timeouts upstream commit: c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac The big driver change in 2.4.19-rc1 introduced a regression for many HPT370[A] chips -- DMA stopped to work completely, only causing endless timeouts... The culprit has been identified (at last!): it turned to be the code resetting the DMA state machine before each transfer. Stop doing it now as this counter- measure has clearly caused more harm than good. This should fix the kernel.org bug #7703. Signed-off-by: Sergei Shtylyov Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Chris Wright commit 6c6737beae9981a707c1a4e1e9f1baf7cc47ce5f Author: Paul Mackerras Date: Wed Apr 15 17:25:05 2009 +0000 powerpc: Fix data-corrupting bug in __futex_atomic_op upstream commit: 306a82881b14d950d59e0b59a55093a07d82aa9a Richard Henderson pointed out that the powerpc __futex_atomic_op has a bug: it will write the wrong value if the stwcx. fails and it has to retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten by the result from the first time around the loop. This happens because it uses the same register for 'oparg' (an input) as it uses for the result. This fixes it by using separate registers for 'oparg' and 'ret'. Cc: stable@kernel.org Signed-off-by: Paul Mackerras Signed-off-by: Chris Wright commit edc9c87244b85102863440a9fd84024414fdc179 Author: Takashi Iwai Date: Wed Apr 15 17:25:03 2009 +0000 ALSA: hda - Fix the cmd cache keys for amp verbs upstream commit: fcad94a4c71c36a05f4d5c6dcb174534b4e0b136 Fix the key value generation for get/set amp verbs. The upper bits of the parameter have to be combined with the verb value to be unique for each direction/index of amp access. This fixes the resume problem on some hardwares like Macbook after the channel mode is changed. Tested-by: Johannes Berg Cc: Signed-off-by: Takashi Iwai Signed-off-by: Chris Wright commit 926e66275ddb852a4a4686df9b6b0f760746c7a3 Author: Ben Hutchings Date: Wed Apr 15 01:39:03 2009 +0100 sfc: Match calls to netif_napi_add() and netif_napi_del() upstream commit: 718cff1eec595ce6ab0635b8160a51ee37d9268d sfc could call netif_napi_add() multiple times for the same napi_struct, corrupting the list of napi_structs for the associated device and leading to a busy-loop on device removal. Move the call to netif_napi_add() and add a call to netif_napi_del() in the obvious places. [bhutchings: backport to 2.6.29] Signed-off-by: Ben Hutchings Signed-off-by: Chris Wright commit 9feb2c00e5d5b267912846454d7d0c85b6abd434 Author: Alan Cox Date: Tue Apr 14 14:58:11 2009 +0100 tty: Fix leak in ti-usb upstream commit: cf5450930db0ae308584e5361f3345e0ff73e643 If the ti-usb adapter returns an zero data length frame (which happens) then we leak a kref. Found by Christoph Mair who proposed a patch. The patch here is different as Christoph's patch didn't work for the case where tty = NULL and data arrived but Christoph did all the hard work chasing it down. Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 68890fb0bae12f076377dd6a9371be0289b98b7b Author: David Brownell Date: Mon Apr 13 22:35:03 2009 +0000 spi: spi_write_then_read() bugfixes upstream commit: bdff549ebeff92b1a6952e5501caf16a6f8898c8 The "simplify spi_write_then_read()" patch included two regressions from the 2.6.27 behaviors: - The data it wrote out during the (full duplex) read side of the transfer was not zeroed. - It fails completely on half duplex hardware, such as Microwire and most "3-wire" SPI variants. So, revert that patch. A revised version should be submitted at some point, which can get the speedup on standard hardware (full duplex) without breaking on less-capable half-duplex stuff. Signed-off-by: David Brownell Cc: [2.6.28.x, 2.6.29.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit d11a29e323dfd141183cdc918e31acdff02ef450 Author: Serge E. Hallyn Date: Mon Apr 13 17:25:03 2009 +0000 add some long-missing capabilities to fs_mask upstream commit: 0ad30b8fd5fe798aae80df6344b415d8309342cc When POSIX capabilities were introduced during the 2.1 Linux cycle, the fs mask, which represents the capabilities which having fsuid==0 is supposed to grant, did not include CAP_MKNOD and CAP_LINUX_IMMUTABLE. However, before capabilities the privilege to call these did in fact depend upon fsuid==0. This patch introduces those capabilities into the fsmask, restoring the old behavior. See the thread starting at http://lkml.org/lkml/2009/3/11/157 for reference. Note that if this fix is deemed valid, then earlier kernel versions (2.4 and 2.2) ought to be fixed too. Changelog: [Mar 23] Actually delete old CAP_FS_SET definition... [Mar 20] Updated against J. Bruce Fields's patch Reported-by: Igor Zhbanov Signed-off-by: Serge E. Hallyn Cc: stable@kernel.org Cc: J. Bruce Fields Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 7b457a610d6ab4d9bc654948da12968833510b2e Author: Peter Zijlstra Date: Fri Mar 13 12:21:27 2009 +0100 hrtimer: fix rq->lock inversion (again) upstream commit: 7f1e2ca9f04b02794597f60e7b1d43f0a1317939 It appears I inadvertly introduced rq->lock recursion to the hrtimer_start() path when I delegated running already expired timers to softirq context. This patch fixes it by introducing a __hrtimer_start_range_ns() method that will not use raise_softirq_irqoff() but __raise_softirq_irqoff() which avoids the wakeup. It then also changes schedule() to check for pending softirqs and do the wakeup then, I'm not quite sure I like this last bit, nor am I convinced its really needed. Signed-off-by: Peter Zijlstra Cc: Peter Zijlstra Cc: paulus@samba.org LKML-Reference: <20090313112301.096138802@chello.nl> Signed-off-by: Ingo Molnar Tested-by: Mikael Pettersson Signed-off-by: Chris Wright commit cf3c4fa34d08ef32a7fcc390e4c54f6eac92d572 Author: Suresh Siddha Date: Thu Apr 9 15:49:41 2009 -0700 x86: fix broken irq migration logic while cleaning up multiple vectors upstream commit: 68a8ca593fac82e336a792226272455901fa83df Impact: fix spurious IRQs During irq migration, we send a low priority interrupt to the previous irq destination. This happens in non interrupt-remapping case after interrupt starts arriving at new destination and in interrupt-remapping case after modifying and flushing the interrupt-remapping table entry caches. This low priority irq cleanup handler can cleanup multiple vectors, as multiple irq's can be migrated at almost the same time. While there will be multiple invocations of irq cleanup handler (one cleanup IPI for each irq migration), first invocation of the cleanup handler can potentially cleanup more than one vector (as the first invocation can see the requests for more than vector cleanup). When we cleanup multiple vectors during the first invocation of the smp_irq_move_cleanup_interrupt(), other vectors that are to be cleanedup can still be pending in the local cpu's IRR (as smp_irq_move_cleanup_interrupt() runs with interrupts disabled). When we are ready to unhook a vector corresponding to an irq, check if that vector is registered in the local cpu's IRR. If so skip that cleanup and do a self IPI with the cleanup vector, so that we give a chance to service the pending vector interrupt and then cleanup that vector allocation once we execute the lowest priority handler. This fixes spurious interrupts seen when migrating multiple vectors at the same time. [ This is apparently possible even on conventional xapic, although to the best of our knowledge it has never been seen. The stable maintainers may wish to consider this one for -stable. ] [suresh: backport to 2.6.29] Signed-off-by: Suresh Siddha Cc: Eric W. Biederman Signed-off-by: H. Peter Anvin Cc: stable@kernel.org Signed-off-by: Chris Wright commit 3f22ebd2f4d191631a7b867addc8bd99e948873f Author: Nathan Lynch Date: Thu Apr 9 18:20:02 2009 +0000 sched: do not count frozen tasks toward load upstream commit: e3c8ca8336707062f3f7cb1cd7e6b3c753baccdd Freezing tasks via the cgroup freezer causes the load average to climb because the freezer's current implementation puts frozen tasks in uninterruptible sleep (D state). Some applications which perform job-scheduling functions consult the load average when making decisions. If a cgroup is frozen, the load average does not provide a useful measure of the system's utilization to such applications. This is especially inconvenient if the job scheduler employs the cgroup freezer as a mechanism for preempting low priority jobs. Contrast this with using SIGSTOP for the same purpose: the stopped tasks do not count toward system load. Change task_contributes_to_load() to return false if the task is frozen. This results in /proc/loadavg behavior that better meets users' expectations. Signed-off-by: Nathan Lynch Acked-by: Andrew Morton Acked-by: Nigel Cunningham Tested-by: Nigel Cunningham Cc: Cc: containers@lists.linux-foundation.org Cc: linux-pm@lists.linux-foundation.org Cc: Matt Helsley LKML-Reference: <20090408194512.47a99b95@manatee.lan> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright commit 94835d2bc7374d26ae8602a96c866c9ddf2e2c45 Author: Mikulas Patocka Date: Thu Apr 9 18:20:04 2009 +0000 dm kcopyd: fix callback race upstream commit: 340cd44451fb0bfa542365e6b4b565bbd44836e2 If the thread calling dm_kcopyd_copy is delayed due to scheduling inside split_job/segment_complete and the subjobs complete before the loop in split_job completes, the kcopyd callback could be invoked from the thread that called dm_kcopyd_copy instead of the kcopyd workqueue. dm_kcopyd_copy -> split_job -> segment_complete -> job->fn() Snapshots depend on the fact that callbacks are called from the singlethreaded kcopyd workqueue and expect that there is no racing between individual callbacks. The racing between callbacks can lead to corruption of exception store and it can also mean that exception store callbacks are called twice for the same exception - a likely reason for crashes reported inside pending_complete() / remove_exception(). This patch fixes two problems: 1. job->fn being called from the thread that submitted the job (see above). - Fix: hand over the completion callback to the kcopyd thread. 2. job->fn(read_err, write_err, job->context); in segment_complete reports the error of the last subjob, not the union of all errors. - Fix: pass job->write_err to the callback to report all error bits (it is done already in run_complete_job) Cc: stable@kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit f2fcdb15ebd2425d165c97c4d07fe10c8730ae23 Author: Mikulas Patocka Date: Thu Apr 9 18:20:06 2009 +0000 dm kcopyd: prepare for callback race fix upstream commit: 73830857bca6f6c9dbd48e906daea50bea42d676 Use a variable in segment_complete() to point to the dm_kcopyd_client struct and only release job->pages in run_complete_job() if any are defined. These changes are needed by the next patch. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit 55e3b46ded854d9fc2408d0d15a6a5aea4986333 Author: Oleg Nesterov Date: Thu Apr 9 18:20:08 2009 +0000 posix-timers: fix RLIMIT_CPU && setitimer(CPUCLOCK_PROF) upstream commit: 8f2e586567b1bad72dac7c3810fe9a2ef7117506 update_rlimit_cpu() tries to optimize out set_process_cpu_timer() in case when we already have CPUCLOCK_PROF timer which should expire first. But it uses cputime_lt() instead of cputime_gt(). Test case: int main(void) { struct itimerval it = { .it_value = { .tv_sec = 1000 }, }; assert(!setitimer(ITIMER_PROF, &it, NULL)); struct rlimit rl = { .rlim_cur = 1, .rlim_max = 1, }; assert(!setrlimit(RLIMIT_CPU, &rl)); for (;;) ; return 0; } Without this patch, the task is not killed as RLIMIT_CPU demands. Signed-off-by: Oleg Nesterov Acked-by: Peter Zijlstra Cc: Peter Lojkin Cc: Roland McGrath Cc: stable@kernel.org LKML-Reference: <20090327000610.GA10108@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright commit 3fe90c4dc50b1c4030d73d196a5d812ea906a4c9 Author: Oleg Nesterov Date: Thu Apr 9 18:20:10 2009 +0000 posix-timers: fix RLIMIT_CPU && fork() upstream commit: 6279a751fe096a21dc7704e918d570d3ff06e769 See http://bugzilla.kernel.org/show_bug.cgi?id=12911 copy_signal() copies signal->rlim, but RLIMIT_CPU is "lost". Because posix_cpu_timers_init_group() sets cputime_expires.prof_exp = 0 and thus fastpath_timer_check() returns false unless we have other expired cpu timers. Change copy_signal() to set cputime_expires.prof_exp if we have RLIMIT_CPU. Also, set cputimer.running = 1 in that case. This is not strictly necessary, but imho makes sense. Reported-by: Peter Lojkin Signed-off-by: Oleg Nesterov Acked-by: Peter Zijlstra Cc: Peter Lojkin Cc: Roland McGrath Cc: stable@kernel.org LKML-Reference: <20090327000607.GA10104@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright commit 39cd13c96cfc4d9d5992e93625fe6d6cb4fe3991 Author: Hidetoshi Seto Date: Thu Apr 9 18:20:12 2009 +0000 posixtimers, sched: Fix posix clock monotonicity upstream commit: c5f8d99585d7b5b7e857fabf8aefd0174903a98c Impact: Regression fix (against clock_gettime() backwarding bug) This patch re-introduces a couple of functions, task_sched_runtime and thread_group_sched_runtime, which was once removed at the time of 2.6.28-rc1. These functions protect the sampling of thread/process clock with rq lock. This rq lock is required not to update rq->clock during the sampling. i.e. The clock_gettime() may return ((accounted runtime before update) + (delta after update)) that is less than what it should be. v2 -> v3: - Rename static helper function __task_delta_exec() to do_task_delta_exec() since -tip tree already has a __task_delta_exec() of different version. v1 -> v2: - Revises comments of function and patch description. - Add note about accuracy of thread group's runtime. Signed-off-by: Hidetoshi Seto Acked-by: Peter Zijlstra Cc: stable@kernel.org [2.6.28.x][2.6.29.x] LKML-Reference: <49D1CC93.4080401@jp.fujitsu.com> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright commit 22f45438e5e7369f7c3a384a41616affd200b840 Author: Serge E. Hallyn Date: Wed Apr 8 16:55:58 2009 -0500 cap_prctl: don't set error to 0 at 'no_change' upstream commit: 5bf37ec3e0f5eb79f23e024a7fbc8f3557c087f0 One-liner: capsh --print is broken without this patch. In certain cases, cap_prctl returns error > 0 for success. However, the 'no_change' label was always setting error to 0. As a result, for example, 'prctl(CAP_BSET_READ, N)' would always return 0. It should return 1 if a process has N in its bounding set (as by default it does). I'm keeping the no_change label even though it's now functionally the same as 'error'. Signed-off-by: Serge Hallyn Acked-by: David Howells Signed-off-by: James Morris Signed-off-by: Chris Wright commit b76d2b612cd5c0c6fb82340f9ec241ca75b942f9 Author: Jean Delvare Date: Wed Apr 1 13:11:29 2009 -0500 SCSI: libiscsi: fix iscsi pool error path upstream commit: fd6e1c14b73dbab89cb76af895d5612e4a8b5522 Le lundi 30 mars 2009, Chris Wright a écrit : > q->queue could be ERR_PTR(-ENOMEM) which will break unwinding > on error. Make iscsi_pool_free more defensive. > Making the freeing of q->queue dependent on q->pool being set looks really weird (although it is correct at the moment. But this seems to be fixable in a much simpler way. With the benefit that only the error case is slowed down. In both cases we have a problem if q->queue contains an error value but it's not -ENOMEM. Apparently this can't happen today, but it doesn't feel right to assume this will always be true. Maybe it's the right time to fix this as well. Signed-off-by: Mike Christie Signed-off-by: James Bottomley [chrisw: this is a fixlet to f474a37b, also in -stable] Signed-off-by: Chris Wright commit 10b9c3cd8848919561d16570759c0146988cb8d5 Author: Jean Delvare Date: Thu Mar 5 14:45:55 2009 -0600 SCSI: libiscsi: fix iscsi pool error path upstream commit: f474a37bc48667595b5653a983b635c95ed82a3b Memory freeing in iscsi_pool_free() looks wrong to me. Either q->pool can be NULL and this should be tested before dereferencing it, or it can't be NULL and it shouldn't be tested at all. As far as I can see, the only case where q->pool is NULL is on early error in iscsi_pool_init(). One possible way to fix the bug is thus to not call iscsi_pool_free() in this case (nothing needs to be freed anyway) and then we can get rid of the q->pool check. Signed-off-by: Jean Delvare Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Chris Wright commit df76bd846a1c4a2264ad670c5b11aa2497edce19 Author: David Miller Date: Wed Apr 8 02:51:47 2009 -0700 sparc64: Fix bug in ("sparc64: Flush TLB before releasing pages.") [ No upstream commit, this regression was added only to 2.6.29.1 ] Unfortunately I merged an earlier version of commit b6816b706138c3870f03115071872cad824f90b4 ("sparc64: Flush TLB before releasing pages.") than what I actually tested and merged upstream. Simply diffing asm/tlb_64.h in Linus's tree vs. what ended up in 2.6.29.1 confirms this. Sync things up to fix BUG() triggers some users are seeing. Reported-by: Dennis Gilmore Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 37a8bca218bf6c4cad295b7d250c3590f57e3cf6 Author: Akinobu Mita Date: Tue Apr 7 16:25:04 2009 +0000 ALSA: hda - add missing comma in ad1884_slave_vols upstream commit: bca68467b59a24396554d8dd5979ee363c174854 Signed-off-by: Akinobu Mita Cc: Signed-off-by: Takashi Iwai Signed-off-by: Chris Wright commit ed960ac61e12e298d1cdcd52b21b9ee07d36755c Author: Miklos Szeredi Date: Tue Apr 7 16:25:02 2009 +0000 splice: fix deadlock in splicing to file upstream commit: 7bfac9ecf0585962fe13584f5cf526d8c8e76f17 There's a possible deadlock in generic_file_splice_write(), splice_from_pipe() and ocfs2_file_splice_write(): - task A calls generic_file_splice_write() - this calls inode_double_lock(), which locks i_mutex on both pipe->inode and target inode - ordering depends on inode pointers, can happen that pipe->inode is locked first - __splice_from_pipe() needs more data, calls pipe_wait() - this releases lock on pipe->inode, goes to interruptible sleep - task B calls generic_file_splice_write(), similarly to the first - this locks pipe->inode, then tries to lock inode, but that is already held by task A - task A is interrupted, it tries to lock pipe->inode, but fails, as it is already held by task B - ABBA deadlock Fix this by explicitly ordering locks: the outer lock must be on target inode and the inner lock (which is later unlocked and relocked) must be on pipe->inode. This is OK, pipe inodes and target inodes form two nonoverlapping sets, generic_file_splice_write() and friends are not called with a target which is a pipe. Signed-off-by: Miklos Szeredi Acked-by: Mark Fasheh Acked-by: Jens Axboe Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright commit 6bc1b5deb47f0fc3d697abd2fcd417618cf07e3f Author: Patrick McHardy Date: Mon Apr 6 17:31:29 2009 +0200 netfilter: {ip, ip6, arp}_tables: fix incorrect loop detection upstream commit: 1f9352ae2253a97b07b34dcf16ffa3b4ca12c558 Commit e1b4b9f ([NETFILTER]: {ip,ip6,arp}_tables: fix exponential worst-case search for loops) introduced a regression in the loop detection algorithm, causing sporadic incorrectly detected loops. When a chain has already been visited during the check, it is treated as having a standard target containing a RETURN verdict directly at the beginning in order to not check it again. The real target of the first rule is then incorrectly treated as STANDARD target and checked not to contain invalid verdicts. Fix by making sure the rule does actually contain a standard target. Based on patch by Francis Dupont Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright commit 3b3e59f78d3bf0e0818a9b759484138d4300a72e Author: Ananth N Mavinakayanahalli Date: Sun Apr 5 18:20:22 2009 +0000 kprobes: Fix locking imbalance in kretprobes upstream commit: f02b8624fedca39886b0eef770dca70c2f0749b3 Fix locking imbalance in kretprobes: ===================================== [ BUG: bad unlock balance detected! ] ------------------------------------- kthreadd/2 is trying to release lock (&rp->lock) at: [] pre_handler_kretprobe+0xea/0xf4 but there are no more locks to release! other info that might help us debug this: 1 lock held by kthreadd/2: #0: (rcu_read_lock){..--}, at: [] __atomic_notifier_call_chain+0x0/0x5a stack backtrace: Pid: 2, comm: kthreadd Not tainted 2.6.29-rc8 #1 Call Trace: [] ? printk+0xf/0x17 [] ? pre_handler_kretprobe+0xea/0xf4 [] print_unlock_inbalance_bug+0xc3/0xce [] ? clocksource_read+0x7/0xa [] ? getnstimeofday+0x5f/0xf6 [] ? register_lock_class+0x17/0x293 [] ? mark_lock+0x1e/0x30b [] ? tick_dev_program_event+0x4a/0xbc [] ? __slab_alloc+0xa5/0x415 [] ? pre_handler_kretprobe+0x28/0xf4 [] ? pre_handler_kretprobe+0xea/0xf4 [] lock_release_non_nested+0xa4/0x1a5 [] ? pre_handler_kretprobe+0xea/0xf4 [] lock_release+0x141/0x166 [] _spin_unlock_irqrestore+0x19/0x50 [] pre_handler_kretprobe+0xea/0xf4 [] kprobe_exceptions_notify+0x1c9/0x43e [] notifier_call_chain+0x26/0x48 [] __atomic_notifier_call_chain+0x37/0x5a [] ? __atomic_notifier_call_chain+0x0/0x5a [] atomic_notifier_call_chain+0xc/0xe [] notify_die+0x2d/0x2f [] do_int3+0x1f/0x71 [] int3+0x2c/0x34 [] ? do_fork+0x1/0x288 [] ? kernel_thread+0x71/0x79 [] ? kthread+0x0/0x60 [] ? kthread+0x0/0x60 [] ? kernel_thread_helper+0x0/0x10 [] kthreadd+0xac/0x148 [] ? kthreadd+0x0/0x148 [] kernel_thread_helper+0x7/0x10 Signed-off-by: Ananth N Mavinakayanahalli Tested-by: Bharata B Rao Cc: Masami Hiramatsu Cc: Jim Keniston Cc: Linus Torvalds Cc: Andrew Morton Cc: [2.6.29.x, 2.6.28.x, 2.6.27.x] LKML-Reference: <20090318113621.GB4129@in.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright commit 3eb67e60612af334fda0b344620e3b04f4254a60 Author: Carlos Corbacho Date: Sun Apr 5 18:20:04 2009 +0000 acer-wmi: Blacklist Acer Aspire One upstream commit: a74dd5fdabcd34c93e17e9c7024eeb503c92b048 The Aspire One's ACPI-WMI interface is a placeholder that does nothing, and the invalid results that we get from it are now causing userspace problems as acer-wmi always returns that the rfkill is enabled (i.e. the radio is off, when it isn't). As it's hardware controlled, acer-wmi isn't needed on the Aspire One either. Thanks to Andy Whitcroft at Canonical for tracking down Ubuntu's userspace issues to this. Signed-off-by: Carlos Corbacho Reported-by: Andy Whitcroft Cc: stable@kernel.org Signed-off-by: Len Brown Signed-off-by: Chris Wright commit fce2b77a3f903be6c3cc46de7b850e3fd910bcef Author: Yehuda Sadeh Date: Sat Apr 4 12:31:02 2009 +0800 crypto: shash - Fix unaligned calculation with short length upstream commit: f4f689933c63e0fbfba62f2a80efb2b424b139ae When the total length is shorter than the calculated number of unaligned bytes, the call to shash->update breaks. For example, calling crc32c on unaligned buffer with length of 1 can result in a system crash. Signed-off-by: Yehuda Sadeh Signed-off-by: Herbert Xu Signed-off-by: Chris Wright commit df5b6025d1a9e2e61dde1fd28257082751264c07 Author: Jean Delvare Date: Wed Apr 22 00:49:51 2009 -0700 net/netrom: Fix socket locking upstream commit: cc29c70dd581f85ee7a3e7980fb031f90b90a2ab Patch "af_rose/x25: Sanity check the maximum user frame size" (commit 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9) from Alan Cox got locking wrong. If we bail out due to user frame size being too large, we must unlock the socket beforehand. Signed-off-by: Jean Delvare Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 33d06566b593703a972da232d08b6a12176f1854 Author: Alan Cox Date: Fri Mar 27 00:28:21 2009 -0700 af_rose/x25: Sanity check the maximum user frame size upstream commit: 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9 CVE-2009-0795. Otherwise we can wrap the sizes and end up sending garbage. Closes #10423 Signed-off-by: Alan Cox Signed-off-by: David S. Miller Signed-off-by: Chris Wright commit 43a00bbcf5aeaac50d9e8271dbfa0d0fc1d4eb43 Author: Alasdair G Kergon Date: Fri Apr 3 17:45:08 2009 +0000 dm table: fix upgrade mode race upstream commit: 570b9d968bf9b16974252ef7cbce73fa6dac34f3 upgrade_mode() sets bdev to NULL temporarily, and does not have any locking to exclude anything from seeing that NULL. In dm_table_any_congested() bdev_get_queue() can dereference that NULL and cause a reported oops. Fix this by not changing that field during the mode upgrade. Cc: stable@kernel.org Cc: Neil Brown Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit d92281c9087f7f7d8c18cf95f18a8148167907e0 Author: Jun'ichi Nomura Date: Fri Apr 3 17:45:10 2009 +0000 dm: path selector use module refcount directly upstream commit: aea9058801c0acfa2831af1714da412dfb0018c2 Fix refcount corruption in dm-path-selector Refcounting with non-atomic ops under shared lock will corrupt the counter in multi-processor system and may trigger BUG_ON(). Use module refcount. # same approach as dm-target-use-module-refcount-directly.patch here # https://www.redhat.com/archives/dm-devel/2008-December/msg00075.html Typical oops: kernel BUG at linux-2.6.29-rc3/drivers/md/dm-path-selector.c:90! Pid: 11148, comm: dmsetup Not tainted 2.6.29-rc3-nm #1 dm_put_path_selector+0x4d/0x61 [dm_multipath] Call Trace: [] free_priority_group+0x33/0xb3 [dm_multipath] [] free_multipath+0x31/0x67 [dm_multipath] [] multipath_dtr+0x2d/0x32 [dm_multipath] [] dm_table_destroy+0x64/0xd8 [dm_mod] [] __unbind+0x46/0x4b [dm_mod] [] dm_swap_table+0x60/0x14d [dm_mod] [] dev_suspend+0xfd/0x177 [dm_mod] [] dm_ctl_ioctl+0x24c/0x29c [dm_mod] [] ? get_page_from_freelist+0x49c/0x61d [] ? dev_suspend+0x0/0x177 [dm_mod] [] vfs_ioctl+0x2a/0x77 [] do_vfs_ioctl+0x448/0x4a0 [] sys_ioctl+0x57/0x7a [] system_call_fastpath+0x16/0x1b Cc: stable@kernel.org Signed-off-by: Jun'ichi Nomura Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit 3ee793df8fbfe03379fa1eb77e532a0b931a67e8 Author: Cheng Renquan Date: Fri Apr 3 17:45:13 2009 +0000 dm target: use module refcount directly upstream commit: 5642b8a61a15436231adf27b2b1bd96901b623dd The tt_internal's 'use' field is superfluous: the module's refcount can do the work properly. An acceptable side-effect is that this increases the reference counts reported by 'lsmod'. Remove the superfluous test when removing a target module. [Crash possible without this on SMP - agk] Cc: stable@kernel.org Signed-off-by: Cheng Renquan Signed-off-by: Alasdair G Kergon Reviewed-by: Alasdair G Kergon Reviewed-by: Jonathan Brassow Signed-off-by: Chris Wright commit 8068bd7e0480e6295b9e0be85a2eb57f9aba7825 Author: Mikulas Patocka Date: Fri Apr 3 17:45:14 2009 +0000 dm snapshot: avoid having two exceptions for the same chunk upstream commit: 35bf659b008e83e725dcd30f542e38461dbb867c We need to check if the exception was completed after dropping the lock. After regaining the lock, __find_pending_exception checks if the exception was already placed into &s->pending hash. But we don't check if the exception was already completed and placed into &s->complete hash. If the process waiting in alloc_pending_exception was delayed at this point because of a scheduling latency and the exception was meanwhile completed, we'd miss that and allocate another pending exception for already completed chunk. It would lead to a situation where two records for the same chunk exist and potential data corruption because multiple snapshot I/Os to the affected chunk could be redirected to different locations in the snapshot. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit e231d89b16b1e137fb098a14a6440da4b4a24786 Author: Mikulas Patocka Date: Fri Apr 3 17:45:16 2009 +0000 dm snapshot: avoid dropping lock in __find_pending_exception upstream commit: c66213921c816f6b1b16a84911618ba9a363b134 It is uncommon and bug-prone to drop a lock in a function that is called with the lock held, so this is moved to the caller. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit 135c58d2f19a471e00006573c9b6e3c4f0c6abd6 Author: Mikulas Patocka Date: Fri Apr 3 17:45:19 2009 +0000 dm snapshot: refactor __find_pending_exception upstream commit: 2913808eb56a6445a7b277eb8d17651c8defb035 Move looking-up of a pending exception from __find_pending_exception to another function. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit 07280df84ae0357594f65e8e56042822c9697fbd Author: Mikulas Patocka Date: Fri Apr 3 17:45:21 2009 +0000 dm io: make sync_io uninterruptible upstream commit: b64b6bf4fd8b678a9f8477c11773c38a0a246a6d If someone sends signal to a process performing synchronous dm-io call, the kernel may crash. The function sync_io attempts to exit with -EINTR if it has pending signal, however the structure "io" is allocated on stack, so already submitted io requests end up touching unallocated stack space and corrupting kernel memory. sync_io sets its state to TASK_UNINTERRUPTIBLE, so the signal can't break out of io_schedule() --- however, if the signal was pending before sync_io entered while (1) loop, the corruption of kernel memory will happen. There is no way to cancel in-progress IOs, so the best solution is to ignore signals at this point. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Chris Wright commit 6858778b9cf9436f667a101ffc62c20f889ea294 Author: Mikulas Patocka Date: Fri Apr 3 17:45:23 2009 +0000 dm raid1: switch read_record from kmalloc to slab to save memory upstream commit: 95f8fac8dc6139fedfb87746e0c8fda9b803cb46 With my previous patch to save bi_io_vec, the size of dm_raid1_read_record is significantly increased (the vector list takes 3072 bytes on 32-bit machines and 4096 bytes on 64-bit machines). The structure dm_raid1_read_record used to be allocated with kmalloc, but kmalloc aligns the size on the next power-of-two so an object slightly greater than 4096 will allocate 8192 bytes of memory and half of that memory will be wasted. This patch turns kmalloc into a slab cache which doesn't have this padding so it will reduce the memory consumed. Cc: stable@kernel.org Signed-off-by: Mikulas Patocka