commit ad9c990a2c6aa197b1e5c68ea2870062e68e0b08 Author: Greg Kroah-Hartman Date: Mon Mar 21 12:49:43 2011 -0700 Linux 2.6.33.8 commit 99b0ee6c642cc2d03fc38dab8e64ae6ef468d3fe Author: Tilman Schmidt Date: Mon Jul 5 14:18:27 2010 +0000 isdn: avoid calling tty_ldisc_flush() in atomic context commit bc10f96757bd6ab3721510df8defa8f21c32f974 upstream. Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER branch of isdn_tty_modem_result(), as already proposed in commit 00409bb045887ec5e7b9e351bc080c38ab6bfd33. This avoids a "sleeping function called from invalid context" BUG when the hardware driver calls the statcallb() callback with command==ISDN_STAT_DHUP in atomic context, which in turn calls isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there, tty_ldisc_flush() which may sleep. Signed-off-by: Tilman Schmidt Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8f5defbad63b47b8a43e4e6cc6089b93049f87f Author: Shaohua Li Date: Wed Mar 16 11:37:29 2011 +0800 x86: Flush TLB if PGD entry is changed in i386 PAE mode commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream. According to intel CPU manual, every time PGD entry is changed in i386 PAE mode, we need do a full TLB flush. Current code follows this and there is comment for this too in the code. But current code misses the multi-threaded case. A changed page table might be used by several CPUs, every such CPU should flush TLB. Usually this isn't a problem, because we prepopulate all PGD entries at process fork. But when the process does munmap and follows new mmap, this issue will be triggered. When it happens, some CPUs keep doing page faults: http://marc.info/?l=linux-kernel&m=129915020508238&w=2 Reported-by: Yasunori Goto Tested-by: Yasunori Goto Reviewed-by: Rik van Riel Signed-off-by: Shaohua Li Cc: Mallick Asit K Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm LKML-Reference: <1300246649.2337.95.camel@sli10-conroe> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit dae148953f37229ca7be1a80d8c9584792d990b2 Author: Milton Miller Date: Tue Mar 15 13:27:16 2011 -0600 call_function_many: add missing ordering commit 45a5791920ae643eafc02e2eedef1a58e341b736 upstream. Paul McKenney's review pointed out two problems with the barriers in the 2.6.38 update to the smp call function many code. First, a barrier that would force the func and info members of data to be visible before their consumption in the interrupt handler was missing. This can be solved by adding a smp_wmb between setting the func and info members and setting setting the cpumask; this will pair with the existing and required smp_rmb ordering the cpumask read before the read of refs. This placement avoids the need a second smp_rmb in the interrupt handler which would be executed on each of the N cpus executing the call request. (I was thinking this barrier was present but was not). Second, the previous write to refs (establishing the zero that we the interrupt handler was testing from all cpus) was performed by a third party cpu. This would invoke transitivity which, as a recient or concurrent addition to memory-barriers.txt now explicitly states, would require a full smp_mb(). However, we know the cpumask will only be set by one cpu (the data owner) and any preivous iteration of the mask would have cleared by the reading cpu. By redundantly writing refs to 0 on the owning cpu before the smp_wmb, the write to refs will follow the same path as the writes that set the cpumask, which in turn allows us to keep the barrier in the interrupt handler a smp_rmb instead of promoting it to a smp_mb (which will be be executed by N cpus for each of the possible M elements on the list). I moved and expanded the comment about our (ab)use of the rcu list primitives for the concurrent walk earlier into this function. I considered moving the first two paragraphs to the queue list head and lock, but felt it would have been too disconected from the code. Cc: Paul McKinney Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9b1bd836a0acdd1d939417017535d37cfaf0e6d0 Author: Milton Miller Date: Tue Mar 15 13:27:16 2011 -0600 call_function_many: fix list delete vs add race commit e6cd1e07a185d5f9b0aa75e020df02d3c1c44940 upstream. Peter pointed out there was nothing preventing the list_del_rcu in smp_call_function_interrupt from running before the list_add_rcu in smp_call_function_many. Fix this by not setting refs until we have gotten the lock for the list. Take advantage of the wmb in list_add_rcu to save an explicit additional one. I tried to force this race with a udelay before the lock & list_add and by mixing all 64 online cpus with just 3 random cpus in the mask, but was unsuccessful. Still, inspection shows a valid race, and the fix is a extension of the existing protection window in the current code. Reported-by: Peter Zijlstra Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9cedf78402729da0d3662ee7c695ac3f232c4f43 Author: Eric Sandeen Date: Fri Mar 4 16:04:08 2011 -0600 ext3: Always set dx_node's fake_dirent explicitly. commit d7433142b63d727b5a217c37b1a1468b116a9771 upstream. (crossport of 1f7bebb9e911d870fa8f997ddff838e82b5715ea by Andreas Schlick ) When ext3_dx_add_entry() has to split an index node, it has to ensure that name_len of dx_node's fake_dirent is also zero, because otherwise e2fsck won't recognise it as an intermediate htree node and consider the htree to be corrupted. Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 9008aa5b68fe409f419c4404de3fb36d43abbe39 Author: Anton Blanchard Date: Wed Mar 9 14:38:42 2011 +1100 perf, powerpc: Handle events that raise an exception without overflowing commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 upstream. Events on POWER7 can roll back if a speculative event doesn't eventually complete. Unfortunately in some rare cases they will raise a performance monitor exception. We need to catch this to ensure we reset the PMC. In all cases the PMC will be 256 or less cycles from overflow. Signed-off-by: Anton Blanchard Signed-off-by: Peter Zijlstra LKML-Reference: <20110309143842.6c22845e@kryten> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 585f09f8bfb60e2b093da4fc7d6078dd8e161bb4 Author: Trond Myklebust Date: Tue Mar 15 19:56:30 2011 -0400 SUNRPC: Ensure we always run the tk_callback before tk_action commit e020c6800c9621a77223bf2c1ff68180e41e8ebf upstream. This fixes a race in which the task->tk_callback() puts the rpc_task to sleep, setting a new callback. Under certain circumstances, the current code may end up executing the task->tk_action before it gets round to the callback. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 314877d903f32978fc0fbd7eb335c044c9887c27 Author: Joseph Gruher Date: Wed Jan 5 16:00:21 2011 -0500 scsi_dh_alua: fix deadlock in stpg_endio commit ed0f36bc5719b25659b637f80ceea85494b84502 upstream. The use of blk_execute_rq_nowait() implies __blk_put_request() is needed in stpg_endio() rather than blk_put_request() -- blk_finish_request() is called with queue lock already held. Signed-off-by: Joseph Gruher Signed-off-by: Ilgu Hong Signed-off-by: Mike Snitzer Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 0fa74a5c1ce6166671879098666a6b9caa1c8af4 Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:58 2011 +0100 ALSA: ctxfi - Clear input settings before initialization commit efed5f26664f93991c929d5bb343e65f900d72bc upstream. Clear input settings before initialization. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 38243420f101167d625b7f2d3a385a396de4b468 Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:57 2011 +0100 ALSA: ctxfi - Fix SPDIF status retrieval commit f164753a263bfd2daaf3e0273b179de7e099c57d upstream. SDPIF status retrieval always returned the default settings instead of the actual ones. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 89b0dcd2a7a11ac324c7bdf15bb15a084c3434ef Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:56 2011 +0100 ALSA: ctxfi - Fix incorrect SPDIF status bit mask commit 4c1847e884efddcc3ede371f7839e5e65b25c34d upstream. SPDIF status mask creation was incorrect. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit db79cbf24f8d161f284dd9e8697ead9a002b3e5e Author: Ben Hutchings Date: Thu Jan 13 19:47:56 2011 +0000 PCI: sysfs: Fix failure path for addition of "vpd" attribute commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream. Commit 280c73d ("PCI: centralize the capabilities code in pci-sysfs.c") changed the initialisation of the "rom" and "vpd" attributes, and made the failure path for the "vpd" attribute incorrect. We must free the new attribute structure (attr), but instead we currently free dev->vpd->attr. That will normally be NULL, resulting in a memory leak, but it might be a stale pointer, resulting in a double-free. Found by inspection; compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 1078c7bf019fed9537eebbf7e84a402ba4a59dcb Author: Jiri Slaby Date: Mon Feb 28 10:45:10 2011 +0100 PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream. Some broken BIOSes on ICH4 chipset report an ACPI region which is in conflict with legacy IDE ports when ACPI is disabled. Even though the regions overlap, IDE ports are working correctly (we cannot find out the decoding rules on chipsets). So the only problem is the reported region itself, if we don't reserve the region in the quirk everything works as expected. This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO which is 0x1000. Some regions might be (and are by a fast google query) below this border, but the only difference is that they won't be reserved anymore. They should still work though the same as before. The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl): pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f] At 0x0100 a 128 bytes long ACPI region is reported in the quirk for ICH4. ata_piix then fails to find disks because the IDE legacy ports are zeroed: ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007]) References: https://bugzilla.novell.com/show_bug.cgi?id=558740 Signed-off-by: Jiri Slaby Cc: Bjorn Helgaas Cc: "David S. Miller" Cc: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 1fed17a3f1736f5396a951dd01ebd58adf43208f Author: Jiri Slaby Date: Mon Feb 28 10:45:09 2011 +0100 PCI: add more checking to ICH region quirks commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream. Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN and GPIO_EN bits are set to 1. Add checks for these bits into the quirks prior to the region creation. While at it, name the constants by macros. Signed-off-by: Jiri Slaby Cc: Bjorn Helgaas Cc: "David S. Miller" Cc: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit ea5b3ecf8f709833067b392afc0a40cc510bb668 Author: Brandeburg, Jesse Date: Mon Feb 14 09:05:02 2011 -0800 PCI: remove quirk for pre-production systems commit b99af4b002e4908d1a5cdaf424529bdf1dc69768 upstream. Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944 Author: Yu Zhao Date: Fri Apr 3 15:18:11 2009 +0800 PCI: SR-IOV quirk for Intel 82576 NIC If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash BAR and program the SR-IOV BARs to use the old Flash Memory Space. Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet section 7.9.2.14.2 for details. http://download.intel.com/design/network/datashts/82576_Datasheet.pdf Signed-off-by: Yu Zhao Signed-off-by: Jesse Barnes This quirk was added before SR-IOV was in production and now all machines that originally had this issue alreayd have bios updates to correct the issue. The quirk itself is no longer needed and in fact causes bugs if run. Remove it. Signed-off-by: Jesse Brandeburg CC: Yu Zhao CC: Jesse Barnes Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 9f13867caa60c0dd55ac0dfc1021de1c4db7c83e Author: Vitaliy Kulikov Date: Wed Mar 9 19:47:43 2011 -0600 ALSA: hda - fix digital mic selection in mixer on 92HD8X codecs commit 094a42452abd5564429045e210281c6d22e67fca upstream. When the mux for digital mic is different from the mux for other mics, the current auto-parser doesn't handle them in a right way but provides only one mic. This patch fixes the issue. Signed-off-by: Vitaliy Kulikov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 23dd4f104b2630a225b41416d5237aca72ebc195 Author: Dan Rosenberg Date: Mon Sep 6 18:24:57 2010 -0400 xfs: prevent reading uninitialized stack memory commit a122eb2fdfd78b58c6dd992d6f4b1aaef667eef9 upstream. The XFS_IOC_FSGETXATTR ioctl allows unprivileged users to read 12 bytes of uninitialized stack memory, because the fsxattr struct declared on the stack in xfs_ioc_fsgetxattr() does not alter (or zero) the 12-byte fsx_pad member before copying it back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Reviewed-by: Eric Sandeen Signed-off-by: Alex Elder Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit 24ae805d43b392998be1097ae0b43fdce2b0c493 Author: Libor Pechacek Date: Fri Jan 14 14:30:21 2011 +0100 USB: serial: handle Data Carrier Detect changes commit d14fc1a74e846d7851f24fc9519fe87dc12a1231 upstream. Alan's commit 335f8514f200e63d689113d29cb7253a5c282967 introduced .carrier_raised function in several drivers. That also means tty_port_block_til_ready can now suspend the process trying to open the serial port when Carrier Detect is low and put it into tty_port.open_wait queue. We need to wake up the process when Carrier Detect goes high and trigger TTY hangup when CD goes low. Some of the devices do not report modem status line changes, or at least we don't understand the status message, so for those we remove .carrier_raised again. Signed-off-by: Libor Pechacek Signed-off-by: Greg Kroah-Hartman commit 659786b73216627aa156b8ff8c07837a109f19cf Author: Craig Shelley Date: Sun Jan 2 21:59:08 2011 +0000 USB: CP210x Removed incorrect device ID commit 9926c0df7b31b2128eebe92e0e2b052f380ea464 upstream. Device ID removed 0x10C4/0x8149 for West Mountain Radio Computerized Battery Analyzer. This device is actually based on a SiLabs C8051Fxxx, see http://www.etheus.net/SiUSBXp_Linux_Driver for further info. Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman commit 31447d059064645b0629a015544eaac441a779fc Author: Craig Shelley Date: Sun Jan 2 21:51:46 2011 +0000 USB: CP210x Add two device IDs commit faea63f7ccfddfb8fc19798799fcd38c58415172 upstream. Device Ids added for IRZ Automation Teleport SG-10 GSM/GPRS Modem and DekTec DTA Plus VHF/UHF Booster/Attenuator. Signed-off-by: Craig Shelley Signed-off-by: Greg Kroah-Hartman commit b3133dba8ce1c78981887f255761d9c717d97177 Author: Márton Németh Date: Mon Dec 13 21:59:09 2010 +0100 staging: usbip: remove double giveback of URB commit 7571f089d7522a95c103558faf313c7af8856ceb upstream. In the vhci_urb_dequeue() function the TCP connection is checked twice. Each time when the TCP connection is closed the URB is unlinked and given back. Remove the second attempt of unlinking and giving back of the URB completely. This patch fixes the bug described at https://bugzilla.kernel.org/show_bug.cgi?id=24872 . Signed-off-by: Márton Németh Signed-off-by: Greg Kroah-Hartman commit 272d7ea16c12f3bd2720a862a28eeb39ca884129 Author: Vlad Yasevich Date: Wed Sep 15 10:00:26 2010 -0400 sctp: Do not reset the packet during sctp_packet_config(). commit 4bdab43323b459900578b200a4b8cf9713ac8fab upstream. sctp_packet_config() is called when getting the packet ready for appending of chunks. The function should not touch the current state, since it's possible to ping-pong between two transports when sending, and that can result packet corruption followed by skb overlfow crash. Reported-by: Thomas Dreibholz Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ebe7aad41efd6c6fbf8c943e433689289d153c93 Author: Ryan Kuester Date: Mon Apr 26 18:11:54 2010 -0500 SCSI: mptsas: fix hangs caused by ATA pass-through commit 2a1b7e575b80ceb19ea50bfa86ce0053ea57181d upstream. I may have an explanation for the LSI 1068 HBA hangs provoked by ATA pass-through commands, in particular by smartctl. First, my version of the symptoms. On an LSI SAS1068E B3 HBA running 01.29.00.00 firmware, with SATA disks, and with smartd running, I'm seeing occasional task, bus, and host resets, some of which lead to hard faults of the HBA requiring a reboot. Abusively looping the smartctl command, # while true; do smartctl -a /dev/sdb > /dev/null; done dramatically increases the frequency of these failures to nearly one per minute. A high IO load through the HBA while looping smartctl seems to improve the chance of a full scsi host reset or a non-recoverable hang. I reduced what smartctl was doing down to a simple test case which causes the hang with a single IO when pointed at the sd interface. See the code at the bottom of this e-mail. It uses an SG_IO ioctl to issue a single pass-through ATA identify device command. If the buffer userspace gives for the read data has certain alignments, the task is issued to the HBA but the HBA fails to respond. If run against the sg interface, neither the test code nor smartctl causes a hang. sd and sg handle the SG_IO ioctl slightly differently. Unless you specifically set a flag to do direct IO, sg passes a buffer of its own, which is page-aligned, to the block layer and later copies the result into the userspace buffer regardless of its alignment. sd, on the other hand, always does direct IO unless the userspace buffer fails an alignment test at block/blk-map.c line 57, in which case a page-aligned buffer is created and used for the transfer. The alignment test currently checks for word-alignment, the default setup by scsi_lib.c; therefore, userspace buffers of almost any alignment are given directly to the HBA as DMA targets. The LSI 1068 hardware doesn't seem to like at least a couple of the alignments which cross a page boundary (see the test code below). Curiously, many page-boundary-crossing alignments do work just fine. So, either the hardware has an bug handling certain alignments or the hardware has a stricter alignment requirement than the driver is advertising. If stricter alignment is required, then in no case should misaligned buffers from userspace be allowed through without being bounced or at least causing an error to be returned. It seems the mptsas driver could use blk_queue_dma_alignment() to advertise a stricter alignment requirement. If it does, sd does the right thing and bounces misaligned buffers (see block/blk-map.c line 57). The following patch to 2.6.34-rc5 makes my symptoms go away. I'm sure this is the wrong place for this code, but it gets my idea across. Acked-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 3ed36704fb8766909627b59a6564e3d43d7f033e Author: Stanislaw Gruszka Date: Tue Sep 14 16:35:14 2010 +0200 sched: Fix user time incorrectly accounted as system time on 32-bit commit e75e863dd5c7d96b91ebbd241da5328fc38a78cc upstream. We have 32-bit variable overflow possibility when multiply in task_times() and thread_group_times() functions. When the overflow happens then the scaled utime value becomes erroneously small and the scaled stime becomes i erroneously big. Reported here: https://bugzilla.redhat.com/show_bug.cgi?id=633037 https://bugzilla.kernel.org/show_bug.cgi?id=16559 Reported-by: Michael Chapman Reported-by: Ciriaco Garcia de Celis Signed-off-by: Stanislaw Gruszka Signed-off-by: Peter Zijlstra Cc: Hidetoshi Seto LKML-Reference: <20100914143513.GB8415@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f45c71c17f9d8af84a5e652904b55b6938e70383 Author: Greg Kroah-Hartman Date: Tue Jan 25 17:42:29 2011 +0800 rt2x00: add device id for windy31 usb device commit 9c4cf6d94fb362c27a24df5223ed6e327eb7279a upstream. This patch adds the device id for the windy31 USB device to the rt73usb driver. Thanks to Ralf Flaxa for reporting this and providing testing and a sample device. Reported-by: Ralf Flaxa Tested-by: Ralf Flaxa Signed-off-by: Greg Kroah-Hartman Acked-by: Ivo van Doorn Signed-off-by: John W. Linville commit 527a95060a52006117803e36ac63911540fe0cf3 Author: Paul E. McKenney Date: Tue Aug 31 17:00:18 2010 -0700 pid: make setpgid() system call use RCU read-side critical section commit 950eaaca681c44aab87a46225c9e44f902c080aa upstream. [ 23.584719] [ 23.584720] =================================================== [ 23.585059] [ INFO: suspicious rcu_dereference_check() usage. ] [ 23.585176] --------------------------------------------------- [ 23.585176] kernel/pid.c:419 invoked rcu_dereference_check() without protection! [ 23.585176] [ 23.585176] other info that might help us debug this: [ 23.585176] [ 23.585176] [ 23.585176] rcu_scheduler_active = 1, debug_locks = 1 [ 23.585176] 1 lock held by rc.sysinit/728: [ 23.585176] #0: (tasklist_lock){.+.+..}, at: [] sys_setpgid+0x5f/0x193 [ 23.585176] [ 23.585176] stack backtrace: [ 23.585176] Pid: 728, comm: rc.sysinit Not tainted 2.6.36-rc2 #2 [ 23.585176] Call Trace: [ 23.585176] [] lockdep_rcu_dereference+0x99/0xa2 [ 23.585176] [] find_task_by_pid_ns+0x50/0x6a [ 23.585176] [] find_task_by_vpid+0x1d/0x1f [ 23.585176] [] sys_setpgid+0x67/0x193 [ 23.585176] [] system_call_fastpath+0x16/0x1b [ 24.959669] type=1400 audit(1282938522.956:4): avc: denied { module_request } for pid=766 comm="hwclock" kmod="char-major-10-135" scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclas It turns out that the setpgid() system call fails to enter an RCU read-side critical section before doing a PID-to-task_struct translation. This commit therefore does rcu_read_lock() before the translation, and also does rcu_read_unlock() after the last use of the returned pointer. Reported-by: Andrew Morton Signed-off-by: Paul E. McKenney Acked-by: David Howells Cc: Jiri Slaby Cc: Oleg Nesterov Signed-off-by: Greg Kroah-Hartman commit d941cd42c4c5056eaffaa35fb30480effc9a5278 Author: Tejun Heo Date: Tue Sep 21 07:57:19 2010 +0200 percpu: fix pcpu_last_unit_cpu commit 46b30ea9bc3698bc1d1e6fd726c9601d46fa0a91 upstream. pcpu_first/last_unit_cpu are used to track which cpu has the first and last units assigned. This in turn is used to determine the span of a chunk for man/unmap cache flushes and whether an address belongs to the first chunk or not in per_cpu_ptr_to_phys(). When the number of possible CPUs isn't power of two, a chunk may contain unassigned units towards the end of a chunk. The logic to determine pcpu_last_unit_cpu was incorrect when there was an unused unit at the end of a chunk. It failed to ignore the unused unit and assigned the unused marker NR_CPUS to pcpu_last_unit_cpu. This was discovered through kdump failure which was caused by malfunctioning per_cpu_ptr_to_phys() on a kvm setup with 50 possible CPUs by CAI Qian. Signed-off-by: Tejun Heo Reported-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit 1ecd68e25ed5ab04861ea146cc87ce936481d79f Author: Mel Gorman Date: Thu Sep 9 16:38:16 2010 -0700 mm: page allocator: update free page counters after pages are placed on the free list commit 72853e2991a2702ae93aaf889ac7db743a415dd3 upstream. When allocating a page, the system uses NR_FREE_PAGES counters to determine if watermarks would remain intact after the allocation was made. This check is made without interrupts disabled or the zone lock held and so is race-prone by nature. Unfortunately, when pages are being freed in batch, the counters are updated before the pages are added on the list. During this window, the counters are misleading as the pages do not exist yet. When under significant pressure on systems with large numbers of CPUs, it's possible for processes to make progress even though they should have been stalled. This is particularly problematic if a number of the processes are using GFP_ATOMIC as the min watermark can be accidentally breached and in extreme cases, the system can livelock. This patch updates the counters after the pages have been added to the list. This makes the allocator more cautious with respect to preserving the watermarks and mitigates livelock possibilities. [akpm@linux-foundation.org: avoid modifying incoming args] Signed-off-by: Mel Gorman Reviewed-by: Rik van Riel Reviewed-by: Minchan Kim Reviewed-by: KAMEZAWA Hiroyuki Reviewed-by: Christoph Lameter Reviewed-by: KOSAKI Motohiro Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit baa466d398a90c02c01658f870f908910f4775d5 Author: Mel Gorman Date: Thu Sep 9 16:38:18 2010 -0700 mm: page allocator: drain per-cpu lists after direct reclaim allocation fails commit 9ee493ce0a60bf42c0f8fd0b0fe91df5704a1cbf upstream. When under significant memory pressure, a process enters direct reclaim and immediately afterwards tries to allocate a page. If it fails and no further progress is made, it's possible the system will go OOM. However, on systems with large amounts of memory, it's possible that a significant number of pages are on per-cpu lists and inaccessible to the calling process. This leads to a process entering direct reclaim more often than it should increasing the pressure on the system and compounding the problem. This patch notes that if direct reclaim is making progress but allocations are still failing that the system is already under heavy pressure. In this case, it drains the per-cpu lists and tries the allocation a second time before continuing. Signed-off-by: Mel Gorman Reviewed-by: Minchan Kim Reviewed-by: KAMEZAWA Hiroyuki Reviewed-by: KOSAKI Motohiro Reviewed-by: Christoph Lameter Cc: Dave Chinner Cc: Wu Fengguang Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 35c27b582a9d67ab4e4ed64e662a3eb148999735 Author: Christoph Lameter Date: Thu Sep 9 16:38:17 2010 -0700 mm: page allocator: calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake commit aa45484031ddee09b06350ab8528bfe5b2c76d1c upstream. Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is cheaper than scanning a number of lists. To avoid synchronization overhead, counter deltas are maintained on a per-cpu basis and drained both periodically and when the delta is above a threshold. On large CPU systems, the difference between the estimated and real value of NR_FREE_PAGES can be very high. If NR_FREE_PAGES is much higher than number of real free page in buddy, the VM can allocate pages below min watermark, at worst reducing the real number of pages to zero. Even if the OOM killer kills some victim for freeing memory, it may not free memory if the exit path requires a new page resulting in livelock. This patch introduces a zone_page_state_snapshot() function (courtesy of Christoph) that takes a slightly more accurate view of an arbitrary vmstat counter. It is used to read NR_FREE_PAGES while kswapd is awake to avoid the watermark being accidentally broken. The estimate is not perfect and may result in cache line bounces but is expected to be lighter than the IPI calls necessary to continually drain the per-cpu counters while kswapd is awake. Signed-off-by: Christoph Lameter Signed-off-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 22b19ee0392cbc7e5d4fe3159113f585bf212944 Author: David Howells Date: Fri Sep 10 09:59:51 2010 +0100 KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring commit 3d96406c7da1ed5811ea52a3b0905f4f0e295376 upstream. Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership of the parent process's session keyring whether or not the parent has a session keyring [CVE-2010-2960]. This results in the following oops: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 IP: [] keyctl_session_to_parent+0x251/0x443 ... Call Trace: [] ? keyctl_session_to_parent+0x67/0x443 [] ? __do_fault+0x24b/0x3d0 [] sys_keyctl+0xb4/0xb8 [] system_call_fastpath+0x16/0x1b if the parent process has no session keyring. If the system is using pam_keyinit then it mostly protected against this as all processes derived from a login will have inherited the session keyring created by pam_keyinit during the log in procedure. To test this, pam_keyinit calls need to be commented out in /etc/pam.d/. Reported-by: Tavis Ormandy Signed-off-by: David Howells Acked-by: Tavis Ormandy Cc: dann frazier Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ef29fb3e1e3aa866828fe419ad4c360ac26d416c Author: David Howells Date: Fri Sep 10 09:59:46 2010 +0100 KEYS: Fix RCU no-lock warning in keyctl_session_to_parent() commit 9d1ac65a9698513d00e5608d93fca0c53f536c14 upstream. There's an protected access to the parent process's credentials in the middle of keyctl_session_to_parent(). This results in the following RCU warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by keyctl-session-/2137: #0: (tasklist_lock){.+.+..}, at: [] keyctl_session_to_parent+0x60/0x236 stack backtrace: Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1 Call Trace: [] lockdep_rcu_dereference+0xaa/0xb3 [] keyctl_session_to_parent+0xed/0x236 [] sys_keyctl+0xb4/0xb6 [] system_call_fastpath+0x16/0x1b The code should take the RCU read lock to make sure the parents credentials don't go away, even though it's holding a spinlock and has IRQ disabled. Signed-off-by: David Howells Signed-off-by: Linus Torvalds Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit b62b1d7df40640fe8b5d257b84add8b009752153 Author: Eric Paris Date: Wed Jul 28 10:18:37 2010 -0400 inotify: send IN_UNMOUNT events commit 611da04f7a31b2208e838be55a42c7a1310ae321 upstream. Since the .31 or so notify rewrite inotify has not sent events about inodes which are unmounted. This patch restores those events. Signed-off-by: Eric Paris Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 3e32b32342f9f58b70053ced9a9663228a125504 Author: Petr Tesarik Date: Wed Sep 15 15:35:48 2010 -0700 IA64: Optimize ticket spinlocks in fsys_rt_sigprocmask commit 2d2b6901649a62977452be85df53eda2412def24 upstream. Tony's fix (f574c843191728d9407b766a027f779dcd27b272) has a small bug, it incorrectly uses "r3" as a scratch register in the first of the two unlock paths ... it is also inefficient. Optimize the fast path again. Signed-off-by: Petr Tesarik Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit f0d44f184f1cbce5fb831b07112bb609cb966300 Author: Tony Luck Date: Thu Sep 9 15:16:56 2010 -0700 IA64: fix siglock commit f574c843191728d9407b766a027f779dcd27b272 upstream. When ia64 converted to using ticket locks, an inline implementation of trylock/unlock in fsys.S was missed. This was not noticed because in most circumstances it simply resulted in using the slow path because the siglock was apparently not available (under old spinlock rules). Problems occur when the ticket spinlock has value 0x0 (when first initialised, or when it wraps around). At this point the fsys.S code acquires the lock (changing the 0x0 to 0x1. If another process attempts to get the lock at this point, it will change the value from 0x1 to 0x2 (using new ticket lock rules). Then the fsys.S code will free the lock using old spinlock rules by writing 0x0 to it. From here a variety of bad things can happen. Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman commit bc498e99c23ea0da7ee007001a7e7802f8ef3ca2 Author: Jean Delvare Date: Wed Jan 12 21:55:09 2011 +0100 hwmon: (via686a) Initialize fan_div values commit f790674d3f87df6390828ac21a7d1530f71b59c8 upstream. Functions set_fan_min() and set_fan_div() assume that the fan_div values have already been read from the register. The driver currently doesn't initialize them at load time, they are only set when function via686a_update_device() is called. This means that set_fan_min() and set_fan_div() misbehave if, for example, "sensors -s" is called before any monitoring application (e.g. "sensors") is has been run. Fix the problem by always initializing the fan_div values at device bind time. Signed-off-by: Jean Delvare Acked-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 6192bed1743d6a1bfc7c6620b3856f4284e31f4b Author: Matt Helsley Date: Mon Sep 13 13:01:18 2010 -0700 hw breakpoints: Fix pid namespace bug commit 068e35eee9ef98eb4cab55181977e24995d273be upstream. Hardware breakpoints can't be registered within pid namespaces because tsk->pid is passed rather than the pid in the current namespace. (See https://bugzilla.kernel.org/show_bug.cgi?id=17281 ) This is a quick fix demonstrating the problem but is not the best method of solving the problem since passing pids internally is not the best way to avoid pid namespace bugs. Subsequent patches will show a better solution. Much thanks to Frederic Weisbecker for doing the bulk of the work finding this bug. Reported-by: Robin Green Signed-off-by: Matt Helsley Signed-off-by: Peter Zijlstra Cc: Prasad Cc: Arnaldo Carvalho de Melo Cc: Steven Rostedt Cc: Will Deacon Cc: Mahesh Salgaonkar LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Frederic Weisbecker Signed-off-by: Greg Kroah-Hartman commit 2d41b2aadaf5d3cb8300fcd418f6ae932902b11b Author: Daniel J Blueman Date: Tue Aug 17 23:56:55 2010 +0100 Fix unprotected access to task credentials in waitid() commit f362b73244fb16ea4ae127ced1467dd8adaa7733 upstream. Using a program like the following: #include #include #include #include int main() { id_t id; siginfo_t infop; pid_t res; id = fork(); if (id == 0) { sleep(1); exit(0); } kill(id, SIGSTOP); alarm(1); waitid(P_PID, id, &infop, WCONTINUED); return 0; } to call waitid() on a stopped process results in access to the child task's credentials without the RCU read lock being held - which may be replaced in the meantime - eliciting the following warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/exit.c:1460 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by waitid02/22252: #0: (tasklist_lock){.?.?..}, at: [] do_wait+0xc5/0x310 #1: (&(&sighand->siglock)->rlock){-.-...}, at: [] wait_consider_task+0x19a/0xbe0 stack backtrace: Pid: 22252, comm: waitid02 Not tainted 2.6.35-323cd+ #3 Call Trace: [] lockdep_rcu_dereference+0xa4/0xc0 [] wait_consider_task+0xaf1/0xbe0 [] do_wait+0xf5/0x310 [] sys_waitid+0x86/0x1f0 [] ? child_wait_callback+0x0/0x70 [] system_call_fastpath+0x16/0x1b This is fixed by holding the RCU read lock in wait_task_continued() to ensure that the task's current credentials aren't destroyed between us reading the cred pointer and us reading the UID from those credentials. Furthermore, protect wait_task_stopped() in the same way. We don't need to keep holding the RCU read lock once we've read the UID from the credentials as holding the RCU read lock doesn't stop the target task from changing its creds under us - so the credentials may be outdated immediately after we've read the pointer, lock or no lock. Signed-off-by: Daniel J Blueman Signed-off-by: David Howells Acked-by: Paul E. McKenney Acked-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fba2e5ee19c351dc83008d29c9441b17a7d988af Author: Dan Rosenberg Date: Wed Sep 15 19:08:24 2010 -0400 drivers/video/via/ioctl.c: prevent reading uninitialized stack memory commit b4aaa78f4c2f9cde2f335b14f4ca30b01f9651ca upstream. The VIAFB_GET_INFO device ioctl allows unprivileged users to read 246 bytes of uninitialized stack memory, because the "reserved" member of the viafb_ioctl_info struct declared on the stack is not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Florian Tobias Schandinat Signed-off-by: Greg Kroah-Hartman commit 7afb10e792956dba10b8df9f95b50420854f6923 Author: Dan Rosenberg Date: Wed Sep 22 13:05:09 2010 -0700 drivers/video/sis/sis_main.c: prevent reading uninitialized stack memory commit fd02db9de73faebc51240619c7c7f99bee9f65c7 upstream. The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "reserved" member of the fb_vblank struct declared on the stack is not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Cc: Thomas Winischhofer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 44498d9d63480b416a23e67a57c51481c861f8a3 Author: Jan Kara Date: Tue Sep 21 11:49:01 2010 +0200 char: Mark /dev/zero and /dev/kmem as not capable of writeback commit 371d217ee1ff8b418b8f73fb2a34990f951ec2d4 upstream. These devices don't do any writeback but their device inodes still can get dirty so mark bdi appropriately so that bdi code does the right thing and files inodes to lists of bdi carrying the device inodes. Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 060049e494a4f234002941aa2403d849ca8c883c Author: Michael Chan Date: Tue Jun 1 15:05:36 2010 +0000 bnx2: Fix hang during rmmod bnx2. commit f048fa9c8686119c3858a463cab6121dced7c0bf upstream. The regression is caused by: commit 4327ba435a56ada13eedf3eb332e583c7a0586a9 bnx2: Fix netpoll crash. If ->open() and ->close() are called multiple times, the same napi structs will be added to dev->napi_list multiple times, corrupting the dev->napi_list. This causes free_netdev() to hang during rmmod. We fix this by calling netif_napi_del() during ->close(). Also, bnx2_init_napi() must not be in the __devinit section since it is called by ->open(). Signed-off-by: Michael Chan Signed-off-by: Benjamin Li Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54142c959f88de9f41e637f39306085b8d7defcc Author: Benjamin Li Date: Tue Mar 23 13:13:11 2010 +0000 bnx2: Fix netpoll crash. commit 4327ba435a56ada13eedf3eb332e583c7a0586a9 upstream. The bnx2 driver calls netif_napi_add() for all the NAPI structs during ->probe() time but not all of them will be used if we're not in MSI-X mode. This creates a problem for netpoll since it will poll all the NAPI structs in the dev_list whether or not they are scheduled, resulting in a crash when we access structure fields not initialized for that vector. We fix it by moving the netif_napi_add() call to ->open() after the number of IRQ vectors has been determined. Signed-off-by: Benjamin Li Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bd33d194a874963afdc3261fa1158b720e90633c Author: Karsten Wiese Date: Tue Jan 4 01:20:37 2011 +0100 ALSA: snd-usb-us122l: Fix missing NULL checks commit cdce2db74e156fbd9a2dc3c7b246166f8b70955b upstream. Fix missing NULL checks in usb_stream_hwdep_poll() and usb_stream_hwdep_ioctl(). Wake up poll waiters before returning from usb_stream_hwdep_ioctl(). Signed-off-by: Karsten Wiese Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8228803d07f7f154e97a71475ccd547afeea86bf Author: Jeff Moyer Date: Fri Sep 10 14:16:00 2010 -0700 aio: check for multiplication overflow in do_io_submit commit 75e1c70fc31490ef8a373ea2a4bea2524099b478 upstream. Tavis Ormandy pointed out that do_io_submit does not do proper bounds checking on the passed-in iocb array:        if (unlikely(nr < 0))                return -EINVAL;        if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(iocbpp)))))                return -EFAULT;                      ^^^^^^^^^^^^^^^^^^ The attached patch checks for overflow, and if it is detected, the number of iocbs submitted is scaled down to a number that will fit in the long.  This is an ok thing to do, as sys_io_submit is documented as returning the number of iocbs submitted, so callers should handle a return value of less than the 'nr' argument passed in. Reported-by: Tavis Ormandy Signed-off-by: Jeff Moyer Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ca4711e759f048f03ac3118bce3f82df3cf664ac Author: Sarah Sharp Date: Wed Feb 23 18:12:29 2011 -0800 xhci: Fix cycle bit calculation during stall handling. commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream. When an endpoint stalls, we need to update the xHCI host's internal dequeue pointer to move it past the stalled transfer. This includes updating the cycle bit (TRB ownership bit) if we have moved the dequeue pointer past a link TRB with the toggle cycle bit set. When we're trying to find the new dequeue segment, find_trb_seg() is supposed to keep track of whether we've passed any link TRBs with the toggle cycle bit set. However, this while loop's body while (cur_seg->trbs > trb || &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) { Will never get executed if the ring only contains one segment. find_trb_seg() will return immediately, without updating the new cycle bit. Since find_trb_seg() has no idea where in the segment the TD that stalled was, make the caller, xhci_find_new_dequeue_state(), check for this special case and update the cycle bit accordingly. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by: Sarah Sharp Tested-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fa2740a7a5d91a0f95c6b4cf3d809c15f0e1b901 Author: Sebastian Andrzej Siewior Date: Tue Feb 8 21:07:40 2011 +0100 USB: isp1760: Implement solution for erratum 2 commit b14e840d04dba211fbdc930247e379085623eacd upstream. The document says: |2.1 Problem description | When at least two USB devices are simultaneously running, it is observed that | sometimes the INT corresponding to one of the USB devices stops occurring. This may | be observed sometimes with USB-to-serial or USB-to-network devices. | The problem is not noticed when only USB mass storage devices are running. |2.2 Implication | This issue is because of the clearing of the respective Done Map bit on reading the ATL | PTD Done Map register when an INT is generated by another PTD completion, but is not | found set on that read access. In this situation, the respective Done Map bit will remain | reset and no further INT will be asserted so the data transfer corresponding to that USB | device will stop. |2.3 Workaround | An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can | be implemented and if a certain Done bit is never set, verification of the PTD completion | can be done by reading PTD contents (valid bit). | This is a proven workaround implemented in software. Russell King run into this with an USB-to-serial converter. This patch implements his suggestion to enable the high frequent SOF interrupt only at the time we have ATL packages queued. It goes even one step further and enables the SOF interrupt only if we have more than one ATL packet queued at the same time. Tested-by: Russell King Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman commit 1a5e3da8abb0d354e906fc2e258e6ddf90a7ea6e Author: wangyanqing Date: Fri Mar 11 06:24:38 2011 -0800 USB: serial: ch341: add new id commit d0781383038e983a63843a9a6a067ed781db89c1 upstream. I picked up a new DAK-780EX(professional digitl reverb/mix system), which use CH341T chipset to communication with computer on 3/2011 and the CH341T's vendor code is 1a86 Looking up the CH341T's vendor and product id's I see: 1a86 QinHeng Electronics 5523 CH341 in serial mode, usb to serial port converter CH341T,CH341 are the products of the same company, maybe have some common hardware, and I test the ch341.c works well with CH341T Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 87ddb1aae235017a3d244a87cc45655a7a724755 Author: Jiri Slaby Date: Mon Feb 28 10:34:06 2011 +0100 USB: serial/kobil_sct, fix potential tty NULL dereference commit 6960f40a954619857e7095a6179eef896f297077 upstream. Make sure that we check the return value of tty_port_tty_get. Sometimes it may return NULL and we later dereference that. The only place here is in kobil_read_int_callback, so fix it. Signed-off-by: Jiri Slaby Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 1fdde2920cdf3926e64d4973bfc4d326d99e7079 Author: Senthil Balasubramanian Date: Wed Dec 22 21:14:20 2010 +0530 ath9k_hw: Fix incorrect macversion and macrev checks commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream. There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Signed-off-by: Senthil Balasubramanian Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 3516421d665e1542c8058b633c7fc1449b5cba97 Author: Andreas Herrmann Date: Tue Mar 15 15:31:37 2011 +0100 x86, quirk: Fix SB600 revision check commit 1d3e09a304e6c4e004ca06356578b171e8735d3c upstream. Commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 (x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems) introduced a regression. It removed some SB600 specific code to determine the revision ID without adapting a corresponding revision ID check for SB600. See this mail thread: http://marc.info/?l=linux-kernel&m=129980296006380&w=2 This patch adapts the corresponding check to cover all SB600 revisions. Tested-by: Wang Lei Signed-off-by: Andreas Herrmann Cc: Andrew Morton LKML-Reference: <20110315143137.GD29499@alberich.amd.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1ca398974b6c489d6737f52b69e05a9d49e1f295 Author: Sean Hefty Date: Wed Feb 23 08:17:40 2011 -0800 IB/cm: Bump reference count on cm_id before invoking callback commit 29963437a48475036353b95ab142bf199adb909e upstream. When processing a SIDR REQ, the ib_cm allocates a new cm_id. The refcount of the cm_id is initialized to 1. However, cm_process_work will decrement the refcount after invoking all callbacks. The result is that the cm_id will end up with refcount set to 0 by the end of the sidr req handler. If a user tries to destroy the cm_id, the destruction will proceed, under the incorrect assumption that no other threads are referencing the cm_id. This can lead to a crash when the cm callback thread tries to access the cm_id. This problem was noticed as part of a larger investigation with kernel crashes in the rdma_cm when running on a real time OS. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit ccfb041348b62a233c66ed003cf99d2ec6e69f91 Author: Sean Hefty Date: Wed Feb 23 08:11:32 2011 -0800 RDMA/cma: Fix crash in request handlers commit 25ae21a10112875763c18b385624df713a288a05 upstream. Doug Ledford and Red Hat reported a crash when running the rdma_cm on a real-time OS. The crash has the following call trace: cm_process_work cma_req_handler cma_disable_callback rdma_create_id kzalloc init_completion cma_get_net_info cma_save_net_info cma_any_addr cma_zero_addr rdma_translate_ip rdma_copy_addr cma_acquire_dev rdma_addr_get_sgid ib_find_cached_gid cma_attach_to_dev ucma_event_handler kzalloc ib_copy_ah_attr_to_user cma_comp [ preempted ] cma_write copy_from_user ucma_destroy_id copy_from_user _ucma_find_context ucma_put_ctx ucma_free_ctx rdma_destroy_id cma_exch cma_cancel_operation rdma_node_get_transport rt_mutex_slowunlock bad_area_nosemaphore oops_enter They were able to reproduce the crash multiple times with the following details: Crash seems to always happen on the: mutex_unlock(&conn_id->handler_mutex); as conn_id looks to have been freed during this code path. An examination of the code shows that a race exists in the request handlers. When a new connection request is received, the rdma_cm allocates a new connection identifier. This identifier has a single reference count on it. If a user calls rdma_destroy_id() from another thread after receiving a callback, rdma_destroy_id will proceed to destroy the id and free the associated memory. However, the request handlers may still be in the process of running. When control returns to the request handlers, they can attempt to access the newly created identifiers. Fix this by holding a reference on the newly created rdma_cm_id until the request handler is through accessing it. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 925f1e4d33b86cd8f425507b9d6910e2dd752a10 Author: Seth Heasley Date: Fri Mar 11 11:57:42 2011 -0800 ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controller commit 64a3903d0885879ba8706a8bcf71c5e3e7664db2 upstream. This patch adds an updated SATA RAID DeviceID for the Intel Patsburg PCH. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit d7ffbbd8f1c0c90f02d3622074b5c964b9de3c06 Author: Seth Heasley Date: Mon Jan 10 12:57:17 2011 -0800 ahci: AHCI mode SATA patch for Intel DH89xxCC DeviceIDs commit a4a461a6df6c0481d5a3d61660ed97f5b539cf16 upstream. This patch adds the AHCI-mode SATA DeviceID for the Intel DH89xxCC PCH. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 9a377c7d08fffaeace59d60b8432829d17cba77a Author: Seth Heasley Date: Thu Sep 9 09:44:56 2010 -0700 ahci: AHCI and RAID mode SATA patch for Intel Patsburg DeviceIDs commit 992b3fb9b5391bc4de5b42bb810dc6dd583a6c4a upstream. This patch adds the Intel Patsburg (PCH) SATA AHCI and RAID Controller DeviceIDs. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 7203bdb035b9145b565da28d71a823d647425cee Author: Kamal Mostafa Date: Thu Feb 3 17:38:05 2011 -0800 x86: Emit "mem=nopentium ignored" warning when not supported commit 9a6d44b9adb777ca9549e88cd55bd8f2673c52a2 upstream. Emit warning when "mem=nopentium" is specified on any arch other than x86_32 (the only that arch supports it). Signed-off-by: Kamal Mostafa BugLink: http://bugs.launchpad.net/bugs/553464 Cc: Yinghai Lu Cc: Len Brown Cc: Rafael J. Wysocki LKML-Reference: <1296783486-23033-2-git-send-email-kamal@canonical.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit fcf391eef3662d8160ba3cd14aa000c43dd84920 Author: Kamal Mostafa Date: Thu Feb 3 17:38:04 2011 -0800 x86: Fix panic when handling "mem={invalid}" param commit 77eed821accf5dd962b1f13bed0680e217e49112 upstream. Avoid removing all of memory and panicing when "mem={invalid}" is specified, e.g. mem=blahblah, mem=0, or mem=nopentium (on platforms other than x86_32). Signed-off-by: Kamal Mostafa BugLink: http://bugs.launchpad.net/bugs/553464 Cc: Yinghai Lu Cc: Len Brown Cc: Rafael J. Wysocki LKML-Reference: <1296783486-23033-1-git-send-email-kamal@canonical.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b0e080d125f14ce2cde9a2ab50b2c2d0fb5609df Author: Steven Rostedt Date: Thu Feb 10 21:26:13 2011 -0500 ftrace: Fix memory leak with function graph and cpu hotplug commit 868baf07b1a259f5f3803c1dc2777b6c358f83cf upstream. When the fuction graph tracer starts, it needs to make a special stack for each task to save the real return values of the tasks. All running tasks have this stack created, as well as any new tasks. On CPU hot plug, the new idle task will allocate a stack as well when init_idle() is called. The problem is that cpu hotplug does not create a new idle_task. Instead it uses the idle task that existed when the cpu went down. ftrace_graph_init_task() will add a new ret_stack to the task that is given to it. Because a clone will make the task have a stack of its parent it does not check if the task's ret_stack is already NULL or not. When the CPU hotplug code starts a CPU up again, it will allocate a new stack even though one already existed for it. The solution is to treat the idle_task specially. In fact, the function_graph code already does, just not at init_idle(). Instead of using the ftrace_graph_init_task() for the idle task, which that function expects the task to be a clone, have a separate ftrace_graph_init_idle_task(). Also, we will create a per_cpu ret_stack that is used by the idle task. When we call ftrace_graph_init_idle_task() it will check if the idle task's ret_stack is NULL, if it is, then it will assign it the per_cpu ret_stack. Reported-by: Benjamin Herrenschmidt Suggested-by: Peter Zijlstra Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 36aeae772759b927bd784e1bf9501c2962084149 Author: Andrey Vagin Date: Wed Mar 9 15:22:23 2011 -0800 x86/mm: Handle mm_fault_error() in kernel space commit f86268549f424f83b9eb0963989270e14fbfc3de upstream. mm_fault_error() should not execute oom-killer, if page fault occurs in kernel space. E.g. in copy_from_user()/copy_to_user(). This would happen if we find ourselves in OOM on a copy_to_user(), or a copy_from_user() which faults. Without this patch, the kernels hangs up in copy_from_user(), because OOM killer sends SIG_KILL to current process, but it can't handle a signal while in syscall, then the kernel returns to copy_from_user(), reexcute current command and provokes page_fault again. With this patch the kernel return -EFAULT from copy_from_user(). The code, which checks that page fault occurred in kernel space, has been copied from do_sigbus(). This situation is handled by the same way on powerpc, xtensa, tile, ... Signed-off-by: Andrey Vagin Signed-off-by: Andrew Morton Cc: "H. Peter Anvin" Cc: Linus Torvalds LKML-Reference: <201103092322.p29NMNPH001682@imap1.linux-foundation.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 34dce55d3302779116b6b9bc82cb8dfc50acbd11 Author: Florian Fainelli Date: Sun Feb 27 19:53:53 2011 +0100 MIPS: MTX-1: Make au1000_eth probe all PHY addresses commit bf3a1eb85967dcbaae42f4fcb53c2392cec32677 upstream. When au1000_eth probes the MII bus for PHY address, if we do not set au1000_eth platform data's phy_search_highest_address, the MII probing logic will exit early and will assume a valid PHY is found at address 0. For MTX-1, the PHY is at address 31, and without this patch, the link detection/speed/duplex would not work correctly. Signed-off-by: Florian Fainelli To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/2111/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit eed80090b96646eb9c670bab22cb6aba4b42497f Author: Tejun Heo Date: Thu Dec 9 15:59:32 2010 +0100 libata: no special completion processing for EH commands commit f08dc1ac6b15c681f4643d8da1700e06c3855608 upstream. ata_qc_complete() contains special handling for certain commands. For example, it schedules EH for device revalidation after certain configurations are changed. These shouldn't be applied to EH commands but they were. In most cases, it doesn't cause an actual problem because EH doesn't issue any command which would trigger special handling; however, ACPI can issue such commands via _GTF which can cause weird interactions. Restructure ata_qc_complete() such that EH commands are always passed on to __ata_qc_complete(). stable: Please apply to -stable only after 2.6.38 is released. Signed-off-by: Tejun Heo Reported-by: Kyle McMartin Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 5e6964da4ef23f7c43d0fa3ade7b8898573a2b42 Author: Axel Lin Date: Mon Mar 7 11:04:24 2011 +0800 mtd: add "platform:" prefix for platform modalias commit c804c733846572ca85c2bba60c7fe6fa024dff18 upstream. Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS with "platform:"), the platform modalias is prefixed with "platform:". Signed-off-by: Axel Lin Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit cad501be7dab2f50df805e3e04fac36b6276156a Author: Antony Pavlov Date: Fri Feb 11 13:00:37 2011 +0300 mtd: jedec_probe: Change variable name from cfi_p to cfi commit efba2e313ea1b1bd69a7c4659263becf43bb1adc upstream. In the following commit, we'll need to use the CMD() macro in order to fix the initialisation of the sector_erase_cmd field. That requires the local variable to be called 'cfi', so change it first in a simple patch. Signed-off-by: Antony Pavlov Acked-by: Guillaume LECERF Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 4a4465f1079bb6bb733e3ea5de79effc08f54bf2 Author: Hans de Goede Date: Sun Mar 13 13:50:33 2011 +0100 hwmon/f71882fg: Set platform drvdata to NULL later commit d9ebaa45472c92704f4814682eec21455edcfa1f upstream. This avoids a possible race leading to trying to dereference NULL. Signed-off-by: Hans de Goede Acked-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 430681f49ab17c025d631d80436143286436a828 Author: Vasiliy Kulikov Date: Wed Mar 2 00:33:13 2011 +0300 net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b upstream. Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't allow anybody load any module not related to networking. This patch restricts an ability of autoloading modules to netdev modules with explicit aliases. This fixes CVE-2011-1019. Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior of loading netdev modules by name (without any prefix) for processes with CAP_SYS_MODULE to maintain the compatibility with network scripts that use autoloading netdev modules by aliases like "eth0", "wlan0". Currently there are only three users of the feature in the upstream kernel: ipip, ip_gre and sit. root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) -- root@albatros:~# grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: fffffff800001000 CapEff: fffffff800001000 CapBnd: fffffff800001000 root@albatros:~# modprobe xfs FATAL: Error inserting xfs (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted root@albatros:~# lsmod | grep xfs root@albatros:~# ifconfig xfs xfs: error fetching interface information: Device not found root@albatros:~# lsmod | grep xfs root@albatros:~# lsmod | grep sit root@albatros:~# ifconfig sit sit: error fetching interface information: Device not found root@albatros:~# lsmod | grep sit root@albatros:~# ifconfig sit0 sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 root@albatros:~# lsmod | grep sit sit 10457 0 tunnel4 2957 1 sit For CAP_SYS_MODULE module loading is still relaxed: root@albatros:~# grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: ffffffffffffffff CapEff: ffffffffffffffff CapBnd: ffffffffffffffff root@albatros:~# ifconfig xfs xfs: error fetching interface information: Device not found root@albatros:~# lsmod | grep xfs xfs 745319 0 Reference: https://lkml.org/lkml/2011/2/24/203 Signed-off-by: Vasiliy Kulikov Signed-off-by: Michael Tokarev Acked-by: David S. Miller Acked-by: Kees Cook Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit a574ce70da46d41ac46abff2915f771ee9f9df6a Author: Olivier Grenie Date: Fri Jan 14 13:58:59 2011 -0300 DiB7000M: add pid filtering commit e192a7cf0effe7680264a5bc35c0ad1bdcdc921c upstream. This patch adds the pid filtering for the dib7000M demod. It also corrects the pid filtering for the dib7700 based board. It should prevent an oops, when using dib7700p based board. References: https://bugzilla.novell.com/show_bug.cgi?id=644807 Signed-off-by: Olivier Grenie Signed-off-by: Patrick Boettcher Tested-by: Pavel SKARKA Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0678b7c36a4d38946740ad0f2b0c4411397eb370 Author: Ivan Vecera Date: Thu Jan 27 12:24:11 2011 +0100 r8169: use RxFIFO overflow workaround for 8168c chipset. commit b5ba6d12bdac21bc0620a5089e0f24e362645efd upstream. I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts generating RxFIFO overflow errors. The result is an infinite loop in interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11. With the workaround everything goes fine. Signed-off-by: Ivan Vecera Acked-by: Francois Romieu Cc: Hayes Signed-off-by: Greg Kroah-Hartman commit be0484472b6fff8b331ce8be44d737b88e57a130 Author: roel Date: Tue Mar 8 22:32:26 2011 +0100 nfsd: wrong index used in inner loop commit 3ec07aa9522e3d5e9d5ede7bef946756e623a0a0 upstream. Index i was already used in the outer loop Signed-off-by: Roel Kluin Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 9147532184cd5d39a677ad15c5b9a7fa9cea631a Author: Matt Evans Date: Mon Mar 7 17:26:04 2011 +0530 powerpc/kexec: Fix orphaned offline CPUs across kexec Commit: e8e5c2155b0035b6e04f29be67f6444bc914005b upstream When CPU hotplug is used, some CPUs may be offline at the time a kexec is performed. The subsequent kernel may expect these CPUs to be already running, and will declare them stuck. On pseries, there's also a soft-offline (cede) state that CPUs may be in; this can also cause problems as the kexeced kernel may ask RTAS if they're online -- and RTAS would say they are. The CPU will either appear stuck, or will cause a crash as we replace its cede loop beneath it. This patch kicks each present offline CPU awake before the kexec, so that none are forever lost to these assumptions in the subsequent kernel. Now, the behaviour is that all available CPUs that were offlined are now online & usable after the kexec. This mimics the behaviour of a full reboot (on which all CPUs will be restarted). Signed-off-by: Matt Evans Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit 333200c5233cc5c5a472977e38fcfe7dc246d83f Author: Jan Engelhardt Date: Wed Mar 2 12:10:13 2011 +0100 netfilter: nf_log: avoid oops in (un)bind with invalid nfproto values commit 9ef0298a8e5730d9a46d640014c727f3b4152870 upstream. Like many other places, we have to check that the array index is within allowed limits, or otherwise, a kernel oops and other nastiness can ensue when we access memory beyond the end of the array. [ 5954.115381] BUG: unable to handle kernel paging request at 0000004000000000 [ 5954.120014] IP: __find_logger+0x6f/0xa0 [ 5954.123979] nf_log_bind_pf+0x2b/0x70 [ 5954.123979] nfulnl_recv_config+0xc0/0x4a0 [nfnetlink_log] [ 5954.123979] nfnetlink_rcv_msg+0x12c/0x1b0 [nfnetlink] ... The problem goes back to v2.6.30-rc1~1372~1342~31 where nf_log_bind was decoupled from nf_log_register. Reported-by: Miguel Di Ciurcio Filho , via irc.freenode.net/#netfilter Signed-off-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit a3e580e27b823487f5049dde077253915351409a Author: Maxim Uvarov Date: Tue May 11 05:41:08 2010 +0000 powerpc/crashdump: Do not fail on NULL pointer dereferencing commit 426b6cb478e60352a463a0d1ec75c1c9fab30b13 upstream. Signed-off-by: Maxim Uvarov Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit 5c1ce60272a33ea4864e24d7dea40af3d947374a Author: Michael Neuling Date: Mon May 10 20:28:26 2010 +0000 powerpc/kexec: Speedup kexec hash PTE tear down commit d504bed676caad29a3dba3d3727298c560628f5c upstream. Currently for kexec the PTE tear down on 1TB segment systems normally requires 3 hcalls for each PTE removal. On a machine with 32GB of memory it can take around a minute to remove all the PTEs. This optimises the path so that we only remove PTEs that are valid. It also uses the read 4 PTEs at once HCALL. For the common case where a PTEs is invalid in a 1TB segment, this turns the 3 HCALLs per PTE down to 1 HCALL per 4 PTEs. This gives an > 10x speedup in kexec times on PHYP, taking a 32GB machine from around 1 minute down to a few seconds. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit 543366ccb6d8fe2b42e5653c374b1109208b4700 Author: Michael Neuling Date: Mon May 10 20:28:26 2010 +0000 powerpc/pseries: Add hcall to read 4 ptes at a time in real mode commit f90ece28c1f5b3ec13fe481406857fe92f4bc7d1 upstream. This adds plpar_pte_read_4_raw() which can be used read 4 PTEs from PHYP at a time, while in real mode. It also creates a new hcall9 which can be used in real mode. It's the same as plpar_hcall9 but minus the tracing hcall statistics which may require variables outside the RMO. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal Cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit c006ef62a4609974e184814c6455cb53603a93ff Author: Anton Blanchard Date: Mon May 10 16:27:38 2010 +0000 powerpc/kdump: Use chip->shutdown to disable IRQs commit 5d7a87217de48b234b3c8ff8a73059947d822e07 upstream. I saw this in a kdump kernel: IOMMU table initialized, virtual merging enabled Interrupt 155954 (real) is invalid, disabling it. Interrupt 155953 (real) is invalid, disabling it. ie we took some spurious interrupts. default_machine_crash_shutdown tries to disable all interrupt sources but uses chip->disable which maps to the default action of: static void default_disable(unsigned int irq) { } If we use chip->shutdown, then we actually mask the IRQ: static void default_shutdown(unsigned int irq) { struct irq_desc *desc = irq_to_desc(irq); desc->chip->mask(irq); desc->status |= IRQ_MASKED; } Not sure why we don't implement a ->disable action for xics.c, or why default_disable doesn't mask the interrupt. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal Signed-off-by: Greg Kroah-Hartman commit efa2edb38d914d449f4f574ac3003637631484d2 Author: Anton Blanchard Date: Mon May 10 16:25:51 2010 +0000 powerpc/kdump: CPUs assume the context of the oopsing CPU commit 0644079410065567e3bb31fcb8e6441f2b7685a9 upstream. We wrap the crash_shutdown_handles[] calls with longjmp/setjmp, so if any of them fault we can recover. The problem is we add a hook to the debugger fault handler hook which calls longjmp unconditionally. This first part of kdump is run before we marshall the other CPUs, so there is a very good chance some CPU on the box is going to page fault. And when it does it hits the longjmp code and assumes the context of the oopsing CPU. The machine gets very confused when it has 10 CPUs all with the same stack, all thinking they have the same CPU id. I get even more confused trying to debug it. The patch below adds crash_shutdown_cpu and uses it to specify which cpu is in the protected region. Since it can only be -1 or the oopsing CPU, we don't need to use memory barriers since it is only valid on the local CPU - no other CPU will ever see a value that matches it's local CPU id. Eventually we should switch the order and marshall all CPUs before doing the crash_shutdown_handles[] calls, but that is a bigger fix. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Cc: Kamalesh babulal Signed-off-by: Greg Kroah-Hartman commit 8f52e5db24ab6b73f0a33e5748b9462be650e7c9 Author: Anton Blanchard Date: Mon May 10 18:59:18 2010 +0000 powerpc: Use more accurate limit for first segment memory allocations commit 095c7965f4dc870ed2b65143b1e2610de653416c upstream. Author: Milton Miller On large machines we are running out of room below 256MB. In some cases we only need to ensure the allocation is in the first segment, which may be 256MB or 1TB. Add slb0_limit and use it to specify the upper limit for the irqstack and emergency stacks. On a large ppc64 box, this fixes a panic at boot when the crashkernel= option is specified (previously we would run out of memory below 256MB). Signed-off-by: Milton Miller Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Cc: Kamalesh Babulal Signed-off-by: Greg Kroah-Hartman commit 1ed9c543aa80a4e42b61ddd02b2a66986660165f Author: Hugh Dickins Date: Wed Feb 23 21:39:49 2011 -0800 mm: fix possible cause of a page_mapped BUG commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7 upstream. Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching a hole with madvise(,, MADV_REMOVE). That path is under mutex, and cannot be explained by lack of serialization in unmap_mapping_range(). Reviewing the code, I found one place where vm_truncate_count handling should have been updated, when I switched at the last minute from one way of managing the restart_addr to another: mremap move changes the virtual addresses, so it ought to adjust the restart_addr. But rather than exporting the notion of restart_addr from memory.c, or converting to restart_pgoff throughout, simply reset vm_truncate_count to 0 to force a rescan if mremap move races with preempted truncation. We have no confirmation that this fixes Robert's BUG, but it is a fix that's worth making anyway. Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Cc: Kerin Millar Signed-off-by: Greg Kroah-Hartman commit 8238f12a32d413d5ad69f2e975972ecb31f7ce70 Author: Don Skidmore Date: Tue Jan 18 22:53:47 2011 +0000 ixgbe: fix for 82599 erratum on Header Splitting commit a124339ad28389093ed15eca990d39c51c5736cc upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by: Don Skidmore Tested-by: Stephen Ko Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit d1d2de54ebe491ecf12298b469e95b7544483340 Author: Thomas Hellstrom Date: Thu Sep 30 12:36:45 2010 +0200 drm/ttm: Fix two race conditions + fix busy codepaths commit 1df6a2ebd75067aefbdf07482bf8e3d0584e04ee upstream. This fixes a race pointed out by Dave Airlie where we don't take a buffer object about to be destroyed off the LRU lists properly. It also fixes a rare case where a buffer object could be destroyed in the middle of an accelerated eviction. The patch also adds a utility function that can be used to prematurely release GPU memory space usage of an object waiting to be destroyed. For example during eviction or swapout. The above mentioned commit didn't queue the buffer on the delayed destroy list under some rare circumstances. It also didn't completely honor the remove_all parameter. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=615505 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061 Signed-off-by: Thomas Hellstrom Signed-off-by: Dave Airlie [ Backported to 2.6.33 -maks ] Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit a06c5ec79df5e4fe7d137f8a06c95e065f081cff Author: Anton Blanchard Date: Mon Feb 28 03:27:53 2011 +0000 RxRPC: Fix v1 keys commit f009918a1c1bbf8607b8aab3959876913a30193a upstream. commit 339412841d7 (RxRPC: Allow key payloads to be passed in XDR form) broke klog for me. I notice the v1 key struct had a kif_version field added: -struct rxkad_key { - u16 security_index; /* RxRPC header security index */ - u16 ticket_len; /* length of ticket[] */ - u32 expiry; /* time at which expires */ - u32 kvno; /* key version number */ - u8 session_key[8]; /* DES session key */ - u8 ticket[0]; /* the encrypted ticket */ -}; +struct rxrpc_key_data_v1 { + u32 kif_version; /* 1 */ + u16 security_index; + u16 ticket_length; + u32 expiry; /* time_t */ + u32 kvno; + u8 session_key[8]; + u8 ticket[0]; +}; However the code in rxrpc_instantiate strips it away: data += sizeof(kver); datalen -= sizeof(kver); Removing kif_version fixes my problem. Signed-off-by: Anton Blanchard Signed-off-by: David Howells Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6d521a02d4a12b1fb3aff6694d400905f4a73f7 Author: Dan Carpenter Date: Thu Mar 3 17:56:06 2011 +0100 keyboard: integer underflow bug commit b652277b09d3d030cb074cc6a98ba80b34244c03 upstream. The "ct" variable should be an unsigned int. Both struct kbdiacrs ->kb_cnt and struct kbd_data ->accent_table_size are unsigned ints. Making it signed causes a problem in KBDIACRUC because the user could set the signed bit and cause a buffer overflow. Signed-off-by: Dan Carpenter Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 2c103bfa4db025da9ab9428981e9e8afcc765492 Author: Li Zefan Date: Fri Mar 4 17:36:21 2011 -0800 cpuset: add a missing unlock in cpuset_write_resmask() commit b75f38d659e6fc747eda64cb72f3920e29dd44a4 upstream. Don't forget to release cgroup_mutex if alloc_trial_cpuset() fails. [akpm@linux-foundation.org: avoid multiple return points] Signed-off-by: Li Zefan Cc: Paul Menage Acked-by: David Rientjes Cc: Miao Xie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 76d102e4c2e0509c58dfe51322e825604afdb0d0 Author: Pavel Shilovsky Date: Mon Jan 17 20:15:44 2011 +0300 CIFS: Fix oplock break handling (try #2) commit 12fed00de963433128b5366a21a55808fab2f756 upstream. When we get oplock break notification we should set the appropriate value of OplockLevel field in oplock break acknowledge according to the oplock level held by the client in this time. As we only can have level II oplock or no oplock in the case of oplock break, we should be aware only about clientCanCacheRead field in cifsInodeInfo structure. Also fix bug connected with wrong interpretation of OplockLevel field during oplock break notification processing. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6b85e439753bfb9e1665a9697df51600cb864c38 Author: Kees Cook Date: Mon Oct 11 11:28:16 2010 -0700 usb: iowarrior: don't trust report_size for buffer size commit 3ed780117dbe5acb64280d218f0347f238dafed0 upstream. If the iowarrior devices in this case statement support more than 8 bytes per report, it is possible to write past the end of a kernel heap allocation. This will probably never be possible, but change the allocation to be more defensive anyway. Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman Acked-by: Brandon Philips commit ee269be9e14809eb981021241931c49ad884a25b Author: Stanislaw Gruszka Date: Tue Feb 22 02:00:11 2011 +0000 r8169: disable ASPM commit ba04c7c93bbcb48ce880cf75b6e9dffcd79d4c7b upstream. For some time is known that ASPM is causing troubles on r8169, i.e. make device randomly stop working without any errors in dmesg. Currently Tomi Leppikangas reports that system with r8169 device hangs with MCE errors when ASPM is enabled: https://bugzilla.redhat.com/show_bug.cgi?id=642861#c4 Lets disable ASPM for r8169 devices at all, to avoid problems with r8169 PCIe devices at least for some users. Reported-by: Tomi Leppikangas Signed-off-by: Stanislaw Gruszka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 20ec7917f9e94256373a2f12e99770a7d2c1a25d Author: Bruce Allan Date: Wed Feb 2 09:30:36 2011 +0000 e1000e: disable broken PHY wakeup for ICH10 LOMs, use MAC wakeup instead commit 4def99bbfd46e05c5e03b5b282cb4ee30e27ff19 upstream. When support for 82577/82578 was added[1] in 2.6.31, PHY wakeup was in- advertently enabled (even though it does not function properly) on ICH10 LOMs. This patch makes it so that the ICH10 LOMs use MAC wakeup instead as was done with the initial support for those devices (i.e. 82567LM-3, 82567LF-3 and 82567V-4). [1] commit a4f58f5455ba0efda36fb33c37074922d1527a10 Reported-by: Aurelien Jarno Signed-off-by: Bruce Allan Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 519c0f5f84fe7ce673305bf12c55a01361b0ee50 Author: Gerrit Renker Date: Tue Mar 1 23:02:07 2011 -0800 dccp: fix oops on Reset after close commit 720dc34bbbe9493c7bd48b2243058b4e447a929d upstream. This fixes a bug in the order of dccp_rcv_state_process() that still permitted reception even after closing the socket. A Reset after close thus causes a NULL pointer dereference by not preventing operations on an already torn-down socket. dccp_v4_do_rcv() | | state other than OPEN v dccp_rcv_state_process() | | DCCP_PKT_RESET v dccp_rcv_reset() | v dccp_time_wait() WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128() Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_n) [] (warn_slowpath_null+0x1c/0x24) from [] (__inet_twsk_hashd) [] (__inet_twsk_hashdance+0x48/0x128) from [] (dccp_time_wai) [] (dccp_time_wait+0x40/0xc8) from [] (dccp_rcv_state_proces) [] (dccp_rcv_state_process+0x120/0x538) from [] (dccp_v4_do_) [] (dccp_v4_do_rcv+0x11c/0x14c) from [] (release_sock+0xac/0) [] (release_sock+0xac/0x110) from [] (dccp_close+0x28c/0x380) [] (dccp_close+0x28c/0x380) from [] (inet_release+0x64/0x70) The fix is by testing the socket state first. Receiving a packet in Closed state now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1. Reported-and-tested-by: Johan Hovold Signed-off-by: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2b0d4ae04fcc5e16d9add9d5aecf870389a88c84 Author: Christian Lamparter Date: Sat Feb 26 12:58:06 2011 +0100 p54usb: add Senao NUB-350 usbid commit 2b799a6b25bb9f9fbc478782cd9503e8066ab618 upstream. Reported-by: Mark Davis Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 44778504c7cfe79b7f93de49d6f6a8798a964982 Author: David S. Miller Date: Wed Feb 9 21:48:36 2011 -0800 x25: Do not reference freed memory. commit 96642d42f076101ba98866363d908cab706d156c upstream. In x25_link_free(), we destroy 'nb' before dereferencing 'nb->dev'. Don't do this, because 'nb' might be freed by then. Reported-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6104ea834d963524862c5565983f65089957b91b Author: Michael S. Tsirkin Date: Sun Nov 29 17:52:00 2009 +0200 virtio: set pci bus master enable bit commit bc505f373979692d51a86d40925f77a8b09d17b9 upstream. As all virtio devices perform DMA, we must enable bus mastering for them to be spec compliant. This patch fixes hotplug of virtio devices with Linux guests and qemu 0.11-0.12. Tested-by: Alexander Graf Signed-off-by: Michael S. Tsirkin Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 14bcdf0bc282f0ea21574d4fec4df15900ceb4c4 Author: Josh Hunt Date: Thu Feb 24 11:48:22 2011 +0100 ext2: Fix link count corruption under heavy link+rename load commit e8a80c6f769dd4622d8b211b398452158ee60c0b upstream. vfs_rename_other() does not lock renamed inode with i_mutex. Thus changing i_nlink in a non-atomic manner (which happens in ext2_rename()) can corrupt it as reported and analyzed by Josh. In fact, there is no good reason to mess with i_nlink of the moved file. We did it presumably to simulate linking into the new directory and unlinking from an old one. But the practical effect of this is disputable because fsck can possibly treat file as being properly linked into both directories without writing any error which is confusing. So we just stop increment-decrement games with i_nlink which also fixes the corruption. CC: Al Viro Signed-off-by: Josh Hunt Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 002b43bfac57403ff58fe9cda16d71bdfac99dcc Author: Thomas Gleixner Date: Fri Feb 25 22:34:23 2011 +0100 clockevents: Prevent oneshot mode when broadcast device is periodic commit 3a142a0672b48a853f00af61f184c7341ac9c99d upstream. When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only can switch into oneshot mode, when the backup broadcast device supports oneshot mode as well. Otherwise we would try to switch the broadcast device into an unsupported mode unconditionally. This went unnoticed so far as the current available broadcast devices support oneshot mode. Seth unearthed this problem while debugging and working around an hpet related BIOS wreckage. Add the necessary check to tick_is_oneshot_available(). Reported-and-tested-by: Seth Forshee Signed-off-by: Thomas Gleixner LKML-Reference: Signed-off-by: Greg Kroah-Hartman commit 5c46eb076e0a1b2c1769287cd6942e4594ade1b1 Author: Miklos Szeredi Date: Fri Feb 25 14:44:58 2011 +0100 fuse: fix hang of single threaded fuseblk filesystem commit 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 upstream. Single threaded NTFS-3G could get stuck if a delayed RELEASE reply triggered a DESTROY request via path_put(). Fix this by a) making RELEASE requests synchronous, whenever possible, on fuseblk filesystems b) if not possible (triggered by an asynchronous read/write) then do the path_put() in a separate thread with schedule_work(). Reported-by: Oliver Neukum Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 4389b6188647b4dbc84d54bbc467ddf966dcb837 Author: Don Zickus Date: Mon Feb 7 23:25:00 2011 -0500 x86: Use u32 instead of long to set reset vector back to 0 commit 299c56966a72b9109d47c71a6db52097098703dd upstream. A customer of ours, complained that when setting the reset vector back to 0, it trashed other data and hung their box. They noticed when only 4 bytes were set to 0 instead of 8, everything worked correctly. Mathew pointed out: | | We're supposed to be resetting trampoline_phys_low and | trampoline_phys_high here, which are two 16-bit values. | Writing 64 bits is definitely going to overwrite space | that we're not supposed to be touching. | So limit the area modified to u32. Signed-off-by: Don Zickus Acked-by: Matthew Garrett LKML-Reference: <1297139100-424-1-git-send-email-dzickus@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1e3b8b67525a567cbfd3d517395a5753491837ab Author: Jochen Friedrich Date: Wed Jan 26 11:30:01 2011 +0100 mfd: Fix NULL pointer due to non-initialized ucb1x00-ts absinfo commit 9063f1f15eec35e5fd608879cef8be5728f2d12a upstream. Call input_set_abs_params instead of manually setting absbit only. This fixes this oops: Unable to handle kernel NULL pointer dereference at virtual address 00000024 Internal error: Oops: 41b67017 [#1] CPU: 0 Not tainted (2.6.37 #4) pc : [] lr : [<00000000>] psr: 20000093 sp : c19e5f30 ip : c19e5e6c fp : c19e5f58 r10: 00000000 r9 : c19e4000 r8 : 00000003 r7 : 000001e4 r6 : 00000001 r5 : c1854400 r4 : 00000003 r3 : 00000018 r2 : 00000018 r1 : 00000018 r0 : c185447c Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: c1b6717f Table: c1b6717f DAC: 00000017 Stack: (0xc19e5f30 to 0xc19e6000) 5f20: 00000003 00000003 c1854400 00000013 5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4 5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4 5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54 5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8 5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54 5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400 Backtrace: Function entered at [] from [] Function entered at [] from [] r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400 Function entered at [] from [] Function entered at [] from [] r6:c003b464 r5:c00500f0 r4:c1a55d54 Code: e59520fc e1a03286 e0433186 e0822003 (e592000c) >>PC; c016d1fc <===== Trace; c016cf50 Trace; c016d5e8 Trace; c016d578 Trace; c01559a4 Trace; c0155750 Trace; c0050174 Trace; c00500f0 Trace; c003b464 Signed-off-by: Jochen Friedrich Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 937d443c0fdb7f09cb309409327f8282892a29c4 Author: Dave Airlie Date: Thu Feb 24 08:35:06 2011 +1000 drm: fix unsigned vs signed comparison issue in modeset ctl ioctl. commit 1922756124ddd53846877416d92ba4a802bc658f upstream. This fixes CVE-2011-1013. Reported-by: Matthiew Herrb (OpenBSD X.org team) Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 1f4833bec35ebc1d53b5cb6eaa9b529d19691999 Author: Tristan Ye Date: Fri Jan 21 18:20:18 2011 +0800 Ocfs2/refcounttree: Fix a bug for refcounttree to writeback clusters in a right number. commit acf3bb007e5636ef4c17505affb0974175108553 upstream. Current refcounttree codes actually didn't writeback the new pages out in write-back mode, due to a bug of always passing a ZERO number of clusters to 'ocfs2_cow_sync_writeback', the patch tries to pass a proper one in. Signed-off-by: Tristan Ye Signed-off-by: Joel Becker Signed-off-by: Greg Kroah-Hartman commit 52d38a02368bb821bb1df4a55f52f65d9a9f0b85 Author: Paul Zimmerman Date: Sat Feb 12 14:07:57 2011 -0800 xhci: Fix an error in count_sg_trbs_needed() commit bcd2fde05341cef0052e49566ec88b406a521cf3 upstream. The expression while (running_total < sg_dma_len(sg)) does not take into account that the remaining data length can be less than sg_dma_len(sg). In that case, running_total can end up being greater than the total data length, so an extra TRB is counted. Changing the expression to while (running_total < sg_dma_len(sg) && running_total < temp) fixes that. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit f62d7814294e094f0d57805ff7e9d6406bdae058 Author: Paul Zimmerman Date: Sat Feb 12 14:07:20 2011 -0800 xhci: Fix errors in the running total calculations in the TRB math commit 5807795bd4dececdf553719cc02869e633395787 upstream. Calculations like running_total = TRB_MAX_BUFF_SIZE - (sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1)); if (running_total != 0) num_trbs++; are incorrect, because running_total can never be zero, so the if() expression will never be true. I think the intention was that running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1 to TRB_MAX_BUFF_SIZE. So adding a running_total &= TRB_MAX_BUFF_SIZE - 1; fixes the problem. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 1d143e0aeacc95efea0c2a9c058b69d0a94b628a Author: Paul Zimmerman Date: Sat Feb 12 14:06:44 2011 -0800 xhci: Clarify some expressions in the TRB math commit a2490187011cc2263117626615a581927d19f1d3 upstream. This makes it easier to spot some problems, which will be fixed by the next patch in the series. Also change dev_dbg to dev_err in check_trb_math(), so any math errors will be visible even when running with debug disabled. Note: This patch changes the expressions containing "((1 << TRB_MAX_BUFF_SHIFT) - 1)" to use the equivalent "(TRB_MAX_BUFF_SIZE - 1)". No change in behavior is intended for those expressions. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 35dda5a304da9f4bc80ef35d49d015bf96ec00fb Author: Paul Zimmerman Date: Sat Feb 12 14:06:06 2011 -0800 xhci: Avoid BUG() in interrupt context commit 68e41c5d032668e2905404afbef75bc58be179d6 upstream. Change the BUGs in xhci_find_new_dequeue_state() to WARN_ONs, to avoid bringing down the box if one of them is hit This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 1c3c76927b92b3c23f58a79b68efc3d15943ba30 Author: Andreas Herrmann Date: Thu Feb 24 15:53:46 2011 +0100 x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 upstream. On some SB800 systems polarity for IOAPIC pin2 is wrongly specified as low active by BIOS. This caused system hangs after resume from S3 when HPET was used in one-shot mode on such systems because a timer interrupt was missed (HPET signal is high active). For more details see: http://marc.info/?l=linux-kernel&m=129623757413868 Tested-by: Manoj Iyer Tested-by: Andre Przywara Signed-off-by: Andreas Herrmann Cc: Borislav Petkov LKML-Reference: <20110224145346.GD3658@alberich.amd.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 54919a0fc2d4d7a9e42300f27fa9f3be0e0d6a75 Author: NeilBrown Date: Wed Feb 16 13:58:51 2011 +1100 md: correctly handle probe of an 'mdp' device. commit 8f5f02c460b7ca74ce55ce126ce0c1e58a3f923d upstream. 'mdp' devices are md devices with preallocated device numbers for partitions. As such it is possible to mknod and open a partition before opening the whole device. this causes md_probe() to be called with a device number of a partition, which in-turn calls mddev_find with such a number. However mddev_find expects the number of a 'whole device' and does the wrong thing with partition numbers. So add code to mddev_find to remove the 'partition' part of a device number and just work with the 'whole device'. This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=28652 Reported-by: hkmaly@bigfoot.com Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ea08d3be6b0b8639dfa60d6803909835c9a02d49 Author: Timo Warns Date: Fri Feb 25 14:44:21 2011 -0800 ldm: corrupted partition table can cause kernel oops commit 294f6cf48666825d23c9372ef37631232746e40d upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch changes ldm_parse_vmdb() to Validate the value of vblk_size. Signed-off-by: Timo Warns Cc: Eugene Teo Acked-by: Richard Russon Cc: Harvey Harrison Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 28a92748aa4bc57d35e7b079498b0ac2e7610a37 Author: Davide Libenzi Date: Fri Feb 25 14:44:12 2011 -0800 epoll: prevent creating circular epoll structures commit 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e upstream. In several places, an epoll fd can call another file's ->f_op->poll() method with ep->mtx held. This is in general unsafe, because that other file could itself be an epoll fd that contains the original epoll fd. The code defends against this possibility in its own ->poll() method using ep_call_nested, but there are several other unsafe calls to ->poll elsewhere that can be made to deadlock. For example, the following simple program causes the call in ep_insert recursively call the original fd's ->poll, leading to deadlock: #include #include int main(void) { int e1, e2, p[2]; struct epoll_event evt = { .events = EPOLLIN }; e1 = epoll_create(1); e2 = epoll_create(2); pipe(p); epoll_ctl(e2, EPOLL_CTL_ADD, e1, &evt); epoll_ctl(e1, EPOLL_CTL_ADD, p[0], &evt); write(p[1], p, sizeof p); epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt); return 0; } On insertion, check whether the inserted file is itself a struct epoll, and if so, do a recursive walk to detect whether inserting this file would create a loop of epoll structures, which could lead to deadlock. [nelhage@ksplice.com: Use epmutex to serialize concurrent inserts] Signed-off-by: Davide Libenzi Signed-off-by: Nelson Elhage Reported-by: Nelson Elhage Tested-by: Nelson Elhage Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fd54872c463767bed1798f6f1f2c61258aeeb91e Author: Max Vozeler Date: Wed Jan 12 15:02:05 2011 +0200 staging: usbip: vhci: use urb->dev->portnum to find port commit 01446ef5af4e8802369bf4d257806e24345a9371 upstream. The access to pending_port was racy when two devices were being attached at the same time. Signed-off-by: Max Vozeler Tested-by: Mark Wehby Signed-off-by: Greg Kroah-Hartman commit 16cf40a5c2116225d68251cc02c7092d80d067bf Author: Max Vozeler Date: Wed Jan 12 15:02:02 2011 +0200 staging: usbip: vhci: refuse to enqueue for dead connections commit 6d212153a838354078cc7d96f9bb23b7d1fd3d1b upstream. There can be requests to enqueue URBs while we are shutting down a connection. Signed-off-by: Max Vozeler Tested-by: Mark Wehby Signed-off-by: Greg Kroah-Hartman commit 68e1d43b525445cd59942646282f134d19da4c6b Author: Max Vozeler Date: Wed Jan 12 15:02:01 2011 +0200 staging: usbip: vhci: give back URBs from in-flight unlink requests commit b92a5e23737172c52656a090977408a80d7f06d1 upstream. If we never received a RET_UNLINK because the TCP connection broke the pending URBs still need to be unlinked and given back. Previously processes would be stuck trying to kill the URB even after the device was detached. Signed-off-by: Max Vozeler Tested-by: Mark Wehby Signed-off-by: Greg Kroah-Hartman commit 075b4e6a982d38121250c090f7b9294314ac1b19 Author: Max Vozeler Date: Wed Jan 12 15:02:00 2011 +0200 staging: usbip: vhci: update reference count for usb_device commit 7606ee8aa33287dd3e6eb44c78541b87a413a325 upstream. This fixes an oops observed when reading status during removal of a device: [ 1706.648285] general protection fault: 0000 [#1] SMP [ 1706.648294] last sysfs file: /sys/devices/platform/vhci_hcd/status [ 1706.648297] CPU 1 [ 1706.648300] Modules linked in: binfmt_misc microcode fuse loop vhci_hcd(N) usbip(N) usbcore usbip_common_mod(N) rtc_core rtc_lib joydev dm_mirror dm_region_hash dm_log linear dm_snapshot xennet dm_mod ext3 mbcache jbd processor thermal_sys hwmon xenblk cdrom [ 1706.648324] Supported: Yes [ 1706.648327] Pid: 10422, comm: usbip Tainted: G N 2.6.32.12-0.7-xen #1 [ 1706.648330] RIP: e030:[] [] strnlen+0x5/0x40 [ 1706.648340] RSP: e02b:ffff8800a994dd30 EFLAGS: 00010286 [ 1706.648343] RAX: ffffffff80481ec1 RBX: 0000000000000000 RCX: 0000000000000002 [ 1706.648347] RDX: 00200d1d4f1c001c RSI: ffffffffffffffff RDI: 00200d1d4f1c001c [ 1706.648350] RBP: ffff880129a1c0aa R08: ffffffffa01901c4 R09: 0000000000000006 [ 1706.648353] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800a9a1c0ab [ 1706.648357] R13: 00200d1d4f1c001c R14: 00000000ffffffff R15: ffff880129a1c0aa [ 1706.648363] FS: 00007f2f2e9ca700(0000) GS:ffff880001018000(0000) knlGS:0000000000000000 [ 1706.648367] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1706.648370] CR2: 000000000071b048 CR3: 00000000b4b68000 CR4: 0000000000002660 [ 1706.648374] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1706.648378] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1706.648381] Process usbip (pid: 10422, threadinfo ffff8800a994c000, task ffff88007b170200) [ 1706.648385] Stack: [ 1706.648387] ffffffff801b28c9 0000000000000002 ffffffffa01901c4 ffff8800a9a1c0ab [ 1706.648391] <0> ffffffffa01901c6 ffff8800a994de08 ffffffff801b339b 0000000000000004 [ 1706.648397] <0> 0000000affffffff ffffffffffffffff 00000000000067c0 0000000000000000 [ 1706.648404] Call Trace: [ 1706.648413] [] string+0x39/0xe0 [ 1706.648419] [] vsnprintf+0x1eb/0x620 [ 1706.648423] [] sprintf+0x43/0x50 [ 1706.648429] [] show_status+0x1b9/0x220 [vhci_hcd] [ 1706.648438] [] dev_attr_show+0x27/0x60 [ 1706.648445] [] sysfs_read_file+0x101/0x1d0 [ 1706.648451] [] vfs_read+0xc7/0x130 [ 1706.648457] [] sys_read+0x53/0xa0 [ 1706.648462] [] system_call_fastpath+0x16/0x1b [ 1706.648468] [<00007f2f2de40f30>] 0x7f2f2de40f30 [ 1706.648470] Code: 66 0f 1f 44 00 00 48 83 c2 01 80 3a 00 75 f7 48 89 d0 48 29 f8 f3 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 85 f6 74 29 <80> 3f 00 74 24 48 8d 56 ff 48 89 f8 eb 0e 0f 1f 44 00 00 48 83 [ 1706.648507] RIP [] strnlen+0x5/0x40 [ 1706.648511] RSP [ 1706.649575] ---[ end trace b4eb72bf2e149593 ]--- Signed-off-by: Max Vozeler Tested-by: Mark Wehby Signed-off-by: Greg Kroah-Hartman commit bd9537501670b2dae4df632b8e126e60d11e548d Author: Eric Dumazet Date: Fri Feb 18 22:35:56 2011 +0000 tcp: fix inet_twsk_deschedule() commit 91035f0b7d89291af728b6f3e370c3be58fcbe1b upstream. Eric W. Biederman reported a lockdep splat in inet_twsk_deschedule() This is caused by inet_twsk_purge(), run from process context, and commit 575f4cd5a5b6394577 (net: Use rcu lookups in inet_twsk_purge.) removed the BH disabling that was necessary. Add the BH disabling but fine grained, right before calling inet_twsk_deschedule(), instead of whole function. With help from Linus Torvalds and Eric W. Biederman Reported-by: Eric W. Biederman Signed-off-by: Eric Dumazet CC: Daniel Lezcano CC: Pavel Emelyanov CC: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 38821aad074e2a35333d0765e8ae2605f20a7608 Author: Alex Deucher Date: Mon Feb 21 01:11:59 2011 -0500 Revert "drm/radeon/kms: switch back to min->max pll post divider iteration" commit bd6a60afeb4c9ada3ff27f1d13db1a2b5c11d8c0 upstream. This reverts commit a6f9761743bf35b052180f4a8bdae4d2cc0465f6. Remove this commit as it is no longer necessary. The relevant bugs were fixed properly in: drm/radeon/kms: hopefully fix pll issues for real (v3) 5b40ddf888398ce4cccbf3b9d0a18d90149ed7ff drm/radeon/kms: add missing frac fb div flag for dce4+ 9f4283f49f0a96a64c5a45fe56f0f8c942885eef This commit also broke certain ~5 Mhz modes on old arcade monitors, so reverting this commit fixes: https://bugzilla.kernel.org/show_bug.cgi?id=29502 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 4f621cb1fec1309fce287a85ba89fed273aef429 Author: Christian Lamparter Date: Fri Feb 11 01:48:42 2011 +0100 p54pci: update receive dma buffers before and after processing commit 0bf719dfdecc5552155cbec78e49fa06e531e35c upstream. Documentation/DMA-API-HOWTO.txt states: "DMA transfers need to be synced properly in order for the cpu and device to see the most uptodate and correct copy of the DMA buffer." Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8ed9cf293b7b5b6530afd1b80ec86b5f649ba51f Author: Jon Thomas Date: Wed Feb 16 11:02:34 2011 -0500 sierra: add new ID for Airprime/Sierra USB IP modem commit e1dc5157c574e7249dc1cd072fde2e48b3011533 upstream. I picked up a new Sierra usb 308 (At&t Shockwave) on 2/2011 and the vendor code is 0x0f3d Looking up vendor and product id's I see: 0f3d Airprime, Incorporated 0112 CDMA 1xEVDO PC Card, PC 5220 Sierra and Airprime are somehow related and I'm guessing the At&t usb 308 might be have some common hardware with the AirPrime SL809x. Signed-off-by: Jon Thomas Signed-off-by: Greg Kroah-Hartman commit ea28b8480420d2ec513646bc54e5193eaaa1eb0f Author: Maciej Szmigiero Date: Sat Feb 5 21:52:00 2011 +0100 USB: Add quirk for Samsung Android phone modem commit 72a012ce0a02c6c616676a24b40ff81d1aaeafda upstream. My Galaxy Spica needs this quirk when in modem mode, otherwise it causes endless USB bus resets and is unusable in this mode. Unfortunately Samsung decided to reuse ID of its old CDMA phone SGH-I500 for the modem part. That's why in addition to this patch the visor driver must be prevented from binding to SPH-I500 ID, so ACM driver can do that. Signed-off-by: Maciej Szmigiero Signed-off-by: Greg Kroah-Hartman commit deb17af455cd0996b761acfac98655b0be7622b3 Author: Maciej Szmigiero Date: Mon Feb 7 12:42:36 2011 +0100 USB: Add Samsung SGH-I500/Android modem ID switch to visor driver commit acb52cb1613e1d3c8a8c650717cc51965c60d7d4 upstream. [USB]Add Samsung SGH-I500/Android modem ID switch to visor driver Samsung decided to reuse USB ID of its old CDMA phone SGH-I500 for the modem part of some of their Android phones. At least Galaxy Spica is affected. This modem needs ACM driver and does not work with visor driver which binds the conflicting ID for SGH-I500. Because SGH-I500 is pretty an old hardware its best to add switch to visor driver in cause somebody still wants to use that phone with Linux. Note that this is needed only when using the Android phone as modem, not in USB storage or ADB mode. Signed-off-by: Maciej Szmigiero Signed-off-by: Greg Kroah-Hartman commit c2173f627fc65c9f23059c4e03a92935deaeebd5 Author: Alan Stern Date: Thu Feb 17 10:26:38 2011 -0500 USB: add quirks entry for Keytouch QWERTY Panel commit 3c18e30f87ac5466bddbb05cf955605efd7db025 upstream. This patch (as1448) adds a quirks entry for the Keytouch QWERTY Panel firmware, used in the IEC 60945 keyboard. This device crashes during enumeration when the computer asks for its configuration string descriptor. Signed-off-by: Alan Stern Tested-by: kholis Signed-off-by: Greg Kroah-Hartman commit 2886f7d272ab59f67546b05b1e3fc1da529479b9 Author: Johan Hovold Date: Fri Feb 11 16:57:08 2011 +0100 usb: musb: omap2430: fix kernel panic on reboot commit b193b412e62b134adf69af286c7e7f8e99259350 upstream. Cancel idle timer in musb_platform_exit. The idle timer could trigger after clock had been disabled leading to kernel panic when MUSB_DEVCTL is accessed in musb_do_idle on 2.6.37. The fault below is no longer triggered on 2.6.38-rc4 (clock is disabled later, and only if compiled as a module, and the offending memory access has moved) but the timer should be cancelled nonetheless. Rebooting... musb_hdrc musb_hdrc: remove, state 4 usb usb1: USB disconnect, address 1 musb_hdrc musb_hdrc: USB bus 1 deregistered Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060 Internal error: : 1028 [#1] PREEMPT last sysfs file: /sys/kernel/uevent_seqnum Modules linked in: CPU: 0 Not tainted (2.6.37+ #6) PC is at musb_do_idle+0x24/0x138 LR is at musb_do_idle+0x18/0x138 pc : [] lr : [] psr: 80000193 sp : cf2bdd80 ip : cf2bdd80 fp : c048a20c r10: c048a60c r9 : c048a40c r8 : cf85e110 r7 : cf2bc000 r6 : 40000113 r5 : c0489800 r4 : cf85e110 r3 : 00000004 r2 : 00000006 r1 : fa0ab000 r0 : cf8a7000 Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8faac019 DAC: 00000015 Process reboot (pid: 769, stack limit = 0xcf2bc2f0) Stack: (0xcf2bdd80 to 0xcf2be000) dd80: 00000103 c0489800 c02377b4 c005fa34 00000555 c0071a8c c04a3858 cf2bdda8 dda0: 00000555 c048a00c cf2bdda8 cf2bdda8 1838beb0 00000103 00000004 cf2bc000 ddc0: 00000001 00000001 c04896c8 0000000a 00000000 c005ac14 00000001 c003f32c dde0: 00000000 00000025 00000000 cf2bc000 00000002 00000001 cf2bc000 00000000 de00: 00000001 c005ad08 cf2bc000 c002e07c c03ec039 ffffffff fa200000 c0033608 de20: 00000001 00000000 cf852c14 cf81f200 c045b714 c045b708 cf2bc000 c04a37e8 de40: c0033c04 cf2bc000 00000000 00000001 cf2bde68 cf2bde68 c01c3abc c004f7d8 de60: 60000013 ffffffff c0033c04 00000000 01234567 fee1dead 00000000 c006627c de80: 00000001 c00662c8 28121969 c00663ec cfa38c40 cf9f6a00 cf2bded0 cf9f6a0c dea0: 00000000 cf92f000 00008914 c02cd284 c04a55c8 c028b398 c00715c0 becf24a8 dec0: 30687465 00000000 00000000 00000000 00000002 1301a8c0 00000000 00000000 dee0: 00000002 1301a8c0 00000000 00000000 c0450494 cf527920 00011f10 cf2bdf08 df00: 00011f10 cf2bdf10 00011f10 cf2bdf18 c00f0b44 c004f7e8 cf2bdf18 cf2bdf18 df20: 00011f10 cf2bdf30 00011f10 cf2bdf38 cf401300 cf486100 00000008 c00d2b28 df40: 00011f10 cf401300 00200200 c00d3388 00011f10 cfb63a88 cfb63a80 c00c2f08 df60: 00000000 00000000 cfb63a80 00000000 cf0a3480 00000006 c0033c04 cfb63a80 df80: 00000000 c00c0104 00000003 cf0a3480 cfb63a80 00000000 00000001 00000004 dfa0: 00000058 c0033a80 00000000 00000001 fee1dead 28121969 01234567 00000000 dfc0: 00000000 00000001 00000004 00000058 00000001 00000001 00000000 00000001 dfe0: 4024d200 becf2cb0 00009210 4024d218 60000010 fee1dead 00000000 00000000 [] (musb_do_idle+0x24/0x138) from [] (run_timer_softirq+0x1a8/0x26) [] (run_timer_softirq+0x1a8/0x26c) from [] (__do_softirq+0x88/0x13) [] (__do_softirq+0x88/0x138) from [] (irq_exit+0x44/0x98) [] (irq_exit+0x44/0x98) from [] (asm_do_IRQ+0x7c/0xa0) [] (asm_do_IRQ+0x7c/0xa0) from [] (__irq_svc+0x48/0xa8) Exception stack(0xcf2bde20 to 0xcf2bde68) de20: 00000001 00000000 cf852c14 cf81f200 c045b714 c045b708 cf2bc000 c04a37e8 de40: c0033c04 cf2bc000 00000000 00000001 cf2bde68 cf2bde68 c01c3abc c004f7d8 de60: 60000013 ffffffff [] (__irq_svc+0x48/0xa8) from [] (sub_preempt_count+0x0/0xb8) Code: ebf86030 e5940098 e594108c e5902010 (e5d13060) ---[ end trace 3689c0d808f9bf7c ]--- Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Johan Hovold Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 64710ba6e96f1c6cca73207a2c9306d53a5f90d1 Author: Vasiliy Kulikov Date: Fri Feb 4 15:24:03 2011 +0300 platform: x86: tc1100-wmi: world-writable sysfs wireless and jogdial files commit 8a6a142c1286797978e4db266d22875a5f424897 upstream. Don't allow everybody to change WMI settings. Signed-off-by: Vasiliy Kulikov Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 2b0d44ee2fd6057d15f9415e09a2ddd5f3289517 Author: Vasiliy Kulikov Date: Fri Feb 4 15:23:59 2011 +0300 platform: x86: asus_acpi: world-writable procfs files commit 8040835760adf0ef66876c063d47f79f015fb55d upstream. Don't allow everybody to change ACPI settings. The comment says that it is done deliberatelly, however, the comment before disp_proc_write() says that at least one of these setting is experimental. Signed-off-by: Vasiliy Kulikov Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit c752d4bb18aff38e932110f271babc58d3cfe8eb Author: Vasiliy Kulikov Date: Fri Feb 4 15:23:56 2011 +0300 platform: x86: acer-wmi: world-writable sysfs threeg file commit b80b168f918bba4b847e884492415546b340e19d upstream. Don't allow everybody to write to hardware registers. Signed-off-by: Vasiliy Kulikov Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 493ceb7495f540df969e8a6dae084485c7148013 Author: Thomas Gleixner Date: Fri Feb 18 23:27:23 2011 +0100 genirq: Disable the SHIRQ_DEBUG call in request_threaded_irq for now commit 6d83f94db95cfe65d2a6359cccdf61cf087c2598 upstream. With CONFIG_SHIRQ_DEBUG=y we call a newly installed interrupt handler in request_threaded_irq(). The original implementation (commit a304e1b8) called the handler _BEFORE_ it was installed, but that caused problems with handlers calling disable_irq_nosync(). See commit 377bf1e4. It's braindead in the first place to call disable_irq_nosync in shared handlers, but .... Moving this call after we installed the handler looks innocent, but it is very subtle broken on SMP. Interrupt handlers rely on the fact, that the irq core prevents reentrancy. Now this debug call violates that promise because we run the handler w/o the IRQ_INPROGRESS protection - which we cannot apply here because that would result in a possibly forever masked interrupt line. A concurrent real hardware interrupt on a different CPU results in handler reentrancy and can lead to complete wreckage, which was unfortunately observed in reality and took a fricking long time to debug. Leave the code here for now. We want this debug feature, but that's not easy to fix. We really should get rid of those disable_irq_nosync() abusers and remove that function completely. Signed-off-by: Thomas Gleixner Cc: Anton Vorontsov Cc: David Woodhouse Cc: Arjan van de Ven Signed-off-by: Greg Kroah-Hartman commit 3cb905a9fcaf1f33feb3593e2b00df3b03405f4e Author: Tyler Hicks Date: Tue Jan 11 12:43:42 2011 -0600 eCryptfs: Copy up lower inode attrs in getattr commit 55f9cf6bbaa682958a7dd2755f883b768270c3ce upstream. The lower filesystem may do some type of inode revalidation during a getattr call. eCryptfs should take advantage of that by copying the lower inode attributes to the eCryptfs inode after a call to vfs_getattr() on the lower inode. I originally wrote this fix while working on eCryptfs on nfsv3 support, but discovered it also fixed an eCryptfs on ext4 nanosecond timestamp bug that was reported. https://bugs.launchpad.net/bugs/613873 Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit 168f7a99fcd92f46e643e165f752150e537e1588 Author: Matthew Garrett Date: Wed Feb 9 16:39:40 2011 -0500 acer-wmi: Fix capitalisation of GUID commit bbb706079abe955a9e3f208f541de97d99449236 upstream. 6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3 needs to be 6AF4F258-B401-42FD-BE91-3D4AC2D7C0D3 to match the hardware alias. Signed-off-by: Matthew Garrett Acked-by: Carlos Corbacho Signed-off-by: Greg Kroah-Hartman commit e10f8b1c1104d1304c16c238235b1bc6e37f563c Author: Russell King Date: Sun Feb 20 12:22:52 2011 +0000 ARM: Ensure predictable endian state on signal handler entry commit 53399053eb505cf541b2405bd9d9bca5ecfb96fb upstream. Ensure a predictable endian state when entering signal handlers. This avoids programs which use SETEND to momentarily switch their endian state from having their signal handlers entered with an unpredictable endian state. Acked-by: Dave Martin Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 717587acd84b74c24a16cc11f61777c259ea5c54 Author: Geert Uytterhoeven Date: Sun Jan 16 10:09:13 2011 -0300 radio-aimslab.c needs #include commit 2400982a2e8a8e4e95f0a0e1517bbe63cc88038f upstream. Commit e3c92215198cb6aa00ad38db2780faa6b72e0a3f ("[media] radio-aimslab.c: Fix gcc 4.5+ bug") removed the include, but introduced new callers of msleep(): | drivers/media/radio/radio-aimslab.c: In function ‘rt_decvol’: | drivers/media/radio/radio-aimslab.c:76: error: implicit declaration of function ‘msleep’ Signed-off-by: Geert Uytterhoeven Signed-off-by: Mauro Carvalho Chehab Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit 20e513d2753cc8172f478b8d0eec4375f3a090e7 Author: Takashi Iwai Date: Mon Feb 14 22:45:59 2011 +0100 ALSA: caiaq - Fix possible string-buffer overflow commit eaae55dac6b64c0616046436b294e69fc5311581 upstream. Use strlcpy() to assure not to overflow the string array sizes by too long USB device name string. Reported-by: Rafa Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b81e7b0ea0bfd2d5ff65f8a4702ea9c751f1d7f1 Author: David Henningsson Date: Mon Feb 14 20:27:44 2011 +0100 ALSA: HDA: Add position_fix quirk for an Asus device commit b540afc2b3d6e4cd1d1f137ef6d9e9c78d67fecd upstream. The bug reporter claims that position_fix=1 is needed for his microphone to work. The controller PCI vendor-id is [1002:4383] (rev 40). Reported-by: Kjell L. BugLink: http://bugs.launchpad.net/bugs/718402 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6512cf6e927885eab153868b8daba1ecb53f3267 Author: Eric Dumazet Date: Thu Feb 17 22:59:19 2011 +0000 net: deinit automatic LIST_HEAD commit ceaaec98ad99859ac90ac6863ad0a6cd075d8e0e upstream. commit 9b5e383c11b08784 (net: Introduce unregister_netdevice_many()) left an active LIST_HEAD() in rollback_registered(), with possible memory corruption. Even if device is freed without touching its unreg_list (and therefore touching the previous memory location holding LISTE_HEAD(single), better close the bug for good, since its really subtle. (Same fix for default_device_exit_batch() for completeness) Reported-by: Michal Hocko Tested-by: Michal Hocko Reported-by: Eric W. Biderman Tested-by: Eric W. Biderman Signed-off-by: Linus Torvalds Signed-off-by: Eric Dumazet CC: Ingo Molnar CC: Octavian Purdila Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9cab3cdd60c929dfe4c5ce641a2530fe8b27a89d Author: Timo Warns Date: Thu Feb 17 22:27:40 2011 +0100 fs/partitions: Validate map_count in Mac partition tables commit fa7ea87a057958a8b7926c1a60a3ca6d696328ed upstream. Validate number of blocks in map and remove redundant variable. Signed-off-by: Timo Warns Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 92a79fb1843f5af48a7d80efde9852450e2ecc5f Author: Stanislaw Gruszka Date: Sat Feb 12 21:06:51 2011 +0100 PM / Hibernate: Return error code when alloc_image_page() fails commit 2e725a065b0153f0c449318da1923a120477633d upstream. Currently we return 0 in swsusp_alloc() when alloc_image_page() fails. Fix that. Also remove unneeded "error" variable since the only useful value of error is -ENOMEM. [rjw: Fixed up the changelog and changed subject.] Signed-off-by: Stanislaw Gruszka Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3393d8f7f8282ec1a154b8df502d7f0ca142ba31 Author: Martin Schwidefsky Date: Tue Feb 15 09:43:32 2011 +0100 s390: remove task_show_regs commit 261cd298a8c363d7985e3482946edb4bfedacf98 upstream. task_show_regs used to be a debugging aid in the early bringup days of Linux on s390. /proc//status is a world readable file, it is not a good idea to show the registers of a process. The only correct fix is to remove task_show_regs. Reported-by: Al Viro Signed-off-by: Martin Schwidefsky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6af40f1c9359c9c795b68a0ae7be4f49e6f95e67 Author: NeilBrown Date: Wed Feb 16 13:08:35 2011 +1100 nfsd: correctly handle return value from nfsd_map_name_to_* commit 47c85291d3dd1a51501555000b90f8e281a0458e upstream. These functions return an nfs status, not a host_err. So don't try to convert before returning. This is a regression introduced by 3c726023402a2f3b28f49b9d90ebf9e71151157d; I fixed up two of the callers, but missed these two. Reported-by: Herbert Poetzl Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit bf9a5b3f21bb693155c9f890efad91975a318300 Author: David S. Miller Date: Wed Nov 24 11:47:22 2010 -0800 tcp: Make TCP_MAXSEG minimum more correct. commit c39508d6f118308355468314ff414644115a07f3 upstream. Use TCP_MIN_MSS instead of constant 64. Reported-by: Min Zhang Signed-off-by: David S. Miller Cc: Moritz Muehlenhoff Signed-off-by: Greg Kroah-Hartman commit fefec0cbd52b128b2b4d57c71eb6b54000039e33 Author: David S. Miller Date: Wed Nov 10 21:35:37 2010 -0800 tcp: Increase TCP_MAXSEG socket option minimum. commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 upstream. As noted by Steve Chen, since commit f5fff5dc8a7a3f395b0525c02ba92c95d42b7390 ("tcp: advertise MSS requested by user") we can end up with a situation where tcp_select_initial_window() does a divide by a zero (or even negative) mss value. The problem is that sometimes we effectively subtract TCPOLEN_TSTAMP_ALIGNED and/or TCPOLEN_MD5SIG_ALIGNED from the mss. Fix this by increasing the minimum from 8 to 64. Reported-by: Steve Chen Signed-off-by: David S. Miller Cc: Moritz Muehlenhoff Signed-off-by: Greg Kroah-Hartman commit af25a83d14fd4d66e68bb28b9e0c3b60382025f2 Author: Ajit Khaparde Date: Fri Feb 19 13:57:12 2010 +0000 be2net: Maintain tx and rx counters in driver commit 91992e446cadbbde1a304de6954afd715af5121e upstream. For certain skews of the BE adapter, H/W Tx and Rx counters could be common for more than one interface. Add Tx and Rx counters in the adapter structure (to maintain stats on a per interfae basis). Signed-off-by: Ajit Khaparde Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit cffffe24025c34c22f9a13d6a1ad817401e5d824 Author: Li Zefan Date: Thu Mar 11 14:08:10 2010 -0800 sunrpc/cache: fix module refcnt leak in a failure path commit a5990ea1254cd186b38744507aeec3136a0c1c95 upstream. Don't forget to release the module refcnt if seq_open() returns failure. Signed-off-by: Li Zefan Cc: J. Bruce Fields Cc: Neil Brown Cc: Trond Myklebust Signed-off-by: Andrew Morton Signed-off-by: J. Bruce Fields Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 37f7d55cdf298cca1da8f881d3cbf4eba1d3ba88 Author: Brian King Date: Fri Feb 19 10:08:31 2010 -0600 scsi_dh_alua: Add IBM Power Virtual SCSI ALUA device to dev list commit 22963a37b3437a25812cc856afa5a84ad4a3f541 upstream. Adds IBM Power Virtual SCSI ALUA devices to the ALUA device handler. Signed-off-by: Brian King Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit c1b07e9ca5a83e678e60ab5c08d26273e8fffa60 Author: Mike Christie Date: Thu Feb 18 17:32:03 2010 -0600 scsi_dh_alua: add netapp to dev list commit cd4a8814d44672bd2c8f04a472121bfbe193809c upstream. Newer Netapp target software supports ALUA, so this patch adds them to the scsi_dev_alua dev list. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit ecd28df16abedcd61fbd94921a514c13948c2390 Author: Milton Miller Date: Fri Feb 19 17:44:42 2010 +0000 ixgbe: prevent speculative processing of descriptors before ready commit 3c945e5b3719bcc18c6ddd31bbcae8ef94f3d19a upstream. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. Signed-off-by: Milton Miller Signed-off-by: Anton Blanchard Acked-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit b584b3505db0b94c231014a6d3aa3c5a72298660 Author: Thomas Gleixner Date: Wed Sep 29 22:16:36 2010 +0200 isdn: hisax: Replace the bogus access to irq stats commit 40f08a724fcc21285cf3a75aec957aef908605c6 upstream. Abusing irq stats in a driver for counting interrupts is a horrible idea and not safe with shared interrupts. Replace it by a local interrupt counter. Noticed by the attempt to remove the irq stats export. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Cc: maximilian attems commit b1d02fe72b50877d5d106b1bafa5d908bbcfa68b Author: J. R. Okajima Date: Wed Aug 11 13:10:16 2010 -0400 NFS: fix the return value of nfs_file_fsync() commit 0702099bd86c33c2dcdbd3963433a61f3f503901 upstream. By the commit af7fa16 2010-08-03 NFS: Fix up the fsync code close(2) became returning the non-zero value even if it went well. nfs_file_fsync() should return 0 when "status" is positive. Signed-off-by: J. R. Okajima Signed-off-by: Trond Myklebust Signed-off-by: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit 8f2f330a85acad0e2eb6d8529ccde763ed49548a Author: Tetsuo Handa Date: Mon Feb 7 13:36:16 2011 +0000 CRED: Fix memory and refcount leaks upon security_prepare_creds() failure commit fb2b2a1d37f80cc818fd4487b510f4e11816e5e1 upstream. In prepare_kernel_cred() since 2.6.29, put_cred(new) is called without assigning new->usage when security_prepare_creds() returned an error. As a result, memory for new and refcount for new->{user,group_info,tgcred} are leaked because put_cred(new) won't call __put_cred() unless old->usage == 1. Fix these leaks by assigning new->usage (and new->subscribers which was added in 2.6.32) before calling security_prepare_creds(). Signed-off-by: Tetsuo Handa Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fbca9e285c0131b2182c34aaf6836858483e5339 Author: Tetsuo Handa Date: Mon Feb 7 13:36:10 2011 +0000 CRED: Fix BUG() upon security_cred_alloc_blank() failure commit 2edeaa34a6e3f2c43b667f6c4f7b27944b811695 upstream. In cred_alloc_blank() since 2.6.32, abort_creds(new) is called with new->security == NULL and new->magic == 0 when security_cred_alloc_blank() returns an error. As a result, BUG() will be triggered if SELinux is enabled or CONFIG_DEBUG_CREDENTIALS=y. If CONFIG_DEBUG_CREDENTIALS=y, BUG() is called from __invalid_creds() because cred->magic == 0. Failing that, BUG() is called from selinux_cred_free() because selinux_cred_free() is not expecting cred->security == NULL. This does not affect smack_cred_free(), tomoyo_cred_free() or apparmor_cred_free(). Fix these bugs by (1) Set new->magic before calling security_cred_alloc_blank(). (2) Handle null cred->security in creds_are_invalid() and selinux_cred_free(). Signed-off-by: Tetsuo Handa Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 22047f7542d6d7f7fa7860d5193bc5be2f0f1221 Author: Tetsuo Handa Date: Fri Feb 4 18:13:24 2011 +0000 CRED: Fix kernel panic upon security_file_alloc() failure. commit 78d2978874e4e10e97dfd4fd79db45bdc0748550 upstream. In get_empty_filp() since 2.6.29, file_free(f) is called with f->f_cred == NULL when security_file_alloc() returned an error. As a result, kernel will panic() due to put_cred(NULL) call within RCU callback. Fix this bug by assigning f->f_cred before calling security_file_alloc(). Signed-off-by: Tetsuo Handa Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 006c514c67d28b1242e29fa89061cb4201f776eb Author: David Howells Date: Thu Jul 29 12:45:49 2010 +0100 CRED: Fix get_task_cred() and task_state() to not resurrect dead credentials commit de09a9771a5346029f4d11e4ac886be7f9bfdd75 upstream. It's possible for get_task_cred() as it currently stands to 'corrupt' a set of credentials by incrementing their usage count after their replacement by the task being accessed. What happens is that get_task_cred() can race with commit_creds(): TASK_1 TASK_2 RCU_CLEANER -->get_task_cred(TASK_2) rcu_read_lock() __cred = __task_cred(TASK_2) -->commit_creds() old_cred = TASK_2->real_cred TASK_2->real_cred = ... put_cred(old_cred) call_rcu(old_cred) [__cred->usage == 0] get_cred(__cred) [__cred->usage == 1] rcu_read_unlock() -->put_cred_rcu() [__cred->usage == 1] panic() However, since a tasks credentials are generally not changed very often, we can reasonably make use of a loop involving reading the creds pointer and using atomic_inc_not_zero() to attempt to increment it if it hasn't already hit zero. If successful, we can safely return the credentials in the knowledge that, even if the task we're accessing has released them, they haven't gone to the RCU cleanup code. We then change task_state() in procfs to use get_task_cred() rather than calling get_cred() on the result of __task_cred(), as that suffers from the same problem. Without this change, a BUG_ON in __put_cred() or in put_cred_rcu() can be tripped when it is noticed that the usage count is not zero as it ought to be, for example: kernel BUG at kernel/cred.c:168! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/kernel/mm/ksm/run CPU 0 Pid: 2436, comm: master Not tainted 2.6.33.3-85.fc13.x86_64 #1 0HR330/OptiPlex 745 RIP: 0010:[] [] __put_cred+0xc/0x45 RSP: 0018:ffff88019e7e9eb8 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff880161514480 RCX: 00000000ffffffff RDX: 00000000ffffffff RSI: ffff880140c690c0 RDI: ffff880140c690c0 RBP: ffff88019e7e9eb8 R08: 00000000000000d0 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000040 R12: ffff880140c690c0 R13: ffff88019e77aea0 R14: 00007fff336b0a5c R15: 0000000000000001 FS: 00007f12f50d97c0(0000) GS:ffff880007400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f461bc000 CR3: 00000001b26ce000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process master (pid: 2436, threadinfo ffff88019e7e8000, task ffff88019e77aea0) Stack: ffff88019e7e9ec8 ffffffff810698cd ffff88019e7e9ef8 ffffffff81069b45 <0> ffff880161514180 ffff880161514480 ffff880161514180 0000000000000000 <0> ffff88019e7e9f28 ffffffff8106aace 0000000000000001 0000000000000246 Call Trace: [] put_cred+0x13/0x15 [] commit_creds+0x16b/0x175 [] set_current_groups+0x47/0x4e [] sys_setgroups+0xf6/0x105 [] system_call_fastpath+0x16/0x1b Code: 48 8d 71 ff e8 7e 4e 15 00 85 c0 78 0b 8b 75 ec 48 89 df e8 ef 4a 15 00 48 83 c4 18 5b c9 c3 55 8b 07 8b 07 48 89 e5 85 c0 74 04 <0f> 0b eb fe 65 48 8b 04 25 00 cc 00 00 48 3b b8 58 04 00 00 75 RIP [] __put_cred+0xc/0x45 RSP ---[ end trace df391256a100ebdd ]--- Signed-off-by: David Howells Acked-by: Jiri Olsa Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f8d85f781b6f24384fdfbcd81e083f84af630474 Author: Dan Carpenter Date: Fri Jan 7 16:41:54 2011 -0300 av7110: check for negative array offset commit cb26a24ee9706473f31d34cc259f4dcf45cd0644 upstream. info->num comes from the user. It's type int. If the user passes in a negative value that would cause memory corruption. Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 132a10e37130f769046d68fa36306c940c981869 Author: Jeremy Fitzhardinge Date: Mon Oct 25 16:53:46 2010 -0700 x86/pvclock: Zero last_value on resume commit e7a3481c0246c8e45e79c629efd63b168e91fcda upstream. If the guest domain has been suspend/resumed or migrated, then the system clock backing the pvclock clocksource may revert to a smaller value (ie, can be non-monotonic across the migration/save-restore). Make sure we zero last_value in that case so that the domain continues to see clock updates. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 267be76c7ce0edf9e443c0654786bf2221dcadd6 Author: Apollon Oikonomopoulos Date: Tue Dec 7 09:43:30 2010 +0000 x25: decrement netdev reference counts on unload commit 171995e5d82dcc92bea37a7d2a2ecc21068a0f19 upstream. x25 does not decrement the network device reference counts on module unload. Thus unregistering any pre-existing interface after unloading the x25 module hangs and results in unregister_netdevice: waiting for tap0 to become free. Usage count = 1 This patch decrements the reference counts of all interfaces in x25_link_free, the way it is already done in x25_link_device_down for NETDEV_DOWN events. Signed-off-by: Apollon Oikonomopoulos Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5aab0d7a20e4dca3268888c81ffa960531388347 Author: Dan Rosenberg Date: Mon Sep 27 12:30:28 2010 -0400 Fix pktcdvd ioctl dev_minor range check commit 252a52aa4fa22a668f019e55b3aac3ff71ec1c29 upstream. The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a pktcdvd_device from the global pkt_devs array. The index into this array is provided directly by the user and is a signed integer, so the comparison to ensure that it falls within the bounds of this array will fail when provided with a negative index. This can be used to read arbitrary kernel memory or cause a crash due to an invalid pointer dereference. This can be exploited by users with permission to open /dev/pktcdvd/control (on many distributions, this is readable by group "cdrom"). Signed-off-by: Dan Rosenberg [ Rather than add a cast, just make the function take the right type -Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2bc3c404decf406bfadd88001945bc2673fc6e4f Author: dann frazier Date: Thu Nov 18 15:03:09 2010 -0700 ocfs2_connection_find() returns pointer to bad structure commit 226291aa4641fa13cb5dec3bcb3379faa83009e2 upstream. If ocfs2_live_connection_list is empty, ocfs2_connection_find() will return a pointer to the LIST_HEAD, cast as a ocfs2_live_connection. This can cause an oops when ocfs2_control_send_down() dereferences c->oc_conn: Call Trace: [] ocfs2_control_message+0x28c/0x2b0 [ocfs2_stack_user] [] ocfs2_control_write+0x35/0xb0 [ocfs2_stack_user] [] vfs_write+0xb8/0x1a0 [] ? do_page_fault+0x153/0x3b0 [] sys_write+0x51/0x80 [] system_call_fastpath+0x16/0x1b Fix by explicitly returning NULL if no match is found. Signed-off-by: dann frazier Signed-off-by: Joel Becker Signed-off-by: Greg Kroah-Hartman commit 57c247a86588c5602e26367728be7fd61d3b334a Author: Dan Rosenberg Date: Fri Oct 1 11:51:47 2010 +0000 sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac() commit 51e97a12bef19b7e43199fc153cf9bd5f2140362 upstream. The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids array and attempts to ensure that only a supported hmac entry is returned. The current code fails to do this properly - if the last id in the array is out of range (greater than SCTP_AUTH_HMAC_ID_MAX), the id integer remains set after exiting the loop, and the address of an out-of-bounds entry will be returned and subsequently used in the parent function, causing potentially ugly memory corruption. This patch resets the id integer to 0 on encountering an invalid id so that NULL will be returned after finishing the loop if no valid ids are found. Signed-off-by: Dan Rosenberg Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 23c49826ab1e94a05c1b4c726afb6cd24c8704e2 Author: Kashyap, Desai Date: Thu Feb 10 11:53:44 2011 +0530 mptfusion: Fix Incorrect return value in mptscsih_dev_reset commit bcfe42e98047f1935c5571c8ea77beb2d43ec19d upstream. There's a branch at the end of this function that is supposed to normalize the return value with what the mid-layer expects. In this one case, we get it wrong. Also increase the verbosity of the INFO level printk at the end of mptscsih_abort to include the actual return value and the scmd->serial_number. The reason being success or failure is actually determined by the state of the internal tag list when a TMF is issued, and not the return value of the TMF cmd. The serial_number is also used in this decision, thus it's useful to know for debugging purposes. Reported-by: Peter M. Petrakis Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 1bf4c7636f2d3b3491c6366a981b2b56bb5c8afc Author: Kashyap, Desai Date: Thu Feb 10 11:52:21 2011 +0530 mptfusion: mptctl_release is required in mptctl.c commit 84857c8bf83e8aa87afc57d2956ba01f11d82386 upstream. Added missing release callback for file_operations mptctl_fops. Without release callback there will be never freed. It remains on mptctl's eent list even after the file is closed and released. Relavent RHEL bugzilla is 660871 Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 74d2a55a8bc405f5f28cf471e0a463f62eaf54d2 Author: Konstantin Khorenko Date: Tue Feb 1 17:16:29 2011 +0300 NFSD: memory corruption due to writing beyond the stat array commit 3aa6e0aa8ab3e64bbfba092c64d42fd1d006b124 upstream. If nfsd fails to find an exported via NFS file in the readahead cache, it should increment corresponding nfsdstats counter (ra_depth[10]), but due to a bug it may instead write to ra_depth[11], corrupting the following field. In a kernel with NFSDv4 compiled in the corruption takes the form of an increment of a counter of the number of NFSv4 operation 0's received; since there is no operation 0, this is harmless. In a kernel with NFSDv4 disabled it corrupts whatever happens to be in the memory beyond nfsdstats. Signed-off-by: Konstantin Khorenko Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit c8a3f6e5a73553f3d3ced5f9d0529e367d4609a1 Author: Sarah Sharp Date: Thu Dec 23 11:12:42 2010 -0800 usb: Realloc xHCI structures after a hub is verified. commit 653a39d1f61bdc9f277766736d21d2e9be0391cb upstream. When there's an xHCI host power loss after a suspend from memory, the USB core attempts to reset and verify the USB devices that are attached to the system. The xHCI driver has to reallocate those devices, since the hardware lost all knowledge of them during the power loss. When a hub is plugged in, and the host loses power, the xHCI hardware structures are not updated to say the device is a hub. This is usually done in hub_configure() when the USB hub is detected. That function is skipped during a reset and verify by the USB core, since the core restores the old configuration and alternate settings, and the hub driver has no idea this happened. This bug makes the xHCI host controller reject the enumeration of low speed devices under the resumed hub. Therefore, make the USB core re-setup the internal xHCI hub device information by calling update_hub_device() when hub_activate() is called for a hub reset resume. After a host power loss, all devices under the roothub get a reset-resume or a disconnect. This patch should be queued for the 2.6.37 stable tree. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 0bff213e8a2e779175998d6187429922b59f8369 Author: Suresh Siddha Date: Thu Feb 3 12:20:04 2011 -0800 x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm commit 831d52bc153971b70e64eccfbed2b232394f22f8 upstream. Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while the cr3 is still pointing to the prev mm. And this window can lead to the possibility of bogus TLB fills resulting in strange failures. One such problematic scenario is mentioned below. T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI etc between the point of clearing the cpu from the mm_cpumask(mm1) and before reloading the cr3 with the new mm2. T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with flushing the TLB for mm1. It doesn't send the flush TLB to CPU-1 as it doesn't see that cpu listed in the mm_cpumask(mm1). T3. After the TLB flush is complete, CPU-2 goes ahead and frees the page-table pages associated with the removed vma mapping. T4. CPU-2 now allocates those freed page-table pages for something else. T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1 can potentially speculate and walk through the page-table caches and can insert new TLB entries. As the page-table pages are already freed and being used on CPU-2, this page walk can potentially insert a bogus global TLB entry depending on the (random) contents of the page that is being used on CPU-2. T6. This bogus TLB entry being global will be active across future CR3 changes and can result in weird memory corruption etc. To avoid this issue, for the prev mm that is handing over the cpu to another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is changed. Marking it for -stable, though we haven't seen any reported failure that can be attributed to this. Signed-off-by: Suresh Siddha Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2a3664f6a6939d0add4e447eb0264126e2f7be2b Author: Chris Wilson Date: Thu Jan 20 10:03:24 2011 +0000 drm/i915: Add dependency on CONFIG_TMPFS commit f7ab9b407b3bc83161c2aa74c992ba4782e87c9c upstream. Without tmpfs, shmem_readpage() is not compiled in causing an OOPS as soon as we try to allocate some swappable pages for GEM. Jan 19 22:52:26 harlie kernel: Modules linked in: i915(+) drm_kms_helper cfbcopyarea video backlight cfbimgblt cfbfillrect Jan 19 22:52:26 harlie kernel: Jan 19 22:52:26 harlie kernel: Pid: 1125, comm: modprobe Not tainted 2.6.37Harlie #10 To be filled by O.E.M./To be filled by O.E.M. Jan 19 22:52:26 harlie kernel: EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 3 Jan 19 22:52:26 harlie kernel: EIP is at 0x0 Jan 19 22:52:26 harlie kernel: EAX: 00000000 EBX: f7b7d000 ECX: f3383100 EDX: f7b7d000 Jan 19 22:52:26 harlie kernel: ESI: f1456118 EDI: 00000000 EBP: f2303c98 ESP: f2303c7c Jan 19 22:52:26 harlie kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jan 19 22:52:26 harlie kernel: Process modprobe (pid: 1125, ti=f2302000 task=f259cd80 task.ti=f2302000) Jan 19 22:52:26 harlie kernel: Stack: Jan 19 22:52:26 harlie udevd-work[1072]: '/sbin/modprobe -b pci:v00008086d00000046sv00000000sd00000000bc03sc00i00' unexpected exit with status 0x0009 Jan 19 22:52:26 harlie kernel: c1074061 000000d0 f2f42b80 00000000 000a13d2 f2d5dcc0 00000001 f2303cac Jan 19 22:52:26 harlie kernel: c107416f 00000000 000a13d2 00000000 f2303cd4 f8d620ed f2cee620 00001000 Jan 19 22:52:26 harlie kernel: 00000000 000a13d2 f1456118 f2d5dcc0 f1a40000 00001000 f2303d04 f8d637ab Jan 19 22:52:26 harlie kernel: Call Trace: Jan 19 22:52:26 harlie kernel: [] ? do_read_cache_page+0x71/0x160 Jan 19 22:52:26 harlie kernel: [] ? read_cache_page_gfp+0x1f/0x30 Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_get_pages+0xad/0x1d0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_bind_to_gtt+0xeb/0x2d0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_gem_object_pin+0x151/0x190 [i915] Jan 19 22:52:26 harlie kernel: [] ? drm_gem_object_init+0x3d/0x60 Jan 19 22:52:26 harlie kernel: [] ? i915_gem_init_ringbuffer+0x105/0x1e0 [i915] Jan 19 22:52:26 harlie kernel: [] ? i915_driver_load+0x667/0x1160 [i915] Reported-by: John J. Stimson-III Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 6e5e4477d63af2a5ffd9a8020a7aa9289f1f4b34 Author: Knut Petersen Date: Fri Jan 14 15:38:10 2011 +0000 drm/i915/lvds: Add AOpen i915GMm-HFS to the list of false-positive LVDS commit 22ab70d3262ddb6e69b3c246a34e2967ba5eb1e8 upstream. Signed-off-by: Knut Petersen Signed-off-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit 2a4232e1c1c1a821bf012fc6fe3211fbed0e0f05 Author: Alex Deucher Date: Wed Feb 2 19:46:06 2011 -0500 drm/radeon/kms: fix s/r issues with bios scratch regs commit 87364760de5d631390c478fcbac8db1b926e0adf upstream. The accelerate mode bit gets checked by certain atom command tables to set up some register state. It needs to be clear when setting modes and set when not. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=26942 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 2dc65dfd4e358e2057880dcaabc5416a96b5cd5f Author: Alex Deucher Date: Tue Feb 1 19:06:46 2011 -0500 drm/radeon: remove 0x4243 pci id commit 63a507800c8aca5a1891d598ae13f829346e8e39 upstream. 0x4243 is a PCI bridge, not a GPU. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=33815 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 012756942c46e1f645af4eeace2d911ce0b5fa6e Author: Alex Deucher Date: Mon Jan 31 16:48:51 2011 -0500 drm/radeon/kms: add pll debugging output commit 51d4bf840a27fe02c883ddc6d9708af056773769 upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit df00c3d5194963ac1bcd7a234d98681a46e1148a Author: Jerome Glisse Date: Wed Jan 26 17:51:03 2011 -0500 radeon/kms: fix dp displayport mode validation commit 6bba2e116808ca12e30c8d88dfedabf8b8d67390 upstream. Check if there is a big enough dp clock & enough dp lane to drive the video mode provided. Signed-off-by: Jerome Glisse Reviewed-By: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 30877fc89aec3196b6572915144ec6c2882b0608 Author: Alex Deucher Date: Tue Jan 18 18:26:11 2011 +0000 drm/radeon/kms: make the mac rv630 quirk generic commit be23da8ad219650517cbbb7acbeaeb235667113a upstream. Seems some other boards do this as well. Reported-by: Andrea Merello Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 61eab5d5b5782aed3c21e52f7a98d96def224e37 Author: Alex Deucher Date: Tue Jan 4 00:43:39 2011 -0500 drm/radeon/kms: add quirk for Mac Radeon HD 2600 card commit f598aa7593427ffe3a61e7767c34bd695a5e7ed0 upstream. Reported-by: 屋国遥 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit fdeb2363045f81ba7ce97dc22abe05e02b0d1b52 Author: Mike Snitzer Date: Thu Jan 13 19:59:46 2011 +0000 dm mpath: disable blk_abort_queue commit 09c9d4c9b6a2b5909ae3c6265e4cd3820b636863 upstream. Revert commit 224cb3e981f1b2f9f93dbd49eaef505d17d894c2 dm: Call blk_abort_queue on failed paths Multipath began to use blk_abort_queue() to allow for lower latency path deactivation. This was found to cause list corruption: the cmd gets blk_abort_queued/timedout run on it and the scsi eh somehow is able to complete and run scsi_queue_insert while scsi_request_fn is still trying to process the request. https://www.redhat.com/archives/dm-devel/2010-November/msg00085.html Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Cc: Mike Anderson Cc: Mike Christie Signed-off-by: Greg Kroah-Hartman commit 8e71d6122e26d85672d9e7ef5e001dec289190b4 Author: Mike Snitzer Date: Thu Jan 13 19:53:46 2011 +0000 dm: dont take i_mutex to change device size commit c217649bf2d60ac119afd71d938278cffd55962b upstream. No longer needlessly hold md->bdev->bd_inode->i_mutex when changing the size of a DM device. This additional locking is unnecessary because i_size_write() is already protected by the existing critical section in dm_swap_table(). DM already has a reference on md->bdev so the associated bd_inode may be changed without lifetime concerns. A negative side-effect of having held md->bdev->bd_inode->i_mutex was that a concurrent DM device resize and flush (via fsync) would deadlock. Dropping md->bdev->bd_inode->i_mutex eliminates this potential for deadlock. The following reproducer no longer deadlocks: https://www.redhat.com/archives/dm-devel/2009-July/msg00284.html Signed-off-by: Mike Snitzer Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit bc0a20a9e8d35e81dd4b6bd65f03db30074f0581 Author: Amitkumar Karwar Date: Tue Jan 11 16:14:24 2011 -0800 ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro commit 8d661f1e462d50bd83de87ee628aaf820ce3c66c upstream. It is defined in include/linux/ieee80211.h. As per IEEE spec. bit6 to bit15 in block ack parameter represents buffer size. So the bitmask should be 0xFFC0. Signed-off-by: Amitkumar Karwar Signed-off-by: Bing Zhao Reviewed-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8a79989a2ae13b66764aea35156dd7a7e572c356 Author: Matthew Garrett Date: Thu Oct 21 17:42:40 2010 -0400 tpm: Autodetect itpm devices commit 3f0d3d016d89a5efb8b926d4707eb21fa13f3d27 upstream. Some Lenovos have TPMs that require a quirk to function correctly. This can be autodetected by checking whether the device has a _HID of INTC0102. This is an invalid PNPid, and as such is discarded by the pnp layer - however it's still present in the ACPI code, so we can pull it out that way. This means that the quirk won't be automatically applied on non-ACPI systems, but without ACPI we don't have any way to identify the chip anyway so I don't think that's a great concern. Signed-off-by: Matthew Garrett Acked-by: Rajiv Andrade Tested-by: Jiri Kosina Tested-by: Andy Isaacson Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 22bd8535f36e895c87dc5d14b8dda917b3dc9cf2 Author: Eric Paris Date: Thu Dec 2 16:13:40 2010 -0500 SELinux: do not compute transition labels on mountpoint labeled filesystems commit 415103f9932d45f7927f4b17e3a9a13834cdb9a1 upstream. selinux_inode_init_security computes transitions sids even for filesystems that use mount point labeling. It shouldn't do that. It should just use the mount point label always and no matter what. This causes 2 problems. 1) it makes file creation slower than it needs to be since we calculate the transition sid and 2) it allows files to be created with a different label than the mount point! # id -Z staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 # sesearch --type --class file --source sysadm_t --target tmp_t Found 1 semantic te rules: type_transition sysadm_t tmp_t : file user_tmp_t; # mount -o loop,context="system_u:object_r:tmp_t:s0" /tmp/fs /mnt/tmp # ls -lZ /mnt/tmp drwx------. root root system_u:object_r:tmp_t:s0 lost+found # touch /mnt/tmp/file1 # ls -lZ /mnt/tmp -rw-r--r--. root root staff_u:object_r:user_tmp_t:s0 file1 drwx------. root root system_u:object_r:tmp_t:s0 lost+found Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t labeled file! Signed-off-by: Eric Paris Reviewed-by: Reviewed-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 17bb9661ff7564562d0dedd558f255408d274121 Author: Eric Paris Date: Thu Dec 16 11:46:51 2010 -0500 SELinux: define permissions for DCB netlink messages commit 350e4f31e0eaf56dfc3b328d24a11bdf42a41fb8 upstream. Commit 2f90b865 added two new netlink message types to the netlink route socket. SELinux has hooks to define if netlink messages are allowed to be sent or received, but it did not know about these two new message types. By default we allow such actions so noone likely noticed. This patch adds the proper definitions and thus proper permissions enforcement. Signed-off-by: Eric Paris Cc: James Morris Signed-off-by: Greg Kroah-Hartman commit 249afc04243913d4b3fab154079197102fbb4c8e Author: Rajiv Andrade Date: Fri Nov 12 22:30:02 2010 +0100 TPM: Long default timeout fix commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit b2feccf658128a26c8c149a570099dac7684f661 Author: Tejun Heo Date: Sun Jan 9 17:48:20 2011 -0500 pata_mpc52xx: inherit from ata_bmdma_port_ops commit 77c5fd19075d299fe820bb59bb21b0b113676e20 upstream. pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which triggers BUG_ON() when a DMA command is issued. Fix it. Signed-off-by: Tejun Heo Reported-by: Roman Fietze Cc: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit ce4aad68fad96b4de17241106404b725b6476d86 Author: NeilBrown Date: Wed Jan 12 09:03:35 2011 +1100 md: fix regression with re-adding devices to arrays with no metadata commit bf572541ab44240163eaa2d486b06f306a31d45a upstream. Commit 1a855a0606 (2.6.37-rc4) fixed a problem where devices were re-added when they shouldn't be but caused a regression in a less common case that means sometimes devices cannot be re-added when they should be. In particular, when re-adding a device to an array without metadata we should always access the device, but after the above commit we didn't. This patch sets the In_sync flag in that case so that the re-add succeeds. This patch is suitable for any -stable kernel to which 1a855a0606 was applied. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit dd27f28ba28e59f20025ad5fdbcf95648ab8af63 Author: Anton Blanchard Date: Thu Jan 20 14:44:33 2011 -0800 kernel/smp.c: fix smp_call_function_many() SMP race commit 6dc19899958e420a931274b94019e267e2396d3e upstream. I noticed a failure where we hit the following WARN_ON in generic_smp_call_function_interrupt: if (!cpumask_test_and_clear_cpu(cpu, data->cpumask)) continue; data->csd.func(data->csd.info); refs = atomic_dec_return(&data->refs); WARN_ON(refs < 0); <------------------------- We atomically tested and cleared our bit in the cpumask, and yet the number of cpus left (ie refs) was 0. How can this be? It turns out commit 54fdade1c3332391948ec43530c02c4794a38172 ("generic-ipi: make struct call_function_data lockless") is at fault. It removes locking from smp_call_function_many and in doing so creates a rather complicated race. The problem comes about because: - The smp_call_function_many interrupt handler walks call_function.queue without any locking. - We reuse a percpu data structure in smp_call_function_many. - We do not wait for any RCU grace period before starting the next smp_call_function_many. Imagine a scenario where CPU A does two smp_call_functions back to back, and CPU B does an smp_call_function in between. We concentrate on how CPU C handles the calls: CPU A CPU B CPU C CPU D smp_call_function smp_call_function_interrupt walks call_function.queue sees data from CPU A on list smp_call_function smp_call_function_interrupt walks call_function.queue sees (stale) CPU A on list smp_call_function int clears last ref on A list_del_rcu, unlock smp_call_function reuses percpu *data A data->cpumask sees and clears bit in cpumask might be using old or new fn! decrements refs below 0 set data->refs (too late!) The important thing to note is since the interrupt handler walks a potentially stale call_function.queue without any locking, then another cpu can view the percpu *data structure at any time, even when the owner is in the process of initialising it. The following test case hits the WARN_ON 100% of the time on my PowerPC box (having 128 threads does help :) #include #include #define ITERATIONS 100 static void do_nothing_ipi(void *dummy) { } static void do_ipis(struct work_struct *dummy) { int i; for (i = 0; i < ITERATIONS; i++) smp_call_function(do_nothing_ipi, NULL, 1); printk(KERN_DEBUG "cpu %d finished\n", smp_processor_id()); } static struct work_struct work[NR_CPUS]; static int __init testcase_init(void) { int cpu; for_each_online_cpu(cpu) { INIT_WORK(&work[cpu], do_ipis); schedule_work_on(cpu, &work[cpu]); } return 0; } static void __exit testcase_exit(void) { } module_init(testcase_init) module_exit(testcase_exit) MODULE_LICENSE("GPL"); MODULE_AUTHOR("Anton Blanchard"); I tried to fix it by ordering the read and the write of ->cpumask and ->refs. In doing so I missed a critical case but Paul McKenney was able to spot my bug thankfully :) To ensure we arent viewing previous iterations the interrupt handler needs to read ->refs then ->cpumask then ->refs _again_. Thanks to Milton Miller and Paul McKenney for helping to debug this issue. [miltonm@bga.com: add WARN_ON and BUG_ON, remove extra read of refs before initial read of mask that doesn't help (also noted by Peter Zijlstra), adjust comments, hopefully clarify scenario ] [miltonm@bga.com: remove excess tests] Signed-off-by: Anton Blanchard Signed-off-by: Milton Miller Cc: Ingo Molnar Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d12879db6eaa45e1717bddb828b7dfeec5cfe1fd Author: Michael Büsch Date: Fri Feb 4 23:34:45 2011 +0100 ssb-pcmcia: Fix parsing of invariants tuples commit dd3cb633078fb12e06ce6cebbdfbf55a7562e929 upstream. This fixes parsing of the device invariants (MAC address) for PCMCIA SSB devices. ssb_pcmcia_do_get_invariants expects an iv pointer as data argument. Tested-by: dylan cristiani Signed-off-by: Michael Buesch Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4796e5e331675712ec5d4e26a6b904d856c99058 Author: Stefan Richter Date: Sat Jan 15 18:19:48 2011 +0100 firewire: core: fix unstable I/O with Canon camcorder commit 6044565af458e7fa6e748bff437ecc49dea88d79 upstream. Regression since commit 10389536742c, "firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder": The camcorder Canon MV5i generates lots of bus resets when asynchronous requests are sent to it (e.g. Config ROM read requests or FCP Command write requests) if the camcorder is not root node. This causes drop- outs in videos or makes the camcorder entirely inaccessible. https://bugzilla.redhat.com/show_bug.cgi?id=633260 Fix this by allowing any Canon device, even if it is a pre-1394a IRM like MV5i are, to remain root node (if it is at least Cycle Master capable). With the FireWire controller cards that I tested, MV5i always becomes root node when plugged in and left to its own devices. Reported-by: Ralf Lange Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 3bb03410e25218cc3d7634babb00f2da66dc6650 Author: Benjamin Herrenschmidt Date: Thu Jan 20 20:35:23 2011 +0000 powerpc: Fix some 6xx/7xxx CPU setup functions commit 1f1936ff3febf38d582177ea319eaa278f32c91f upstream. Some of those functions try to adjust the CPU features, for example to remove NAP support on some revisions. However, they seem to use r5 as an index into the CPU table entry, which might have been right a long time ago but no longer is. r4 is the right register to use. This probably caused some off behaviours on some PowerMac variants using 750cx or 7455 processor revisions. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 4c0821e7a7ebca3614995845b91a640c6919fdc5 Author: Anton Blanchard Date: Thu Oct 21 00:52:12 2010 +0000 powerpc: Fix hcall tracepoint recursion commit 57cdfdf829a850a317425ed93c6a576c9ee6329c upstream. Spinlocks on shared processor partitions use H_YIELD to notify the hypervisor we are waiting on another virtual CPU. Unfortunately this means the hcall tracepoints can recurse. The patch below adds a percpu depth and checks it on both the entry and exit hcall tracepoints. Signed-off-by: Anton Blanchard Acked-by: Steven Rostedt Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 1f9b4d210cc74010c9b6f24dc854bf1da52262f8 Author: Justin TerAvest Date: Wed Feb 9 14:20:03 2011 +0100 cfq-iosched: Don't wait if queue already has requests. commit 02a8f01b5a9f396d0327977af4c232d0f94c45fd upstream. Commit 7667aa0630407bc07dc38dcc79d29cc0a65553c1 added logic to wait for the last queue of the group to become busy (have at least one request), so that the group does not lose out for not being continuously backlogged. The commit did not check for the condition that the last queue already has some requests. As a result, if the queue already has requests, wait_busy is set. Later on, cfq_select_queue() checks the flag, and decides that since the queue has a request now and wait_busy is set, the queue is expired. This results in early expiration of the queue. This patch fixes the problem by adding a check to see if queue already has requests. If it does, wait_busy is not set. As a result, time slices do not expire early. The queues with more than one request are usually buffered writers. Testing shows improvement in isolation between buffered writers. Signed-off-by: Justin TerAvest Reviewed-by: Gui Jianfeng Acked-by: Vivek Goyal Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1327258317f30e48a67b39f6a2dd0049daa1d46c Author: David Miller Date: Sun Feb 13 16:37:07 2011 -0800 klist: Fix object alignment on 64-bit. commit 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505 upstream. Commit c0e69a5bbc6f ("klist.c: bit 0 in pointer can't be used as flag") intended to make sure that all klist objects were at least pointer size aligned, but used the constant "4" which only works on 32-bit. Use "sizeof(void *)" which is correct in all cases. Signed-off-by: David S. Miller Acked-by: Jesper Nilsson Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4d77999fd16484510b65799ab0ebf00c700c0c16 Author: Dario Lombardo Date: Fri Jan 21 15:35:19 2011 +0100 drivers: update to pl2303 usb-serial to support Motorola cables commit 96a3e79edff6f41b0f115a82f1a39d66218077a7 upstream. Added 0x0307 device id to support Motorola cables to the pl2303 usb serial driver. This cable has a modified chip that is a pl2303, but declares itself as 0307. Fixed by adding the right device id to the supported devices list, assigning it the code labeled PL2303_PRODUCT_ID_MOTOROLA. Signed-off-by: Dario Lombardo Signed-off-by: Greg Kroah-Hartman commit 445772b82658a50d568a5f8082afdbe1f9df3a2d Author: Simone Contini Date: Mon Apr 12 23:25:10 2010 +0200 USB: serial: pl2303: Hybrid reader Uniform HCR331 commit 18344a1cd5889d48dac67229fcf024ed300030d5 upstream. I tried a magnetic stripe reader (http://www.kimaldi.com/kimaldi_eng/productos/lectores_de_tarjetas/lectores_tarjeta_chip_y_dni/lector_hibrido_uniform_hcr_331) and I see that it is interfaced with a PL2303. I wrote a patch to use your driver which simply adds the product ID for the device and it seems working fine. From: Simone Contini Signed-off-by: Greg Kroah-Hartman commit 66622d09ac2597d858ecbcf1a22c03f8a069638a Author: Tim Deegan Date: Thu Feb 10 08:50:41 2011 +0000 fix jiffy calculations in calibrate_delay_direct to handle overflow commit 70a062286b9dfcbd24d2e11601aecfead5cf709a upstream. Fixes a hang when booting as dom0 under Xen, when jiffies can be quite large by the time the kernel init gets this far. Signed-off-by: Tim Deegan [jbeulich@novell.com: !time_after() -> time_before_eq() as suggested by Jiri Slaby] Signed-off-by: Jan Beulich Cc: Jiri Slaby Cc: Jeremy Fitzhardinge Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 61f5f3c07b38a55de0e6ed1f6e412790366a9068 Author: Suresh Siddha Date: Wed Feb 2 17:02:55 2011 -0800 x86, mtrr: Avoid MTRR reprogramming on BP during boot on UP platforms commit f7448548a9f32db38f243ccd4271617758ddfe2c upstream. Markus Kohn ran into a hard hang regression on an acer aspire 1310, when acpi is enabled. git bisect showed the following commit as the bad one that introduced the boot regression. commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3 Author: Suresh Siddha Date: Wed Aug 19 18:05:36 2009 -0700 x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init Because of the UP configuration of that platform, native_smp_prepare_cpus() bailed out (in smp_sanity_check()) before doing the set_mtrr_aps_delayed_init() Further down the boot path, native_smp_cpus_done() will call the delayed MTRR initialization for the AP's (mtrr_aps_init()) with mtrr_aps_delayed_init not set. This resulted in the boot processor reprogramming its MTRR's to the values seen during the start of the OS boot. While this is not needed ideally, this shouldn't have caused any side-effects. This is because the reprogramming of MTRR's (set_mtrr_state() that gets called via set_mtrr()) will check if the live register contents are different from what is being asked to write and will do the actual write only if they are different. BP's mtrr state is read during the start of the OS boot and typically nothing would have changed when we ask to reprogram it on BP again because of the above scenario on an UP platform. So on a normal UP platform no reprogramming of BP MTRR MSR's happens and all is well. However, on this platform, bios seems to be modifying the fixed mtrr range registers between the start of OS boot and when we double check the live registers for reprogramming BP MTRR registers. And as the live registers are modified, we end up reprogramming the MTRR's to the state seen during the start of the OS boot. During ACPI initialization, something in the bios (probably smi handler?) don't like this fact and results in a hard lockup. We didn't see this boot hang issue on this platform before the commit d0af9eed5aa91b6b7b5049cae69e5ea956fd85c3, because only the AP's (if any) will program its MTRR's to the value that BP had at the start of the OS boot. Fix this issue by checking mtrr_aps_delayed_init before continuing further in the mtrr_aps_init(). Now, only AP's (if any) will program its MTRR's to the BP values during boot. Addresses https://bugzilla.novell.com/show_bug.cgi?id=623393 [ By the way, this behavior of the bios modifying MTRR's after the start of the OS boot is not common and the kernel is not prepared to handle this situation well. Irrespective of this issue, during suspend/resume, linux kernel will try to reprogram the BP's MTRR values to the values seen during the start of the OS boot. So suspend/resume might be already broken on this platform for all linux kernel versions. ] Reported-and-bisected-by: Markus Kohn Tested-by: Markus Kohn Signed-off-by: Suresh Siddha Cc: Thomas Renninger Cc: Rafael Wysocki Cc: Venkatesh Pallipadi LKML-Reference: <1296694975.4418.402.camel@sbsiddha-MOBL3.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a0c3347293050b7d76aef3fbfc69466946c0da52 Author: Eric W. Biederman Date: Sat Jan 29 14:57:22 2011 +0000 net: Fix ip link add netns oops commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream. Ed Swierk writes: > On 2.6.35.7 > ip link add link eth0 netns 9999 type macvlan > where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang: > [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d > [10663.821917] IP: [] __dev_alloc_name+0x9a/0x170 > [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0 > [10663.821944] Oops: 0000 [#1] SMP > [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [10663.821959] CPU 3 > [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class > [10663.822155] > [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO > [10663.822167] RIP: 0010:[] [] __dev_alloc_name+0x9a/0x170 > [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286 > [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000 > [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000 > [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041 > [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818 > [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000 > [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000 > [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0 > [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0) > [10663.822236] Stack: > [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6 > [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818 > [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413 > [10663.822281] Call Trace: > [10663.822290] [] ? dev_addr_init+0x75/0xb0 > [10663.822298] [] dev_alloc_name+0x43/0x90 > [10663.822307] [] rtnl_create_link+0xbe/0x1b0 > [10663.822314] [] rtnl_newlink+0x48a/0x570 > [10663.822321] [] ? rtnl_newlink+0x1ac/0x570 > [10663.822332] [] ? native_x2apic_icr_read+0x4/0x20 > [10663.822339] [] rtnetlink_rcv_msg+0x177/0x290 > [10663.822346] [] ? rtnetlink_rcv_msg+0x0/0x290 > [10663.822354] [] netlink_rcv_skb+0xa9/0xd0 > [10663.822360] [] rtnetlink_rcv+0x25/0x40 > [10663.822367] [] netlink_unicast+0x2de/0x2f0 > [10663.822374] [] netlink_sendmsg+0x1fe/0x2e0 > [10663.822383] [] sock_sendmsg+0xf3/0x120 > [10663.822391] [] ? _raw_spin_lock+0xe/0x20 > [10663.822400] [] ? __d_lookup+0x136/0x150 > [10663.822406] [] ? _raw_spin_lock+0xe/0x20 > [10663.822414] [] ? _atomic_dec_and_lock+0x4d/0x80 > [10663.822422] [] ? mntput_no_expire+0x30/0x110 > [10663.822429] [] ? move_addr_to_kernel+0x65/0x70 > [10663.822435] [] ? verify_iovec+0x88/0xe0 > [10663.822442] [] sys_sendmsg+0x240/0x3a0 > [10663.822450] [] ? __do_fault+0x479/0x560 > [10663.822457] [] ? _raw_spin_lock+0xe/0x20 > [10663.822465] [] ? alloc_fd+0x10a/0x150 > [10663.822473] [] ? do_page_fault+0x15e/0x350 > [10663.822482] [] system_call_fastpath+0x16/0x1b > [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55 > [10663.822618] RIP [] __dev_alloc_name+0x9a/0x170 > [10663.822627] RSP > [10663.822631] CR2: 000000000000006d > [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]--- This bug was introduced in: commit 81adee47dfb608df3ad0b91d230fb3cef75f0060 Author: Eric W. Biederman Date: Sun Nov 8 00:53:51 2009 -0800 net: Support specifying the network namespace upon device creation. There is no good reason to not support userspace specifying the network namespace during device creation, and it makes it easier to create a network device and pass it to a child network namespace with a well known name. We have to be careful to ensure that the target network namespace for the new device exists through the life of the call. To keep that logic clear I have factored out the network namespace grabbing logic into rtnl_link_get_net. In addtion we need to continue to pass the source network namespace to the rtnl_link_ops.newlink method so that we can find the base device source network namespace. Signed-off-by: Eric W. Biederman Acked-by: Eric Dumazet Where apparently I forgot to add error handling to the path where we create a new network device in a new network namespace, and pass in an invalid pid. Reported-by: Ed Swierk Signed-off-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit edf07481f5a833b01bf23910834133fdac72fde1 Author: Tejun Heo Date: Thu Feb 10 15:01:22 2011 -0800 ptrace: use safer wake up on ptrace_detach() commit 01e05e9a90b8f4c3997ae0537e87720eb475e532 upstream. The wake_up_process() call in ptrace_detach() is spurious and not interlocked with the tracee state. IOW, the tracee could be running or sleeping in any place in the kernel by the time wake_up_process() is called. This can lead to the tracee waking up unexpectedly which can be dangerous. The wake_up is spurious and should be removed but for now reduce its toxicity by only waking up if the tracee is in TRACED or STOPPED state. This bug can possibly be used as an attack vector. I don't think it will take too much effort to come up with an attack which triggers oops somewhere. Most sleeps are wrapped in condition test loops and should be safe but we have quite a number of places where sleep and wakeup conditions are expected to be interlocked. Although the window of opportunity is tiny, ptrace can be used by non-privileged users and with some loading the window can definitely be extended and exploited. Signed-off-by: Tejun Heo Acked-by: Roland McGrath Acked-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0769e495f2a53ac6e1e52b1a5954a1f90b52c3d2 Author: Pavel Machek Date: Sun Jan 9 08:38:48 2011 +0100 serial: unbreak billionton CF card commit d0694e2aeb815042aa0f3e5036728b3db4446f1d upstream. Unbreak Billionton CF bluetooth card. This actually fixes a regression on zaurus. Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit d8f2ab6a443454b9e0e0728418339f75b9ecd809 Author: Jean Delvare Date: Fri Jan 14 22:03:49 2011 +0100 i2c: Unregister dummy devices last on adapter removal commit 5219bf884b6e2b54e734ca1799b6f0014bb2b4b7 upstream. Remove real devices first and dummy devices last. This gives device driver which instantiated dummy devices themselves a chance to clean them up before we do. Signed-off-by: Jean Delvare Tested-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e2e38d481ef60ccc6724f996bb8c131daa156c28 Author: Christian Lamparter Date: Thu Jan 6 23:47:52 2011 +0100 p54: fix sequence no. accounting off-by-one error commit 3b5c5827d1f80ad8ae844a8b1183f59ddb90fe25 upstream. P54_HDR_FLAG_DATA_OUT_SEQNR is meant to tell the firmware that "the frame's sequence number has already been set by the application." Whereas IEEE80211_TX_CTL_ASSIGN_SEQ is set for frames which lack a valid sequence number and either the driver or firmware has to assign one. Yup, it's the exact opposite! Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 10b75926fef4637862aeb35bb0d2dd3e518ff2b9 Author: Sven Neumann Date: Fri Nov 12 11:36:22 2010 +0100 ds2760_battery: Fix calculation of time_to_empty_now commit 86af95039b69a90db15294eb1f9c147f1df0a8ea upstream. A check against division by zero was modified in commit b0525b48. Since this change time_to_empty_now is always reported as zero while the battery is discharging and as a negative value while the battery is charging. This is because current is negative while the battery is discharging. Fix the check introduced by commit b0525b48 so that time_to_empty_now is reported correctly during discharge and as zero while charging. Signed-off-by: Sven Neumann Acked-by: Daniel Mack Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman commit ec00083b5319728c4223e62dd603f4aac2985843 Author: Milton Miller Date: Fri Jan 7 02:55:06 2011 -0600 virtio: remove virtio-pci root device commit 8b3bb3ecf1934ac4a7005ad9017de1127e2fbd2f upstream. We sometimes need to map between the virtio device and the given pci device. One such use is OS installer that gets the boot pci device from BIOS and needs to find the relevant block device. Since it can't, installation fails. Instead of creating a top-level devices/virtio-pci directory, create each device under the corresponding pci device node. Symlinks to all virtio-pci devices can be found under the pci driver link in bus/pci/drivers/virtio-pci/devices, and all virtio devices under drivers/bus/virtio/devices. Signed-off-by: Milton Miller Signed-off-by: Rusty Russell Acked-by: Michael S. Tsirkin Tested-by: Michael S. Tsirkin Acked-by: Gleb Natapov Tested-by: "Daniel P. Berrange" Signed-off-by: Greg Kroah-Hartman commit b1c47a314a92d625d7a438d5d886115a6831ac9f Author: Tejun Heo Date: Wed Dec 22 10:06:36 2010 +0100 PCI: pci-stub: ignore zero-length id parameters commit 99a0fadf561e1f553c08f0a29f8b2578f55dd5f0 upstream. pci-stub uses strsep() to separate list of ids and generates a warning message when it fails to parse an id. However, not specifying the parameter results in ids set to an empty string. strsep() happily returns the empty string as the first token and thus triggers the warning message spuriously. Make the tokner ignore zero length ids. Reported-by: Chris Wright Reported-by: Prasad Joshi Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 8512adb61ffe72f5875421f548a6a964336115f0 Author: Thomas Taranowski Date: Wed Jan 12 17:00:44 2011 -0800 rapidio: fix hang on RapidIO doorbell queue full condition commit 12a4dc43911785f51a596f771ae0701b18d436f1 upstream. In fsl_rio_dbell_handler() the code currently simply acknowledges the QFI queue full interrupt, but does nothing to resolve the queue full condition. Instead, it jumps to the end of the isr. When a queue full condition occurs, the isr is then re-entered immediately and continually, forever. The fix is to just fall through and read out current doorbell entries. Signed-off-by: Thomas Taranowski Cc: Alexandre Bounine Cc: Kumar Gala Cc: Matt Porter Cc: Li Yang Cc: Thomas Moll Cc: Micha Nelissen Cc: Benjamin Herrenschmidt Cc: Grant Likely Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5daa2a8aec9f4f2ad3cdb8a0ba9a61597aa5f898 Author: Paul Fox Date: Wed Jan 12 17:00:07 2011 -0800 rtc-cmos: fix suspend/resume commit 2fb08e6ca9f00d1aedb3964983e9c8f84b36b807 upstream. rtc-cmos was setting suspend/resume hooks at the device_driver level. However, the platform bus code (drivers/base/platform.c) only looks for resume hooks at the dev_pm_ops level, or within the platform_driver. Switch rtc_cmos to use dev_pm_ops so that suspend/resume code is executed again. Paul said: : The user visible symptom in our (XO laptop) case was that rtcwake would : fail to wake the laptop. The RTC alarm would expire, but the wakeup : wasn't unmasked. : : As for severity, the impact may have been reduced because if I recall : correctly, the bug only affected platforms with CONFIG_PNP disabled. Signed-off-by: Paul Fox Signed-off-by: Daniel Drake Acked-by: Rafael J. Wysocki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ee6322c509bdf8566c2d90d02b38fa7be5cdf3d0 Author: Chuck Lever Date: Fri Jan 21 15:54:57 2011 +0000 NFS: Fix "kernel BUG at fs/aio.c:554!" commit 839f7ad6932d95f4d5ae7267b95c574714ff3d5b upstream. Nick Piggin reports: > I'm getting use after frees in aio code in NFS > > [ 2703.396766] Call Trace: > [ 2703.396858] [] ? native_sched_clock+0x27/0x80 > [ 2703.396959] [] ? put_lock_stats+0xe/0x40 > [ 2703.397058] [] ? lock_release_holdtime+0xa8/0x140 > [ 2703.397159] [] lock_acquire+0x95/0x1b0 > [ 2703.397260] [] ? aio_put_req+0x2b/0x60 > [ 2703.397361] [] ? get_parent_ip+0x11/0x50 > [ 2703.397464] [] _raw_spin_lock_irq+0x41/0x80 > [ 2703.397564] [] ? aio_put_req+0x2b/0x60 > [ 2703.397662] [] aio_put_req+0x2b/0x60 > [ 2703.397761] [] do_io_submit+0x2be/0x7c0 > [ 2703.397895] [] sys_io_submit+0xb/0x10 > [ 2703.397995] [] system_call_fastpath+0x16/0x1b > > Adding some tracing, it is due to nfs completing the request then > returning something other than -EIOCBQUEUED, so aio.c > also completes the request. To address this, prevent the NFS direct I/O engine from completing async iocbs when the forward path returns an error without starting any I/O. This fix appears to survive ^C during both "xfstest no. 208" and "fsx -Z." It's likely this bug has existed for a very long while, as we are seeing very similar symptoms in OEL 5. Copying stable. Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c9592f07f243b5605ddbe5b9d7a7cfe5652de919 Author: Mike Frysinger Date: Tue Jan 11 19:57:33 2011 -0500 ASoC: Blackfin AC97: fix build error after multi-component update commit e9c2048915048d605fd76539ddd96f00d593e1eb upstream. We need to tweak how we query the active capture/playback state after the recent overhauls of common code. Signed-off-by: Mike Frysinger Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 92b9c597d6c869648a04db3f32faaf22aeba8c8b Author: Dimitris Papastamos Date: Fri Jan 14 15:59:13 2011 +0000 ASoC: WM8990: msleep() takes milliseconds not jiffies commit 7ebcf5d6021a696680ee77d9162a2edec2d671dd upstream. Signed-off-by: Dimitris Papastamos Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 841d1e0a6aad6f65dae941af38c0f2566e4fa781 Author: Clemens Ladisch Date: Thu Feb 10 16:15:44 2011 +0100 ALSA: hrtimer: handle delayed timer interrupts commit b1d4f7f4bdcf9915c41ff8cfc4425c84dabb1fde upstream. If a timer interrupt was delayed too much, hrtimer_forward_now() will forward the timer expiry more than once. When this happens, the additional number of elapsed ALSA timer ticks must be passed to snd_timer_interrupt() to prevent the ALSA timer from falling behind. This mostly fixes MIDI slowdown problems on highly-loaded systems with badly behaved interrupt handlers. Signed-off-by: Clemens Ladisch Reported-and-tested-by: Arthur Marsh Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8352da691f11ec260191ab58d49da20bd4782b94 Author: Edgar (gimli) Hucek Date: Tue Nov 9 17:38:42 2010 +0100 input: bcm5974: Add support for MacBookAir3 commit 6021afcf19d8c6f5db6d11cadcfb6a22d0c28a48 upstream. This patch adds support for the MacBookAir3,1 and MacBookAir3,2 models. [rydberg@euromail.se: touchpad range calibration] Signed-off-by: Edgar (gimli) Hucek Signed-off-by: Henrik Rydberg Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9b40136e548a2954f90628e503d1bc9f146cf752 Author: Takashi Iwai Date: Wed Feb 2 17:16:38 2011 +0100 ALSA: hda - Fix memory leaks in conexant jack arrays commit 70f7db11c45a313b23922cacf248c613c3b2144c upstream. The Conexant codec driver adds the jack arrays in init callback which may be called also in each PM resume. This results in the addition of new jack element at each time. The fix is to check whether the requested jack is already present in the array. Reference: Novell bug 668929 https://bugzilla.novell.com/show_bug.cgi?id=668929 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a791782f6f2e9759e26c1ccb10c661942b2da314 Author: David Henningsson Date: Tue Jan 25 19:44:26 2011 +0100 ALSA: HDA: Fix dmesg output of HDMI supported bits commit d757534ed15387202e322854cd72dc58bbb975de upstream. This typo caused the dmesg output of the supported bits of HDMI to be cut off early. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c59b7f8316082c2c44fde4de7007ebca5d2169b7 Author: Raymond Yau Date: Sun Jan 16 10:55:54 2011 +0800 ALSA : au88x0 - Limit number of channels to fix Oops via OSS emu commit d9ab344336f74c012f6643ed3d1ad8ca0136de3b upstream. Fix playback/capture channels patch to change supported playback channels of au8830 to 1,2,4 and capture channels to 1,2. This prevent oops when oss emulation use SNDCTL_DSP_CHANNELS to set 3 Channels Signed-off-by: Raymond Yau Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1f5b107fd55a5dcc94b1a2161221cba3e53fc4ba Author: Mauro Carvalho Chehab Date: Mon Oct 25 17:51:15 2010 -0300 em28xx: Fix audio input for Terratec Grabby commit a3fa904ec79b94f0db7faed010ff94d42f7d1d47 upstream. The audio input line was wrong. Fix it. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1c2f5926f21af23d73f92ee391d2adda2b6d7459 Author: Mauro Carvalho Chehab Date: Thu Jan 6 08:16:04 2011 -0200 radio-aimslab.c: Fix gcc 4.5+ bug commit e3c92215198cb6aa00ad38db2780faa6b72e0a3f upstream. gcc 4.5+ doesn't properly evaluate some inlined expressions. A previous patch were proposed by Andrew Morton using noinline. However, the entire inlined function is bogus, so let's just remove it and be happy. Reported-by: Andrew Morton Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3a08cff3675f1402d25127a4adce931d28f360b8 Author: Kashyap, Desai Date: Tue Nov 17 13:16:37 2009 +0530 mpt2sas: add missing initialization of scsih_cmds commit d685c262083dcd5fd98b7499b22a377a3225229c upstream. Internal command scsih_cmds init is included in mpt2sas_base_attach. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8e742a685c57cc5fea5d1d98bf4f4dbf953ea4ee Author: Kashyap, Desai Date: Tue Jan 4 11:38:39 2011 +0530 mpt2sas: Kernel Panic during Large Topology discovery commit 4224489f45b503f0a1f1cf310f76dc108f45689a upstream. There was a configuration page timing out during the initial port enable at driver load time. The port enable would fail, and this would result in the driver unloading itself, meanwhile the driver was accessing freed memory in another context resulting in the panic. The fix is to prevent access to freed memory once the driver had issued the diag reset which woke up the sleeping port enable process. The routine _base_reset_handler was reorganized so the last sleeping process woken up was the port_enable. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8e704f267ee2980bb51a71bf8d644507b9f7c874 Author: Kashyap, Desai Date: Tue Jan 4 11:34:57 2011 +0530 mpt2sas: Correct resizing calculation for max_queue_depth commit 11e1b961ab067ee3acaf723531da4d3f23e1d6f7 upstream. The ioc->hba_queue_depth is not properly resized when the controller firmware reports that it supports more outstanding IO than what can be fit inside the reply descriptor pool depth. This is reproduced by setting the controller global credits larger than 30,000. The bug results in an incorrect sizing of the queues. The fix is to resize the queue_size by dividing queue_diff by two. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 783d92c878039172d281fd03fdd0ceee665a1a3d Author: Kashyap, Desai Date: Tue Jan 4 11:32:13 2011 +0530 mpt2sas: Fix device removal handshake for zoned devices commit 4dc2757a2e9a9d1f2faee4fc6119276fc0061c16 upstream. When zoning end devices, the driver is not sending device removal handshake alogrithm to firmware. This results in controller firmware not sending sas topology add events the next time the device is added. The fix is the driver should be doing the device removal handshake even though the PHYSTATUS_VACANT bit is set in the PhyStatus of the event data. The current design is avoiding the handshake when the VACANT bit is set in the phy status. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b7c594f128716d94767c9c165c5aee38639e7b6f Author: Kashyap, Desai Date: Tue Jan 4 11:40:23 2011 +0530 mpt2sas: fix Integrated Raid unsynced on shutdown problem commit 3a9c913a3e57b170887d39456e04c18f2305ec67 upstream. Issue: IR shutdown(sending) and IR shutdown(complete) messages not listed in /var/log/messages when driver is removed. The driver needs to issue a MPI2_RAID_ACTION_SYSTEM_SHUTDOWN_INITIATED request when the driver is unloaded so the IR metadata journal is updated. If this request is not sent, then the volume would need a "check consistency" issued on the next bootup if the volume was roamed from one initiator to another. The current driver supports this feature only when the system is rebooted, however this also need to be supported if the driver is unloaded Fix: To fix this issue, the driver is going to need to call the _scsih_ir_shutdown prior to reporting the volumes missing from the OS, hence the device handles are still present. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit ac516aa27fabd38893f21eeb894dea16bee23a8c Author: James Bottomley Date: Thu Jan 20 17:26:44 2011 -0600 libsas: fix runaway error handler problem commit 9ee91f7fb550a4c82f82d9818e42493484c754af upstream. libsas makes use of scsi_schedule_eh() but forgets to clear the host_eh_scheduled flag in its error handling routine. Because of this, the error handler thread never gets to sleep; it's constantly awake and trying to run the error routine leading to console spew and inability to run anything else (at least on a UP system). The fix is to clear the flag as we splice the work queue. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 0a8513c92536d8272c6fbaa8c42e2740aaeb4942 Author: James Bottomley Date: Fri Dec 17 15:36:34 2010 -0500 fix medium error problems with some arrays which can cause data corruption commit a8733c7baf457b071528e385a0b7d4aaec79287c upstream. Our current handling of medium error assumes that data is returned up to the bad sector. This assumption holds good for all disk devices, all DIF arrays and most ordinary arrays. However, an LSI array engine was recently discovered which reports a medium error without returning any data. This means that when we report good data up to the medium error, we've reported junk originally in the buffer as good. Worse, if the read consists of requested data plus a readahead, and the error occurs in readahead, we'll just strip off the readahead and report junk up to userspace as good data with no error. The fix for this is to have the error position computation take into account the amount of data returned by the driver using the scsi residual data. Unfortunately, not every driver fills in this data, but for those who don't, it's set to zero, which means we'll think a full set of data was transferred and the behaviour will be identical to the prior behaviour of the code (believe the buffer up to the error sector). All modern drivers seem to set the residual, so that should fix up the LSI failure/corruption case. Reported-by: Douglas Gilbert Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 68ba505969284c6dacaea7e36c5bee4528847189 Author: Jan Glauber Date: Wed Jan 5 12:47:52 2011 +0100 qdio: use proper QEBSM operand for SIGA-R and SIGA-S commit 958c0ba403cb6a693b54be2389f9ef53377fa259 upstream. If QIOASSIST is enabled for a qdio device the SIGA instruction requires a modified function code. This function code modifier was missing for SIGA-R and SIGA-S which can lead to a kernel panic caused by an operand exception. Signed-off-by: Jan Glauber Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit f5aca15a9c1bb8b4ca7d9ff657759ff121358b33 Author: Martin Schwidefsky Date: Fri Feb 26 22:37:54 2010 +0100 correct vdso version string commit 13c6680acb3df25722858566b42759215ea5d2e0 upstream. The glibc vdso code for s390 uses the version string 2.6.29, the kernel uses the version string 2.6.26. No wonder the vdso code is never used. The first kernel version to contain the vdso code is 2.6.29 which makes this the correct version. Signed-off-by: Martin Schwidefsky Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 11b97e7ca403c13bdbba0ca1dda3b48e4f93c2f4 Author: Don Fry Date: Sun Feb 6 09:29:45 2011 -0800 iwlagn: Re-enable RF_KILL interrupt when down commit 3dd823e6b86407aed1a025041d8f1df77e43a9c8 upstream. With commit 554d1d027b19265c4aa3f718b3126d2b86e09a08 only one RF_KILL interrupt will be seen by the driver when the interface is down. Re-enable the interrupt when it occurs to see all transitions. Signed-off-by: Don Fry Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit af01e9c0cdb7e164a6eb22c2ce8c7ed9acd8f664 Author: Stanislaw Gruszka Date: Thu Dec 23 12:38:21 2010 +0100 iwlagn: enable only rfkill interrupt when device is down commit 554d1d027b19265c4aa3f718b3126d2b86e09a08 upstream. Since commit 6cd0b1cb872b3bf9fc5de4536404206ab74bafdd "iwlagn: fix hw-rfkill while the interface is down", we enable interrupts when device is not ready to receive them. However hardware, when it is in some inconsistent state, can generate other than rfkill interrupts and crash the system. I can reproduce crash with "kernel BUG at drivers/net/wireless/iwlwifi/iwl-agn.c:1010!" message, when forcing firmware restarts. To fix only enable rfkill interrupt when down device and after probe. I checked patch on laptop with 5100 device, rfkill change is still passed to user space when device is down. Signed-off-by: Stanislaw Gruszka Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 244b7f557447aafbe3bae0d3c25665fc5826b3b4 Author: Denis Kirjanov Date: Mon Jan 10 20:09:30 2011 +0000 staging: rt2860: Fix incorrect netif_stop_queue usage warning commit 9c33008412683eba91bce2dc4575f28c728b6bd1 upstream. The TX queues are allocated inside register_netdev. It doesn't make any sense to stop the queue before allocation. Signed-off-by: Denis Kirjanov Signed-off-by: Greg Kroah-Hartman commit 7ce49687d7af34535dd4a72f35b81270db822504 Author: Chen, Chien-Chia Date: Thu Dec 9 10:52:08 2010 +0800 Staging: rt2860: fix previous patch error commit 1f0613158ea14b399fd7a16470630a729ba9d0c3 upstream. Somehow Greg messed up the last patch and missed a chunk. This patch contains the missing chunk. Acked-by: Chun-Yi Lee Signed-off-by: Chien-Chia Chen Signed-off-by: Greg Kroah-Hartman commit 446fcbf1b8487ecec8bab92064da83b6341b33b8 Author: Chen, Chien-Chia Date: Wed Dec 8 14:20:33 2010 -0800 Staging: rt3090: Fix RT3090 scan AP function commit 1226056d9608d241db4b558a0d88a347ad5c66ae upstream. Fix RT3090 scan AP function. This patch fixes the rt3090 wireless module failed to scan AP around due to Windows driver causing rt3090 module unable to scan AP in Linux. Acked-by: Chun-Yi Lee Signed-off-by: Chien-Chia Chen Signed-off-by: Greg Kroah-Hartman commit 53798a65764d6ff1ce4c83263a2a2d1b621b7f29 Author: Hendrik Brueckner Date: Mon Mar 8 12:25:15 2010 +0100 hvc_iucv: allocate memory buffers for IUCV in zone DMA commit 91a970d9889c7d6f451ee91ed361d0f0119d3778 upstream. The device driver must allocate memory for IUCV buffers with GFP_DMA, because IUCV cannot address memory above 2GB (31bit addresses only). Because the IUCV ignores the higher bits of the address, sending and receiving IUCV data with this driver might cause memory corruptions. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Cc: maximilian attems commit 6e725f28b5c4298e06917269a7a7d33993f320cc Author: Ky Srinivasan Date: Thu Dec 16 18:59:19 2010 -0700 Staging: hv: fix sysfs symlink on hv block device commit 268eff909afaca93188d2d14554cbf824f6a0e41 upstream. The block device does not create the proper symlink in sysfs because we forgot to set up the gendisk structure properly. This patch fixes the issue. Signed-off-by: K. Y. Srinivasan Cc: Hank Janssen Cc: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman commit d436369c4c603f565358caab080633a926345f82 Author: Ian Abbott Date: Wed Jan 19 11:48:44 2011 +0000 staging: comedi: ni_labpc: Use shared IRQ for PCMCIA card commit d1ce318496f5943d2cc5e20171fc383a59a1421f upstream. The ni_labpc driver module only requests a shared IRQ for PCI devices, requesting a non-shared IRQ for non-PCI devices. As this module is also used by the ni_labpc_cs module for certain National Instruments PCMCIA cards, it also needs to request a shared IRQ for PCMCIA devices, otherwise you get a IRQ mismatch with the CardBus controller. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 51280e163d177b1d249fb7d4a6338c14cafde258 Author: Ruben Smits Date: Sat Dec 11 08:26:18 2010 +0100 staging: comedi: add support for newer jr3 1-channel pci board commit 6292817d58637f85dd623cfe563c7f5ec4f4c470 upstream. add DEVICE_ID to table Signed-off-by: Ruben Smits Signed-off-by: Greg Kroah-Hartman commit 6c8f7afcfad689a63dfed43743911fcb24401978 Author: Alan Stern Date: Mon Jan 31 10:56:37 2011 -0500 USB: prevent buggy hubs from crashing the USB stack commit d199c96d41d80a567493e12b8e96ea056a1350c1 upstream. If anyone comes across a high-speed hub that (by mistake or by design) claims to have no Transaction Translators, plugging a full- or low-speed device into it will cause the USB stack to crash. This patch (as1446) prevents the problem by ignoring such devices, since the kernel has no way to communicate with them. Signed-off-by: Alan Stern Tested-by: Perry Neben Signed-off-by: Greg Kroah-Hartman commit 0d4ea2f83aff8517b10cafe4b14577d9bed68584 Author: Michael Williamson Date: Thu Jan 27 18:36:19 2011 -0600 USB: ftdi_sio: Add VID=0x0647, PID=0x0100 for Acton Research spectrograph commit 28fe2eb0162a1d23370dd99ff7d0e35632b1ee91 upstream. Add the USB Vendor ID and Product ID for a Acton Research Corp. spectrograph device with a FTDI chip for serial I/O. Signed-off-by: Michael H Williamson Signed-off-by: Greg Kroah-Hartman commit 47bd2812767dae51ea0690a71e7f2cd3919eaf98 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Sat Jan 29 15:32:52 2011 +0100 USB: ftdi_sio: add ST Micro Connect Lite uart support commit 6ec2f46c4b4abf48c88c0ae7c476f347b97e1105 upstream. on ST Micro Connect Lite we have 4 port Part A and B for the JTAG Port C Uart Port D for PIO Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Greg Kroah-Hartman commit d7927020981261937c206601d7bfc9556e896ce6 Author: Nick Holloway Date: Wed Jan 26 21:47:43 2011 +0000 USB: Storage: Add unusual_devs entry for VTech Kidizoom commit c25f6b1591b158f7ae3b9132367d0fa6d632e70e upstream. This device suffers from the off-by-one error when reporting the capacity, so add entry with US_FL_FIX_CAPACITY. Signed-off-by: Nick Holloway Signed-off-by: Greg Kroah-Hartman commit 0c7d6cd9b045d8163accf173ddb19074d3d0fd94 Author: Ionut Nicu Date: Tue Dec 28 22:21:08 2010 +0200 USB: ti_usb: fix module removal commit b14de3857227cd978f515247853fd15cc2425d3e upstream. If usb_deregister() is called after usb_serial_deregister() when the device is plugged in, the following Oops occurs: [ 95.337377] BUG: unable to handle kernel NULL pointer dereference at 00000010 [ 95.338236] IP: [] klist_put+0x12/0x62 [ 95.338356] *pdpt = 000000003001a001 *pde = 0000000000000000 [ 95.338356] Oops: 0000 [#1] SMP [ 95.340499] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.2/usb8/idVendor [ 95.340499] Modules linked in: ti_usb_3410_5052(-) usbserial cpufreq_ondemand acpi_cpufreq mperf iptable_nat nf_nat iptable_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput arc4 ecb iwlagn iwlcore mac80211 cfg80211 microcode pcspkr acer_wmi joydev wmi sky2 [last unloaded: scsi_wait_scan] [ 95.341908] [ 95.341908] Pid: 1532, comm: modprobe Not tainted 2.6.37-rc7+ #6 Eiger /Aspire 5930 [ 95.341908] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 95.341908] EIP is at klist_put+0x12/0x62 [ 95.341908] EAX: 00000000 EBX: eedc0c84 ECX: c09c21b4 EDX: 00000001 [ 95.341908] ESI: 00000000 EDI: efaa0c1c EBP: f214fe2c ESP: f214fe1c [ 95.341908] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 95.341908] Process modprobe (pid: 1532, ti=f214e000 task=efaaf080 task.ti=f214e000) [ 95.341908] Stack: [ 95.341908] f214fe24 eedc0c84 efaaf080 efaa0c1c f214fe34 c0776ba8 f214fe5c c0776c76 [ 95.341908] c09c21b4 c09c21b4 eedc0c84 efaaf080 00000000 c0634398 eafe2d1c f7b515f0 [ 95.341908] f214fe6c c0631b5c eafe2d50 eafe2d1c f214fe7c c0631ba2 eafe2d1c eafe2c00 [ 95.341908] Call Trace: [ 95.341908] [] ? klist_del+0xd/0xf [ 95.341908] [] ? klist_remove+0x48/0x74 [ 95.341908] [] ? devres_release_all+0x49/0x51 [ 95.341908] [] ? __device_release_driver+0x7b/0xa4 [ 95.341908] [] ? device_release_driver+0x1d/0x28 [ 95.341908] [] ? bus_remove_device+0x92/0xa1 [ 95.341908] [] ? device_del+0xf9/0x13e [ 95.341908] [] ? usb_serial_disconnect+0xd9/0x116 [usbserial] [ 95.341908] [] ? usb_disable_interface+0x32/0x40 [ 95.341908] [] ? usb_unbind_interface+0x48/0xfd [ 95.341908] [] ? __device_release_driver+0x62/0xa4 [ 95.341908] [] ? driver_detach+0x62/0x81 [ 95.341908] [] ? bus_remove_driver+0x8f/0xae [ 95.341908] [] ? driver_unregister+0x50/0x57 [ 95.341908] [] ? usb_deregister+0x77/0x84 [ 95.341908] [] ? ti_exit+0x26/0x28 [ti_usb_3410_5052] [ 95.341908] [] ? sys_delete_module+0x181/0x1de [ 95.341908] [] ? path_put+0x1a/0x1d [ 95.341908] [] ? audit_syscall_entry+0x116/0x138 [ 95.341908] [] ? sysenter_do_call+0x12/0x28 [ 95.341908] Code: 00 83 7d f0 00 74 09 85 f6 74 05 89 f0 ff 55 f0 8b 43 04 5a 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 83 ec 04 8b 30 83 e6 fe 89 f0 <8b> 7e 10 88 55 f0 e8 47 26 01 00 8a 55 f0 84 d2 74 17 f6 03 01 [ 95.341908] EIP: [] klist_put+0x12/0x62 SS:ESP 0068:f214fe1c [ 95.341908] CR2: 0000000000000010 [ 95.342357] ---[ end trace 8124d00ad871ad18 ]--- Signed-off-by: Ionut Nicu Signed-off-by: Greg Kroah-Hartman commit b282a1e7f1adc5e7bc21c7d4c0f16610984fc63d Author: Bjørn Mork Date: Mon Jan 17 14:19:37 2011 +0100 USB: io_edgeport: fix the reported firmware major and minor commit 271c1150b4f8e1685e5a8cbf76e329ec894481da upstream. The major and minor number saved in the product_info structure were copied from the address instead of the data, causing an inconsistency in the reported versions during firmware loading: usb 4-1: firmware: requesting edgeport/down.fw /usr/src/linux/drivers/usb/serial/io_edgeport.c: downloading firmware version (930) 1.16.4 [..] /usr/src/linux/drivers/usb/serial/io_edgeport.c: edge_startup - time 3 4328191260 /usr/src/linux/drivers/usb/serial/io_edgeport.c: FirmwareMajorVersion 0.0.4 This can cause some confusion whether firmware loaded successfully or not. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 0f806c0914f85dc926193871a1435773418ffe2e Author: Alan Stern Date: Mon Jan 10 11:24:14 2011 -0500 USB: g_printer: fix bug in module parameter definitions commit ad84e4a9efb7c8ed322bafb6ebdb9c3a49a3d3a8 upstream. This patch (as1442) fixes a bug in g_printer: Module parameters should not be marked "__initdata" if they are accessible in sysfs (i.e., if the mode value in the module_param() macro is nonzero). Otherwise attempts to access the parameters will cause addressing violations. Character-string module parameters must not be marked "__initdata" if the module can be unloaded, because the kernel needs to access the parameter variable at unload time in order to free the dynamically-allocated string. Signed-off-by: Alan Stern CC: Roland Kletzing CC: Craig W. Nadler Signed-off-by: Greg Kroah-Hartman commit 4e6cff8669426db49452e3ab475e3c88239954c4 Author: Alan Stern Date: Thu Jan 6 10:17:09 2011 -0500 USB: EHCI: fix DMA deallocation bug commit f75593ceaa08e6d27aec1a5de31cded19e850dd1 upstream. This patch (as1440) fixes a bug in ehci-hcd. ehci->periodic_size is used to compute the size in a dma_alloc_coherent() call, but then it gets changed later on. As a result, the corresponding call to dma_free_coherent() passes a different size from the original allocation. Fix the problem by adjusting ehci->periodic_size before carrying out any of the memory allocations. Signed-off-by: Alan Stern Tested-by: Larry Finger CC: David Brownell Signed-off-by: Greg Kroah-Hartman commit eeffda606e0e1b1c1c949a75d8c73a99f0f0637c Author: Pieter Maes Date: Tue Jan 18 00:26:16 2011 +0100 USB: serial: Updated support for ICOM devices commit a9d61bc49188e32d2ae9cf0f683cde3e1744feef upstream. I found the original patch on the db0fhn repeater wiki (couldn't find the email of the origial author) I guess it was never commited. I updated and added some Icom HAM-radio devices to the ftdi driver. Added extra comments to make clear what devices it are. Signed-off-by: Pieter Maes Signed-off-by: Greg Kroah-Hartman commit 18cadc7d1232e5d4c2fea5c4f823052c20433343 Author: Alan Stern Date: Tue Jan 25 13:07:04 2011 -0500 USB: usb-storage: unusual_devs entry for Coby MP3 player commit 3ea3c9b5a8464ec8223125f95e5dddb3bfd02a39 upstream. This patch (as1444) adds an unusual_devs entry for an MP3 player from Coby electronics. The device has two nasty bugs. Signed-off-by: Alan Stern Tested-by: Jasper Mackenzie Signed-off-by: Greg Kroah-Hartman commit 7cfff59cda0dfb023ad28482081824bdff1187e2 Author: Alan Stern Date: Mon Jan 3 16:47:49 2011 -0500 USB: usb-storage: unusual_devs entry for CamSport Evo commit 12f68c480c7155a66bd2a76ab2fef28dd5f93fa2 upstream. This patch (as1438) adds an unusual_devs entry for the MagicPixel FW_Omega2 chip, used in the CamSport Evo camera. The firmware incorrectly reports a vendor-specific bDeviceClass. Signed-off-by: Alan Stern Reported-by: Signed-off-by: Greg Kroah-Hartman commit 3812b5655a5a96cf2d8bb889aa3f649ea6079fc3 Author: Richard Schütz Date: Wed Dec 22 14:28:56 2010 +0100 USB: usb-storage: unusual_devs update for TrekStor DataStation maxi g.u external hard drive enclosure commit 7e1e7bd9dbd469267b6e6de1bf8d71a7d65ce86a upstream. The TrekStor DataStation maxi g.u external hard drive enclosure uses a JMicron USB to SATA chip which needs the US_FL_IGNORE_RESIDUE flag to work properly. Signed-off-by: Richard Schütz Signed-off-by: Greg Kroah-Hartman commit 6ebb7dbbb6398177a3f3acb51cf0b6464f32cfcc Author: Richard Schütz Date: Sun Dec 19 21:18:38 2010 +0100 USB: usb-storage: unusual_devs update for Cypress ATACB commit cae41118f50ef0c431e13159df6d7dd8bbd54004 upstream. New device ID added for unusual Cypress ATACB device. Signed-off-by: Richard Schütz Signed-off-by: Greg Kroah-Hartman commit a9e7807087ec156943c6e40405626bcbb8167f27 Author: Oleg Nesterov Date: Fri Nov 5 16:53:42 2010 +0100 posix-cpu-timers: workaround to suppress the problems with mt exec commit e0a70217107e6f9844628120412cb27bb4cea194 upstream. posix-cpu-timers.c correctly assumes that the dying process does posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD timers from signal->cpu_timers list. But, it also assumes that timer->it.cpu.task is always the group leader, and thus the dead ->task means the dead thread group. This is obviously not true after de_thread() changes the leader. After that almost every posix_cpu_timer_ method has problems. It is not simple to fix this bug correctly. First of all, I think that timer->it.cpu should use struct pid instead of task_struct. Also, the locking should be reworked completely. In particular, tasklist_lock should not be used at all. This all needs a lot of nontrivial and hard-to-test changes. Change __exit_signal() to do posix_cpu_timers_exit_group() when the old leader dies during exec. This is not the fix, just the temporary hack to hide the problem for 2.6.37 and stable. IOW, this is obviously wrong but this is what we currently have anyway: cpu timers do not work after mt exec. In theory this change adds another race. The exiting leader can detach the timers which were attached to the new leader. However, the window between de_thread() and release_task() is small, we can pretend that sys_timer_create() was called before de_thread(). Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ad801fa0f9c4c08c75c506cc5d3cd0ab18a6ded3 Author: Vlad Yasevich Date: Thu May 6 00:56:07 2010 -0700 sctp: Fix a race between ICMP protocol unreachable and connect() commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819 upstream. ICMP protocol unreachable handling completely disregarded the fact that the user may have locked the socket. It proceeded to destroy the association, even though the user may have held the lock and had a ref on the association. This resulted in the following: Attempt to release alive inet socket f6afcc00 ========================= [ BUG: held lock freed! ] ------------------------- somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held there! (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c 1 lock held by somenu/2672: #0: (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c stack backtrace: Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55 Call Trace: [] ? printk+0xf/0x11 [] debug_check_no_locks_freed+0xce/0xff [] kmem_cache_free+0x21/0x66 [] __sk_free+0x9d/0xab [] sk_free+0x1c/0x1e [] sctp_association_put+0x32/0x89 [] __sctp_connect+0x36d/0x3f4 [] ? sctp_connect+0x13/0x4c [] ? autoremove_wake_function+0x0/0x33 [] sctp_connect+0x31/0x4c [] inet_dgram_connect+0x4b/0x55 [] sys_connect+0x54/0x71 [] ? lock_release_non_nested+0x88/0x239 [] ? might_fault+0x42/0x7c [] ? might_fault+0x42/0x7c [] sys_socketcall+0x6d/0x178 [] ? trace_hardirqs_on_thunk+0xc/0x10 [] syscall_call+0x7/0xb This was because the sctp_wait_for_connect() would aqcure the socket lock and then proceed to release the last reference count on the association, thus cause the fully destruction path to finish freeing the socket. The simplest solution is to start a very short timer in case the socket is owned by user. When the timer expires, we can do some verification and be able to do the release properly. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit de5e8ac404e76cbbd634ea60f974325d26c9b3d8 Author: Daniel T Chen Date: Tue Dec 28 17:20:02 2010 -0500 ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120 commit e03fa055bc126e536c7f65862e08a9b143138ea9 upstream. Sjoerd Simons reports that, without using position_fix=1, recording experiences overruns. Work around that by applying the LPIB quirk for his hardware. Reported-and-tested-by: Sjoerd Simons Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e2dc4ebe9b764f832943e0997a5599709a4340a0 Author: Mimi Zohar Date: Mon Jan 3 14:59:10 2011 -0800 ima: fix add LSM rule bug commit 867c20265459d30a01b021a9c1e81fb4c5832aa9 upstream. If security_filter_rule_init() doesn't return a rule, then not everything is as fine as the return code implies. This bug only occurs when the LSM (eg. SELinux) is disabled at runtime. Adding an empty LSM rule causes ima_match_rules() to always succeed, ignoring any remaining rules. default IMA TCB policy: # PROC_SUPER_MAGIC dont_measure fsmagic=0x9fa0 # SYSFS_MAGIC dont_measure fsmagic=0x62656572 # DEBUGFS_MAGIC dont_measure fsmagic=0x64626720 # TMPFS_MAGIC dont_measure fsmagic=0x01021994 # SECURITYFS_MAGIC dont_measure fsmagic=0x73636673 < LSM specific rule > dont_measure obj_type=var_log_t measure func=BPRM_CHECK measure func=FILE_MMAP mask=MAY_EXEC measure func=FILE_CHECK mask=MAY_READ uid=0 Thus without the patch, with the boot parameters 'tcb selinux=0', adding the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB measurement policy, would result in nothing being measured. The patch prevents the default TCB policy from being replaced. Signed-off-by: Mimi Zohar Cc: James Morris Acked-by: Serge Hallyn Cc: David Safford Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 32dc3265772c1d7930a4f5e4e679c23db8a14afa Author: Saeed Bishara Date: Tue Dec 21 16:53:39 2010 +0200 mv_xor: fix race in tasklet function commit 8333f65ef094e47020cd01452b4637e7daf5a77f upstream. use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function aquires the spin lock that needed to protect the drivers data. Signed-off-by: Saeed Bishara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 0dd40482f3d6bf04eb477c14d9e9443a3d59f1e9 Author: Dan Rosenberg Date: Sat Dec 25 16:23:40 2010 -0500 sound: Prevent buffer overflow in OSS load_mixer_volumes commit d81a12bc29ae4038770e05dce4ab7f26fd5880fb upstream. The load_mixer_volumes() function, which can be triggered by unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to a buffer overflow. Because the provided "name" argument isn't guaranteed to be NULL terminated at the expected 32 bytes, it's possible to overflow past the end of the last element in the mixer_vols array. Further exploitation can result in an arbitrary kernel write (via subsequent calls to load_mixer_volumes()) leading to privilege escalation, or arbitrary kernel reads via get_mixer_levels(). In addition, the strcmp() may leak bytes beyond the mixer_vols array. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d7d4c798c903b0463787c21a5a2f41ccebb026b8 Author: Eduardo Costa Date: Tue Dec 14 14:37:59 2010 -0600 p54usb: New USB ID for Gemtek WUBI-100GW commit 56e6417b49132d4f56e9f2241d31942b90b46315 upstream. This USB ID is for the WUBI-100GW 802.11g Wireless LAN USB Device that uses p54usb. Signed-off-by: Larry Finger Signed-off-by: Eduardo Costa Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 852a8f2368659f67667064f55517bb6e977b73ff Author: Christian Lamparter Date: Sat Dec 11 12:19:48 2010 +0100 p54usb: add 5 more USBIDs commit 16cad7fba037b34ca32cc0adac65bc089d969fb8 upstream. This patch adds five more USBIDs to the table. Source: http://www.linuxant.com/pipermail/driverloader/2005q3/002307.html http://wireless.kernel.org/en/users/Drivers/p54/devices (by M. Davis) Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f5884ae8ee8fcdeebd58ccdbc89de6013b8f02be Author: Vitaly Kuznetsov Date: Tue Dec 14 10:16:49 2010 -0500 USB: usb-storage: unusual_devs entry for the Samsung YP-CP3 commit d73a9b3001f29271c2e9f2a806b05a431c5d9591 upstream. Add an unusual_devs entry for the Samsung YP-CP3 MP4 player. User was getting the following errors in dmesg: usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: reset high speed USB device using ehci_hcd and address 2 usb 2-6: USB disconnect, address 2 sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb:<2>ldm_validate_partition_table(): Disk read failed. Dev sdb: unable to read RDB block 0 unable to read partition table Signed-off-by: Vitaly Kuznetsov Acked-by: Alan Stern CC: Matthew Dharm Signed-off-by: Greg Kroah-Hartman commit 2e3e89747b2a4fb4e85e8f5ec0388b9910fb67d2 Author: Thomas Sailer Date: Tue Dec 14 16:04:05 2010 +0100 USB: misc: uss720.c: add another vendor/product ID commit ecc1624a2fff45780959efbcb73ace18fdb3c58d upstream. Fabio Battaglia report that he has another cable that works with this driver, so this patch adds its vendor/product ID. Signed-off-by: Thomas Sailer Signed-off-by: Greg Kroah-Hartman commit b59f4c4209aadca12cc049baf9f9cb2f0c215f5b Author: Tavis Ormandy Date: Thu Dec 9 15:29:42 2010 +0100 install_special_mapping skips security_file_mmap check. commit 462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream. The install_special_mapping routine (used, for example, to setup the vdso) skips the security check before insert_vm_struct, allowing a local attacker to bypass the mmap_min_addr security restriction by limiting the available pages for special mappings. bprm_mm_init() also skips the check, and although I don't think this can be used to bypass any restrictions, I don't see any reason not to have the security check. $ uname -m x86_64 $ cat /proc/sys/vm/mmap_min_addr 65536 $ cat install_special_mapping.s section .bss resb BSS_SIZE section .text global _start _start: mov eax, __NR_pause int 0x80 $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o $ ./install_special_mapping & [1] 14303 $ cat /proc/14303/maps 0000f000-00010000 r-xp 00000000 00:00 0 [vdso] 00010000-00011000 r-xp 00001000 00:19 2453665 /home/taviso/install_special_mapping 00011000-ffffe000 rwxp 00000000 00:00 0 [stack] It's worth noting that Red Hat are shipping with mmap_min_addr set to 4096. Signed-off-by: Tavis Ormandy Acked-by: Kees Cook Acked-by: Robert Swiecki [ Changed to not drop the error code - akpm ] Reviewed-by: James Morris Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4550dcca25723fb3014d4a352eed5aa6f472245b Author: Alexander Duyck Date: Tue Mar 23 18:35:18 2010 +0000 igb: only use vlan_gro_receive if vlans are registered commit 31b24b955c3ebbb6f3008a6374e61cf7c05a193c upstream. This change makes it so that vlan_gro_receive is only used if vlans have been registered to the adapter structure. Previously we were just sending all vlan tagged frames in via this function but this results in a null pointer dereference when vlans are not registered. [ This fixes bugzilla entry 15582 -Eric Dumazet] Signed-off-by: Alexander Duyck Signed-off-by: Jeff Kirsher Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7cb215ebdfc6c255129f5baff525a2abd7237f0e Author: Krishna Gudipati Date: Fri May 21 14:39:45 2010 -0700 bfa: fix system crash when reading sysfs fc_host statistics commit 7873ca4e4401f0ecd8868bf1543113467e6bae61 upstream. The port data structure related to fc_host statistics collection is not initialized. This causes system crash when reading the fc_host statistics. The fix is to initialize port structure during driver attach. Signed-off-by: Krishna Gudipati Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 15bd914890cca7434047276c77e4962d93fb3a62 Author: Suresh Siddha Date: Mon Dec 6 12:26:30 2010 -0800 x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic commit 254e42006c893f45bca48f313536fcba12206418 upstream. On platforms with Intel 7500 chipset, there were some reports of system hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled. During kdump, there is a window where the devices might be still using old kernel's interrupt information, while the kdump kernel is coming up. This can cause vt-d faults as the interrupt configuration from the old kernel map to null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled, we still have the same issue but in this case we will see benign spurious interrupt hit the new kernel). Based on platform config settings, these platforms seem to generate NMI/SMI when a vt-d fault happens and there were reports that the resulting SMI causes the system to hang. Fix it by masking vt-d spec defined errors to platform error reporting logic. VT-d spec related errors are already handled by the VT-d OS code, so need to report the same error through other channels. Signed-off-by: Suresh Siddha LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> Reported-by: Max Asbock Reported-and-tested-by: Takao Indoh Acked-by: Chris Wright Acked-by: Kenji Kaneshige Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 0b480c14fdaa8d8113daf586ba351ae036934bbb Author: Kenji Kaneshige Date: Wed Dec 1 09:40:32 2010 -0800 x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode commit 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream. In x2apic mode, we need to set the upper address register of the fault handling interrupt register of the vt-d hardware. Without this irq migration of the vt-d fault handling interrupt is broken. Signed-off-by: Kenji Kaneshige LKML-Reference: <1291225233.2648.39.camel@sbsiddha-MOBL3> Signed-off-by: Suresh Siddha Acked-by: Chris Wright Tested-by: Takao Indoh Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit b1b82a34ab0b647e7df0367f9cbe5c96a7b4dd0c Author: Suresh Siddha Date: Tue Nov 30 22:22:29 2010 -0800 x86, vt-d: Handle previous faults after enabling fault handling commit 7f99d946e71e71d484b7543b49e990508e70d0c0 upstream. Fault handling is getting enabled after enabling the interrupt-remapping (as the success of interrupt-remapping can affect the apic mode and hence the fault handling mode). Hence there can potentially be some faults between the window of enabling interrupt-remapping in the vt-d and the fault-handling of the vt-d units. Handle any previous faults after enabling the vt-d fault handling. For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the enable_intr_remapping() and see if we can enable fault handling along with enabling intr-remapping. Signed-off-by: Suresh Siddha LKML-Reference: <20101201062244.630417138@intel.com> Acked-by: Chris Wright Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 64d19b04aeea1585b1f4808d5b962218eb607992 Author: Kenji Kaneshige Date: Tue Nov 30 22:22:28 2010 -0800 x86: Enable the intr-remap fault handling after local APIC setup commit 7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream. Interrupt-remapping gets enabled very early in the boot, as it determines the apic mode that the processor can use. And the current code enables the vt-d fault handling before the setup_local_APIC(). And hence the APIC LDR registers and data structure in the memory may not be initialized. So the vt-d fault handling in logical xapic/x2apic modes were broken. Fix this by enabling the vt-d fault handling in the end_local_APIC_setup() A cleaner fix of enabling fault handling while enabling intr-remapping will be addressed for v2.6.38. [ Enabling intr-remapping determines the usage of x2apic mode and the apic mode determines the fault-handling configuration. ] Signed-off-by: Kenji Kaneshige LKML-Reference: <20101201062244.541996375@intel.com> Signed-off-by: Suresh Siddha Acked-by: Chris Wright Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit f0d5275394231c918760612ad5ea1992b64353a0 Author: H. Peter Anvin Date: Mon Dec 13 16:01:38 2010 -0800 x86, gcc-4.6: Use gcc -m options when building vdso commit de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream. The vdso Makefile passes linker-style -m options not to the linker but to gcc. This happens to work with earlier gcc, but fails with gcc 4.6. Pass gcc-style -m options, instead. Note: all currently supported versions of gcc supports -m32, so there is no reason to conditionalize it any more. Reported-by: H. J. Lu Signed-off-by: H. Peter Anvin LKML-Reference: Signed-off-by: Greg Kroah-Hartman commit b5d59533fbb7c72bc1e87fa0a96d51d7a45e1c25 Author: Slava Pestov Date: Wed Nov 24 15:13:16 2010 -0800 tracing: Fix panic when lseek() called on "trace" opened for writing commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream. The file_ops struct for the "trace" special file defined llseek as seq_lseek(). However, if the file was opened for writing only, seq_open() was not called, and the seek would dereference a null pointer, file->private_data. This patch introduces a new wrapper for seq_lseek() which checks if the file descriptor is opened for reading first. If not, it does nothing. Signed-off-by: Slava Pestov LKML-Reference: <1290640396-24179-1-git-send-email-slavapestov@google.com> Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1aed660d993eed0586440bcee66754315a8aae01 Author: NeilBrown Date: Thu Dec 9 16:36:28 2010 +1100 md: fix bug with re-adding of partially recovered device. commit 1a855a0606653d2d82506281e2c686bacb4b2f45 upstream. With v0.90 metadata, a hot-spare does not become a full member of the array until recovery is complete. So if we re-add such a device to the array, we know that all of it is as up-to-date as the event count would suggest, and so it a bitmap-based recovery is possible. However with v1.x metadata, the hot-spare immediately becomes a full member of the array, but it record how much of the device has been recovered. If the array is stopped and re-assembled recovery starts from this point. When such a device is hot-added to an array we currently lose the 'how much is recovered' information and incorrectly included it as a full in-sync member (after bitmap-based fixup). This is wrong and unsafe and could corrupt data. So be more careful about setting saved_raid_disk - which is what guides the re-adding of devices back into an array. The new code matches the code in slot_store which does a similar thing, which is encouraging. This is suitable for any -stable kernel. Reported-by: "Dailey, Nate" Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 0c103939c31777a5ca08c418faaf1ce6e5f47479 Author: Andreas Herrmann Date: Thu Dec 16 21:29:37 2010 +0100 x86, amd: Fix panic on AMD CPU family 0x15 [The mainline kernel doesn't have this problem. Commit "(23588c3) x86, amd: Add support for CPUID topology extension of AMD CPUs" removed the family check. But 2.6.32.y needs to be fixed.] This CPU family check is not required -- existence of the NodeId MSR is indicated by a CPUID feature flag which is already checked in amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be called for newer AMD CPUs. In worst case this can lead to a panic in the scheduler code for AMD family 0x15 multi-node AMD CPUs. I just have a picture of VGA console output so I can't copy-and-paste it herein, but the call stack of such a panic looked like: do_divide_error ... find_busiest_group run_rebalance_domains ... apic_timer_interrupt ... cpu_idle The mainline kernel doesn't have this problem. Commit "(23588c3) x86, amd: Add support for CPUID topology extension of AMD CPUs" removed the family check. But 2.6.32.y needs to be fixed. Signed-off-by: Andreas Herrmann Signed-off-by: Greg Kroah-Hartman commit d5f0c1fcd3b2e22a23c51d9f64fa959b90022098 Author: David Kilroy Date: Sun Dec 5 15:45:58 2010 +0000 orinoco: clear countermeasure setting on commit commit ba34fcee476d11e7c9df95932787a22a96ff6e68 upstream. ... and interface up. In these situations, you are usually trying to connect to a new AP, so keeping TKIP countermeasures active is confusing. This is already how the driver behaves (inadvertently). However, querying SIOCGIWAUTH may tell userspace that countermeasures are active when they aren't. Clear the setting so that the reporting matches what the driver has done.. Signed-off by: David Kilroy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 005a1438d438d342b41e7aa1441c5a8e606cab8a Author: David Kilroy Date: Sun Dec 5 15:43:55 2010 +0000 orinoco: fix TKIP countermeasure behaviour commit 0a54917c3fc295cb61f3fb52373c173fd3b69f48 upstream. Enable the port when disabling countermeasures, and disable it on enabling countermeasures. This bug causes the response of the system to certain attacks to be ineffective. It also prevents wpa_supplicant from getting scan results, as wpa_supplicant disables countermeasures on startup - preventing the hardware from scanning. wpa_supplicant works with ap_mode=2 despite this bug because the commit handler re-enables the port. The log tends to look like: State: DISCONNECTED -> SCANNING Starting AP scan for wildcard SSID Scan requested (ret=0) - scan timeout 5 seconds EAPOL: disable timer tick EAPOL: Supplicant port status: Unauthorized Scan timeout - try to get results Failed to get scan results Failed to get scan results - try scanning again Setting scan request: 1 sec 0 usec Starting AP scan for wildcard SSID Scan requested (ret=-1) - scan timeout 5 seconds Failed to initiate AP scan. Reported by: Giacomo Comes Signed-off by: David Kilroy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8ac3202ab76acd2370ac49ab5232c317d93fc8e2 Author: Bob Moore Date: Sat Oct 23 01:36:40 2010 -0400 ACPICA: Fix Scope() op in module level code commit 8df3fc981dc12d9fdcaef4100a2193b605024d7a upstream. Some Panasonic Toughbooks create nodes in module level code. Module level code is the executable AML code outside of control method, for example, below AML code creates a node \_SB.PCI0.GFX0.DD02.CUBL If (\_OSI ("Windows 2006")) { Scope (\_SB.PCI0.GFX0.DD02) { Name (CUBL, Ones) ... } } Scope() op does not actually create a new object, it refers to an existing object(\_SB.PCI0.GFX0.DD02 in above example). However, for Scope(), we want to indeed open a new scope, so the child nodes(CUBL in above example) can be created correctly under it. https://bugzilla.kernel.org/show_bug.cgi?id=19462 Signed-off-by: Bob Moore Signed-off-by: Lin Ming Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 40d5940db8efa1aa65d1b5f140d6114c437e06e9 Author: Alexey Starikovskiy Date: Thu Dec 9 17:07:54 2010 -0500 ACPI: EC: Add another dmi match entry for MSI hardware commit a5dc4f898c2a0f66e2cefada6c687db82ba2fcbc upstream. http://bugzilla.kernel.org/show_bug.cgi?id=15418 Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 15b81eb89180441e82557ec77ac09f8ab6198072 Author: Takashi Iwai Date: Fri Dec 10 00:16:39 2010 +0100 PM / Hibernate: Fix PM_POST_* notification with user-space suspend commit 1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream. The user-space hibernation sends a wrong notification after the image restoration because of thinko for the file flag check. RDONLY corresponds to hibernation and WRONLY to restoration, confusingly. Signed-off-by: Takashi Iwai Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit db1aac64b2783fa1103289b48a6766afd5746eda Author: Dan Carpenter Date: Wed Oct 13 09:13:12 2010 +0000 IB/uverbs: Handle large number of entries in poll CQ commit 7182afea8d1afd432a17c18162cc3fd441d0da93 upstream. In ib_uverbs_poll_cq() code there is a potential integer overflow if userspace passes in a large cmd.ne. The calls to kmalloc() would allocate smaller buffers than intended, leading to memory corruption. There iss also an information leak if resp wasn't all used. Unprivileged userspace may call this function, although only if an RDMA device that uses this function is present. Fix this by copying CQ entries one at a time, which avoids the allocation entirely, and also by moving this copying into a function that makes sure to initialize all memory copied to userspace. Special thanks to Jason Gunthorpe for his help and advice. Signed-off-by: Dan Carpenter [ Monkey around with things a bit to avoid bad code generation by gcc when designated initializers are used. - Roland ] Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 99278605842a40e431bf2b70f71ee76a337b59da Author: Borislav Petkov Date: Mon Dec 6 16:20:25 2010 +0100 amd64_edac: Fix interleaving check commit e726f3c368e7c1919a7166ec09c5705759f1a69d upstream. When matching error address to the range contained by one memory node, we're in valid range when node interleaving 1. is disabled, or 2. enabled and when the address bits we interleave on match the interleave selector on this node (see the "Node Interleaving" section in the BKDG for an enlightening example). Thus, when we early-exit, we need to reverse the compound logic statement properly. Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 495cc545c9059a8fdcc40eeb6584cb60c7620fbb Author: Gabriele Gorla Date: Wed Dec 8 16:27:22 2010 +0100 hwmon: (adm1026) Fix setting fan_div commit 52bc9802ce849d0d287cc5fe76d06b0daa3986ca upstream. Prevent setting fan_div from stomping on other fans that share the same I2C register. Signed-off-by: Gabriele Gorla Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 37872b548dd2100728142f49421e679c51a6e85c Author: Gabriele Gorla Date: Wed Dec 8 16:27:22 2010 +0100 hwmon: (adm1026) Allow 1 as a valid divider value commit 8b0f1840a46449e1946fc88860ef3ec8d6b1c2c7 upstream. Allow 1 as a valid div value as specified in the ADM1026 datasheet. Signed-off-by: Gabriele Gorla Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 7a1c91206aa602c9fb9f52279a2dc5c150c7ec77 Author: NeilBrown Date: Tue Nov 16 16:55:19 2010 +1100 sunrpc: prevent use-after-free on clearing XPT_BUSY commit ed2849d3ecfa339435818eeff28f6c3424300cec upstream. When an xprt is created, it has a refcount of 1, and XPT_BUSY is set. The refcount is *not* owned by the thread that created the xprt (as is clear from the fact that creators never put the reference). Rather, it is owned by the absence of XPT_DEAD. Once XPT_DEAD is set, (And XPT_BUSY is clear) that initial reference is dropped and the xprt can be freed. So when a creator clears XPT_BUSY it is dropping its only reference and so must not touch the xprt again. However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY reference on a new xprt), calls svc_xprt_recieved. This clears XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference. This is dangerous and has been seen to leave svc_xprt_enqueue working with an xprt containing garbage. So we need to hold an extra counted reference over that call to svc_xprt_received. For safety, any time we clear XPT_BUSY and then use the xprt again, we first get a reference, and the put it again afterwards. Note that svc_close_all does not need this extra protection as there are no threads running, and the final free can only be called asynchronously from such a thread. Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 8ca4ba7bac89a78cc75de8b47872030bfb9faee6 Author: Sergey Vlasov Date: Sun Nov 28 21:04:05 2010 +0000 NFS: Fix fcntl F_GETLK not reporting some conflicts commit 21ac19d484a8ffb66f64487846c8d53afef04d2b upstream. The commit 129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK regression (failure to find conflicts)) fixed the posix_test_lock() function by itself, however, its usage in NFS changed by the commit 9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock same interface as ->lock) remained broken - subsequent NFS-specific locking code received F_UNLCK instead of the user-specified lock type. To fix the problem, fl->fl_type needs to be saved before the posix_test_lock() call and restored if no local conflicts were reported. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892 Tested-by: Alexander Morozov Signed-off-by: Sergey Vlasov Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8db3fab78db195b013c42fbaf9267ef0875b1b3f Author: Neil Brown Date: Thu Dec 2 11:14:30 2010 +1100 nfsd: Fix possible BUG_ON firing in set_change_info commit c1ac3ffcd0bc7e9617f62be8c7043d53ab84deac upstream. If vfs_getattr in fill_post_wcc returns an error, we don't set fh_post_change. For NFSv4, this can result in set_change_info triggering a BUG_ON. i.e. fh_post_saved being zero isn't really a bug. So: - instead of BUGging when fh_post_saved is zero, just clear ->atomic. - if vfs_getattr fails in fill_post_wcc, take a copy of i_ctime anyway. This will be used i seg_change_info, but not overly trusted. - While we are there, remove the pointless 'if' statements in set_change_info. There is no harm setting all the values. Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 253afebc6098cb7461bc1052a9fd9757250b462b Author: Chuck Lever Date: Fri Dec 10 12:31:14 2010 -0500 NFS: Fix panic after nfs_umount() commit 5b362ac3799ff4225c40935500f520cad4d7ed66 upstream. After a few unsuccessful NFS mount attempts in which the client and server cannot agree on an authentication flavor both support, the client panics. nfs_umount() is invoked in the kernel in this case. Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to write off the end of the rpc_clnt's iostat array. This is because the mount client's nrprocs field is initialized with the count of defined procedures (two: MNT and UMNT), rather than the size of the client's proc array (four). The fix is to use the same initialization technique used by most other upper layer clients in the kernel. Introduced by commit 0b524123, which failed to update nrprocs when support was added for UMNT in the kernel. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302 BugLink: http://bugs.launchpad.net/bugs/683938 Reported-by: Stefan Bader Tested-by: Stefan Bader Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e972317c844a4b2ec578e70ba3c397f0e242e9f6 Author: Heiko Carstens Date: Wed Dec 1 10:11:09 2010 +0100 nohz: Fix get_next_timer_interrupt() vs cpu hotplug commit dbd87b5af055a0cc9bba17795c9a2b0d17795389 upstream. This fixes a bug as seen on 2.6.32 based kernels where timers got enqueued on offline cpus. If a cpu goes offline it might still have pending timers. These will be migrated during CPU_DEAD handling after the cpu is offline. However while the cpu is going offline it will schedule the idle task which will then call tick_nohz_stop_sched_tick(). That function in turn will call get_next_timer_intterupt() to figure out if the tick of the cpu can be stopped or not. If it turns out that the next tick is just one jiffy off (delta_jiffies == 1) tick_nohz_stop_sched_tick() incorrectly assumes that the tick should not stop and takes an early exit and thus it won't update the load balancer cpu. Just afterwards the cpu will be killed and the load balancer cpu could be the offline cpu. On 2.6.32 based kernel get_nohz_load_balancer() gets called to decide on which cpu a timer should be enqueued (see __mod_timer()). Which leads to the possibility that timers get enqueued on an offline cpu. These will never expire and can cause a system hang. This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses get_nohz_timer_target() which doesn't have that problem. However there might be other problems because of the too early exit tick_nohz_stop_sched_tick() in case a cpu goes offline. The easiest and probably safest fix seems to be to let get_next_timer_interrupt() just lie and let it say there isn't any pending timer if the current cpu is offline. I also thought of moving migrate_[hr]timers() from CPU_DEAD to CPU_DYING, but seeing that there already have been fixes at least in the hrtimer code in this area I'm afraid that this could add new subtle bugs. Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra LKML-Reference: <20101201091109.GA8984@osiris.boeblingen.de.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8300619b701e4441950f505c32df651dff26286b Author: Heiko Carstens Date: Fri Nov 26 13:00:59 2010 +0100 nohz: Fix printk_needs_cpu() return value on offline cpus commit 61ab25447ad6334a74e32f60efb135a3467223f8 upstream. This patch fixes a hang observed with 2.6.32 kernels where timers got enqueued on offline cpus. printk_needs_cpu() may return 1 if called on offline cpus. When a cpu gets offlined it schedules the idle process which, before killing its own cpu, will call tick_nohz_stop_sched_tick(). That function in turn will call printk_needs_cpu() in order to check if the local tick can be disabled. On offline cpus this function should naturally return 0 since regardless if the tick gets disabled or not the cpu will be dead short after. That is besides the fact that __cpu_disable() should already have made sure that no interrupts on the offlined cpu will be delivered anyway. In this case it prevents tick_nohz_stop_sched_tick() to call select_nohz_load_balancer(). No idea if that really is a problem. However what made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is used within __mod_timer() to select a cpu on which a timer gets enqueued. If printk_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get updated when a cpu gets offlined. It may contain the cpu number of an offline cpu. In turn timers get enqueued on an offline cpu and not very surprisingly they never expire and cause system hangs. This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses get_nohz_timer_target() which doesn't have that problem. However there might be other problems because of the too early exit tick_nohz_stop_sched_tick() in case a cpu goes offline. Easiest way to fix this is just to test if the current cpu is offline and call printk_tick() directly which clears the condition. Alternatively I tried a cpu hotplug notifier which would clear the condition, however between calling the notifier function and printk_needs_cpu() something could have called printk() again and the problem is back again. This seems to be the safest fix. Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra LKML-Reference: <20101126120235.406766476@de.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit bb494f01fec09228682c060841f7f6033b7563f4 Author: Alex Deucher Date: Wed Dec 8 19:09:42 2010 -0500 drm/kms: remove spaces from connector names (v2) commit e76116ca9671e2e5239054a40303b94feab585ad upstream. Grub doesn't parse spaces in parameters correctly, so this makes it impossible to force video= parameters for kms on the grub kernel command line. v2: shorten the names to make them easier to type. Reported-by: Sergej Pupykin Cc: Sergej Pupykin Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6a6dbd720c976847e4cd553ae8d4520e300e7c65 Author: Daniel T Chen Date: Thu Dec 2 22:45:45 2010 -0500 ALSA: hda: Use model=lg quirk for LG P1 Express to enable playback and capture commit 77c4d5cdb81d25a45fbdfb84dd3348121219a072 upstream. BugLink: https://launchpad.net/bugs/595482 The original reporter states that audible playback from the internal speaker is inaudible despite the hardware being properly detected. To work around this symptom, he uses the model=lg quirk to properly enable both playback, capture, and jack sense. Another user corroborates this workaround on separate hardware. Add this PCI SSID to the quirk table to enable it for further LG P1 Expresses. Reported-and-tested-by: Philip Peitsch Tested-by: nikhov Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 74a6e0fd8fc216cfa5edcde4bd356a8972cbc74c Author: H. Peter Anvin Date: Fri Dec 10 23:57:04 2010 -0500 x86, hotplug: Use mwait to offline a processor, fix the legacy case upstream ea53069231f9317062910d6e772cca4ce93de8c8 x86, hotplug: Use mwait to offline a processor, fix the legacy case Here included also some small follow-on patches to the same code: upstream a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a x86, hotplug: Move WBINVD back outside the play_dead loop upstream ce5f68246bf2385d6174856708d0b746dc378f20 x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line https://bugzilla.kernel.org/show_bug.cgi?id=5471 Signed-off-by: H. Peter Anvin Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit ef93fe6db2f59649bd3ee094fcc52eb1cc0648b7 Author: Miklos Szeredi Date: Tue Nov 30 16:39:27 2010 +0100 fuse: fix ioctl when server is 32bit commit d9d318d39dd5cb686660504a3565aac453709ccc upstream. If a 32bit CUSE server is run on 64bit this results in EIO being returned to the caller. The reason is that FUSE_IOCTL_RETRY reply was defined to use 'struct iovec', which is different on 32bit and 64bit archs. Work around this by looking at the size of the reply to determine which struct was used. This is only needed if CONFIG_COMPAT is defined. A more permanent fix for the interface will be to use the same struct on both 32bit and 64bit. Reported-by: "ccmail111" Signed-off-by: Miklos Szeredi CC: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 149062eb1b3be1295f11adb5c9d7d200c3996373 Author: Miklos Szeredi Date: Tue Nov 30 16:39:27 2010 +0100 fuse: verify ioctl retries commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 upstream. Verify that the total length of the iovec returned in FUSE_IOCTL_RETRY doesn't overflow iov_length(). Signed-off-by: Miklos Szeredi CC: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 5faf7d928cf005ec7e6effa0e006b013f1ec3946 Author: Robin Holt Date: Tue Oct 26 14:21:15 2010 -0700 sgi-xp: incoming XPC channel messages can come in after the channel's partition structures have been torn down commit 09358972bff5ce99de496bbba97c85d417b3c054 upstream. Under some workloads, some channel messages have been observed being delayed on the sending side past the point where the receiving side has been able to tear down its partition structures. This condition is already detected in xpc_handle_activate_IRQ_uv(), but that information is not given to xpc_handle_activate_mq_msg_uv(). As a result, xpc_handle_activate_mq_msg_uv() assumes the structures still exist and references them, causing a NULL-pointer deref. Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d7a777500e5c2d0478bed0f5d81625ff69deea9e Author: Dan Rosenberg Date: Wed Nov 17 06:37:16 2010 +0000 rds: Integer overflow in RDS cmsg handling commit 218854af84038d828a32f061858b1902ed2beec6 upstream. In rds_cmsg_rdma_args(), the user-provided args->nr_local value is restricted to less than UINT_MAX. This seems to need a tighter upper bound, since the calculation of total iov_size can overflow, resulting in a small sock_kmalloc() allocation. This would probably just result in walking off the heap and crashing when calling rds_rdma_pages() with a high count value. If it somehow doesn't crash here, then memory corruption could occur soon after. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f33eee5d6d77e4185d8e9a7a082da1a7c200064 Author: Phil Blundell Date: Wed Nov 24 11:51:47 2010 -0800 econet: fix CVE-2010-3848 commit a27e13d370415add3487949c60810e36069a23a6 upstream. Don't declare variable sized array of iovecs on the stack since this could cause stack overflow if msg->msgiovlen is large. Instead, coalesce the user-supplied data into a new buffer and use a single iovec for it. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e2ebf28f8733a1cc3539a02e6c07e08e9eff9962 Author: Phil Blundell Date: Wed Nov 24 11:49:53 2010 -0800 econet: fix CVE-2010-3850 commit 16c41745c7b92a243d0874f534c1655196c64b74 upstream. Add missing check for capable(CAP_NET_ADMIN) in SIOCSIFADDR operation. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8db8568ebd04b53744abdb0ecdbac41a4f866523 Author: Phil Blundell Date: Wed Nov 24 11:49:19 2010 -0800 econet: disallow NULL remote addr for sendmsg(), fixes CVE-2010-3849 commit fa0e846494792e722d817b9d3d625a4ef4896c96 upstream. Later parts of econet_sendmsg() rely on saddr != NULL, so return early with EINVAL if NULL was passed otherwise an oops may occur. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3302c32ab0e6bdcc9f9b4acac8c4c3c0a2fc3f02 Author: Herbert Xu Date: Thu Nov 4 14:38:39 2010 -0400 crypto: padlock - Fix AES-CBC handling on odd-block-sized input commit c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream. On certain VIA chipsets AES-CBC requires the input/output to be a multiple of 64 bytes. We had a workaround for this but it was buggy as it sent the whole input for processing when it is meant to only send the initial number of blocks which makes the rest a multiple of 64 bytes. As expected this causes memory corruption whenever the workaround kicks in. Reported-by: Phil Sutter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9cff69da3eb80877cf7efd51c777707e7561537f Author: Dan Rosenberg Date: Fri Nov 12 12:44:42 2010 -0800 x25: Prevent crashing when parsing bad X.25 facilities commit 5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f upstream. Now with improved comma support. On parsing malformed X.25 facilities, decrementing the remaining length may cause it to underflow. Since the length is an unsigned integer, this will result in the loop continuing until the kernel crashes. This patch adds checks to ensure decrementing the remaining length does not cause it to wrap around. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b534a83f55a6c4ca6ad9e54148df9b94e1c46010 Author: Dan Rosenberg Date: Wed Sep 15 18:44:22 2010 -0300 V4L/DVB: ivtvfb: prevent reading uninitialized stack memory commit 405707985594169cfd0b1d97d29fcb4b4c6f2ac9 upstream. The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "reserved" member of the fb_vblank struct declared on the stack is not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e3485e7d76a3c1b0cab50c8a804bccc577842598 Author: Oliver Hartkopp Date: Wed Nov 10 12:10:30 2010 +0000 can-bcm: fix minor heap overflow commit 0597d1b99fcfc2c0eada09a698f85ed413d4ba84 upstream. On 64-bit platforms the ASCII representation of a pointer may be up to 17 bytes long. This patch increases the length of the buffer accordingly. http://marc.info/?l=linux-netdev&m=128872251418192&w=2 Reported-by: Dan Rosenberg Signed-off-by: Oliver Hartkopp CC: Linus Torvalds Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9b981c1f3110980ab5e0b7adb3359934621b4da7 Author: andrew hendry Date: Wed Nov 3 12:54:53 2010 +0000 memory corruption in X.25 facilities parsing commit a6331d6f9a4298173b413cf99a40cc86a9d92c37 upstream. Signed-of-by: Andrew Hendry Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 274430196e3c31e3f8a3671ac06c7cf486f8666b Author: John Hughes Date: Wed Apr 7 21:29:25 2010 -0700 x25: Patch to fix bug 15678 - x25 accesses fields beyond end of packet. commit f5eb917b861828da18dc28854308068c66d1449a upstream. Here is a patch to stop X.25 examining fields beyond the end of the packet. For example, when a simple CALL ACCEPTED was received: 10 10 0f x25_parse_facilities was attempting to decode the FACILITIES field, but this packet contains no facilities field. Signed-off-by: John Hughes Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d9de63daf855ea965bd7e8af55f22c40551835d5 Author: David S. Miller Date: Thu Oct 28 11:41:55 2010 -0700 net: Limit socket I/O iovec total length to INT_MAX. commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream. This helps protect us from overflow issues down in the individual protocol sendmsg/recvmsg handlers. Once we hit INT_MAX we truncate out the rest of the iovec by setting the iov_len members to zero. This works because: 1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial writes are allowed and the application will just continue with another write to send the rest of the data. 2) For datagram oriented sockets, where there must be a one-to-one correspondance between write() calls and packets on the wire, INT_MAX is going to be far larger than the packet size limit the protocol is going to check for and signal with -EMSGSIZE. Based upon a patch by Linus Torvalds. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 47f407ec1fa2d0b5a785ecb19dc124bdba40ca20 Author: Linus Torvalds Date: Sat Oct 30 16:43:10 2010 -0700 net: Truncate recvfrom and sendto length to INT_MAX. commit 253eacc070b114c2ec1f81b067d2fed7305467b0 upstream. Signed-off-by: Linus Torvalds Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4f098248b8f55a27598eccac90d39b94e2dc78cd Author: Kenji Kaneshige Date: Tue Nov 30 17:36:08 2010 +0900 genirq: Fix incorrect proc spurious output commit 25c9170ed64a6551beefe9315882f754e14486f4 upstream. Since commit a1afb637(switch /proc/irq/*/spurious to seq_file) all /proc/irq/XX/spurious files show the information of irq 0. Current irq_spurious_proc_open() passes on NULL as the 3rd argument, which is used as an IRQ number in irq_spurious_proc_show(), to the single_open(). Because of this, all the /proc/irq/XX/spurious file shows IRQ 0 information regardless of the IRQ number. To fix the problem, irq_spurious_proc_open() must pass on the appropreate data (IRQ number) to single_open(). Signed-off-by: Kenji Kaneshige Reviewed-by: Yong Zhang LKML-Reference: <4CF4B778.90604@jp.fujitsu.com> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8d342ebf1fddfa25fa6b5e1c6c28546addf53248 Author: Heiko Carstens Date: Wed Dec 1 10:08:01 2010 +0100 nohz/s390: fix arch_needs_cpu() return value on offline cpus commit 398812159e328478ae49b4bd01f0d71efea96c39 upstream. This fixes the same problem as described in the patch "nohz: fix printk_needs_cpu() return value on offline cpus" for the arch_needs_cpu() primitive: arch_needs_cpu() may return 1 if called on offline cpus. When a cpu gets offlined it schedules the idle process which, before killing its own cpu, will call tick_nohz_stop_sched_tick(). That function in turn will call arch_needs_cpu() in order to check if the local tick can be disabled. On offline cpus this function should naturally return 0 since regardless if the tick gets disabled or not the cpu will be dead short after. That is besides the fact that __cpu_disable() should already have made sure that no interrupts on the offlined cpu will be delivered anyway. In this case it prevents tick_nohz_stop_sched_tick() to call select_nohz_load_balancer(). No idea if that really is a problem. However what made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is used within __mod_timer() to select a cpu on which a timer gets enqueued. If arch_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get updated when a cpu gets offlined. It may contain the cpu number of an offline cpu. In turn timers get enqueued on an offline cpu and not very surprisingly they never expire and cause system hangs. This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses get_nohz_timer_target() which doesn't have that problem. However there might be other problems because of the too early exit tick_nohz_stop_sched_tick() in case a cpu goes offline. This specific bug was indrocuded with 3c5d92a0 "nohz: Introduce arch_needs_cpu". In this case a cpu hotplug notifier is used to fix the issue in order to keep the normal/fast path small. All we need to do is to clear the condition that makes arch_needs_cpu() return 1 since it is just a performance improvement which is supposed to keep the local tick running for a short period if a cpu goes idle. Nothing special needs to be done except for clearing the condition. Acked-by: Peter Zijlstra Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 971a8db01d3de4f15e6aff74012b2e68387700e3 Author: Thadeu Lima de Souza Cascardo Date: Sun Nov 28 19:46:50 2010 -0200 wmi: use memcmp instead of strncmp to compare GUIDs commit 8b14d7b22c61f17ccb869e0047d9df6dd9f50a9f upstream. While looking for the duplicates in /sys/class/wmi/, I couldn't find them. The code that looks for duplicates uses strncmp in a binary GUID, which may contain zero bytes. The right function is memcmp, which is also used in another section of wmi code. It was finding 49142400-C6A3-40FA-BADB-8A2652834100 as a duplicate of 39142400-C6A3-40FA-BADB-8A2652834100. Since the first byte is the fourth printed, they were found as equal by strncmp. Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit c72eb4d4a0239d8940b027bbe0ce3cd9a66d4635 Author: Wu Fengguang Date: Mon Aug 9 17:20:01 2010 -0700 vmscan: raise the bar to PAGEOUT_IO_SYNC stalls commit e31f3698cd3499e676f6b0ea12e3528f569c4fa3 upstream. Fix "system goes unresponsive under memory pressure and lots of dirty/writeback pages" bug. http://lkml.org/lkml/2010/4/4/86 In the above thread, Andreas Mohr described that Invoking any command locked up for minutes (note that I'm talking about attempted additional I/O to the _other_, _unaffected_ main system HDD - such as loading some shell binaries -, NOT the external SSD18M!!). This happens when the two conditions are both meet: - under memory pressure - writing heavily to a slow device OOM also happens in Andreas' system. The OOM trace shows that 3 processes are stuck in wait_on_page_writeback() in the direct reclaim path. One in do_fork() and the other two in unix_stream_sendmsg(). They are blocked on this condition: (sc->order && priority < DEF_PRIORITY - 2) which was introduced in commit 78dc583d (vmscan: low order lumpy reclaim also should use PAGEOUT_IO_SYNC) one year ago. That condition may be too permissive. In Andreas' case, 512MB/1024 = 512KB. If the direct reclaim for the order-1 fork() allocation runs into a range of 512KB hard-to-reclaim LRU pages, it will be stalled. It's a severe problem in three ways. Firstly, it can easily happen in daily desktop usage. vmscan priority can easily go below (DEF_PRIORITY - 2) on _local_ memory pressure. Even if the system has 50% globally reclaimable pages, it still has good opportunity to have 0.1% sized hard-to-reclaim ranges. For example, a simple dd can easily create a big range (up to 20%) of dirty pages in the LRU lists. And order-1 to order-3 allocations are more than common with SLUB. Try "grep -v '1 :' /proc/slabinfo" to get the list of high order slab caches. For example, the order-1 radix_tree_node slab cache may stall applications at swap-in time; the order-3 inode cache on most filesystems may stall applications when trying to read some file; the order-2 proc_inode_cache may stall applications when trying to open a /proc file. Secondly, once triggered, it will stall unrelated processes (not doing IO at all) in the system. This "one slow USB device stalls the whole system" avalanching effect is very bad. Thirdly, once stalled, the stall time could be intolerable long for the users. When there are 20MB queued writeback pages and USB 1.1 is writing them in 1MB/s, wait_on_page_writeback() will stuck for up to 20 seconds. Not to mention it may be called multiple times. So raise the bar to only enable PAGEOUT_IO_SYNC when priority goes below DEF_PRIORITY/3, or 6.25% LRU size. As the default dirty throttle ratio is 20%, it will hardly be triggered by pure dirty pages. We'd better treat PAGEOUT_IO_SYNC as some last resort workaround -- its stall time is so uncomfortably long (easily goes beyond 1s). The bar is only raised for (order < PAGE_ALLOC_COSTLY_ORDER) allocations, which are easy to satisfy in 1TB memory boxes. So, although 6.25% of memory could be an awful lot of pages to scan on a system with 1TB of memory, it won't really have to busy scan that much. Andreas tested an older version of this patch and reported that it mostly fixed his problem. Mel Gorman helped improve it and KOSAKI Motohiro will fix it further in the next patch. Reported-by: Andreas Mohr Reviewed-by: Minchan Kim Reviewed-by: KOSAKI Motohiro Signed-off-by: Mel Gorman Signed-off-by: Wu Fengguang Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit cc99a496b570408113139fcddcf1a30223357293 Author: Linus Torvalds Date: Tue Mar 2 08:36:46 2010 -0800 Prioritize synchronous signals over 'normal' signals commit a27341cd5fcb7cf2d2d4726e9f324009f7162c00 upstream. This makes sure that we pick the synchronous signals caused by a processor fault over any pending regular asynchronous signals sent to use by [t]kill(). This is not strictly required semantics, but it makes it _much_ easier for programs like Wine that expect to find the fault information in the signal stack. Without this, if a non-synchronous signal gets picked first, the delayed asynchronous signal will have its signal context pointing to the new signal invocation, rather than the instruction that caused the SIGSEGV or SIGBUS in the first place. This is not all that pretty, and we're discussing making the synchronous signals more explicit rather than have these kinds of implicit preferences of SIGSEGV and friends. See for example http://bugzilla.kernel.org/show_bug.cgi?id=15395 for some of the discussion. But in the meantime this is a simple and fairly straightforward work-around, and the whole if (x & Y) x &= Y; thing can be compiled into (and gcc does do it) just three instructions: movq %rdx, %rax andl $Y, %eax cmovne %rax, %rdx so it is at least a simple solution to a subtle issue. Reported-and-tested-by: Pavel Vilim Acked-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 171d73b2f89f57d6696d0aaf42fd5ff8ae19801f Author: Josef Bacik Date: Thu Feb 25 20:38:35 2010 +0000 Btrfs: kfree correct pointer during mount option parsing commit da495ecc0fb096b383754952a1c152147bc95b52 upstream. We kstrdup the options string, but then strsep screws with the pointer, so when we kfree() it, we're not giving it the right pointer. Tested-by: Andy Lutomirski Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 3eb88cf70fd483e2333b1954e35b355deb5e1f06 Author: KAMEZAWA Hiroyuki Date: Mon Aug 9 17:20:09 2010 -0700 mm: fix corruption of hibernation caused by reusing swap during image saving commit 966cca029f739716fbcc8068b8c6dfe381f86fc3 upstream. Since 2.6.31, swap_map[]'s refcounting was changed to show that a used swap entry is just for swap-cache, can be reused. Then, while scanning free entry in swap_map[], a swap entry may be able to be reclaimed and reused. It was caused by commit c9e444103b5e7a5 ("mm: reuse unused swap entry if necessary"). But this caused deta corruption at resume. The scenario is - Assume a clean-swap cache, but mapped. - at hibernation_snapshot[], clean-swap-cache is saved as clean-swap-cache and swap_map[] is marked as SWAP_HAS_CACHE. - then, save_image() is called. And reuse SWAP_HAS_CACHE entry to save image, and break the contents. After resume: - the memory reclaim runs and finds clean-not-referenced-swap-cache and discards it because it's marked as clean. But here, the contents on disk and swap-cache is inconsistent. Hance memory is corrupted. This patch avoids the bug by not reclaiming swap-entry during hibernation. This is a quick fix for backporting. Signed-off-by: KAMEZAWA Hiroyuki Cc: Rafael J. Wysocki Reported-by: Ondreg Zary Tested-by: Ondreg Zary Tested-by: Andrea Gelmini Acked-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b87c9ea0ff8b0f8e7ff538e1d47a20933b229403 Author: Nikanth Karthikesan Date: Sun May 16 14:00:00 2010 -0400 ext4: Prevent creation of files larger than RLIMIT_FSIZE using fallocate commit 6d19c42b7cf81c39632b6d4dbc514e8449bcd346 upstream. Currently using posix_fallocate one can bypass an RLIMIT_FSIZE limit and create a file larger than the limit. Add a check for that. Signed-off-by: Nikanth Karthikesan Signed-off-by: Amit Arora Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 110e9fc4b1c8096f7805c6c3e9e20b55a4aaffc7 Author: H. Peter Anvin Date: Tue Sep 7 16:16:18 2010 -0700 compat: Make compat_alloc_user_space() incorporate the access_ok() commit c41d68a513c71e35a14f66d71782d27a79a81ea6 upstream. compat_alloc_user_space() expects the caller to independently call access_ok() to verify the returned area. A missing call could introduce problems on some architectures. This patch incorporates the access_ok() check into compat_alloc_user_space() and also adds a sanity check on the length. The existing compat_alloc_user_space() implementations are renamed arch_compat_alloc_user_space() and are used as part of the implementation of the new global function. This patch assumes NULL will cause __get_user()/__put_user() to either fail or access userspace on all architectures. This should be followed by checking the return value of compat_access_user_space() for NULL in the callers, at which time the access_ok() in the callers can also be removed. Reported-by: Ben Hawkes Signed-off-by: H. Peter Anvin Acked-by: Benjamin Herrenschmidt Acked-by: Chris Metcalf Acked-by: David S. Miller Acked-by: Ingo Molnar Acked-by: Thomas Gleixner Acked-by: Tony Luck Cc: Andrew Morton Cc: Arnd Bergmann Cc: Fenghua Yu Cc: H. Peter Anvin Cc: Heiko Carstens Cc: Helge Deller Cc: James Bottomley Cc: Kyle McMartin Cc: Martin Schwidefsky Cc: Paul Mackerras Cc: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit b5bf2cfbfbecb8b4d0369c637569283d05d85cf5 Author: Roland McGrath Date: Tue Sep 14 12:22:58 2010 -0700 x86-64, compat: Retruncate rax after ia32 syscall entry tracing commit eefdca043e8391dcd719711716492063030b55ac upstream. In commit d4d6715, we reopened an old hole for a 64-bit ptracer touching a 32-bit tracee in system call entry. A %rax value set via ptrace at the entry tracing stop gets used whole as a 32-bit syscall number, while we only check the low 32 bits for validity. Fix it by truncating %rax back to 32 bits after syscall_trace_enter, in addition to testing the full 64 bits as has already been added. Reported-by: Ben Hawkes Signed-off-by: Roland McGrath Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 86869f15548105de95cfbf51b240b37a8e1bf35d Author: H. Peter Anvin Date: Tue Sep 14 12:42:41 2010 -0700 x86-64, compat: Test %rax for the syscall number, not %eax commit 36d001c70d8a0144ac1d038f6876c484849a74de upstream. On 64 bits, we always, by necessity, jump through the system call table via %rax. For 32-bit system calls, in theory the system call number is stored in %eax, and the code was testing %eax for a valid system call number. At one point we loaded the stored value back from the stack to enforce zero-extension, but that was removed in checkin d4d67150165df8bf1cc05e532f6efca96f907cab. An actual 32-bit process will not be able to introduce a non-zero-extended number, but it can happen via ptrace. Instead of re-introducing the zero-extension, test what we are actually going to use, i.e. %rax. This only adds a handful of REX prefixes to the code. Reported-by: Ben Hawkes Signed-off-by: H. Peter Anvin Cc: Roland McGrath Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d4c7414aa43c3c71245d33bb976c92af727240f4 Author: Akinobu Mita Date: Wed Mar 3 23:55:01 2010 -0500 ext4: consolidate in_range() definitions commit 731eb1a03a8445cde2cb23ecfb3580c6fa7bb690 upstream. There are duplicate macro definitions of in_range() in mballoc.h and balloc.c. This consolidates these two definitions into ext4.h, and changes extents.c to use in_range() as well. Signed-off-by: Akinobu Mita Signed-off-by: "Theodore Ts'o" Cc: Andreas Dilger Signed-off-by: Greg Kroah-Hartman commit 83647d51540c560bd6da6b2b14452a2c231b4ff7 Author: Linus Torvalds Date: Sun Aug 15 11:35:52 2010 -0700 mm: fix up some user-visible effects of the stack guard page commit d7824370e26325c881b665350ce64fb0a4fde24a upstream. This commit makes the stack guard page somewhat less visible to user space. It does this by: - not showing the guard page in /proc//maps It looks like lvm-tools will actually read /proc/self/maps to figure out where all its mappings are, and effectively do a specialized "mlockall()" in user space. By not showing the guard page as part of the mapping (by just adding PAGE_SIZE to the start for grows-up pages), lvm-tools ends up not being aware of it. - by also teaching the _real_ mlock() functionality not to try to lock the guard page. That would just expand the mapping down to create a new guard page, so there really is no point in trying to lock it in place. It would perhaps be nice to show the guard page specially in /proc//maps (or at least mark grow-down segments some way), but let's not open ourselves up to more breakage by user space from programs that depends on the exact deails of the 'maps' file. Special thanks to Henrique de Moraes Holschuh for diving into lvm-tools source code to see what was going on with the whole new warning. Reported-and-tested-by: François Valenduc Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8310ff66adec21334f83d7169f9453cae796e401 Author: Linus Torvalds Date: Sat Aug 14 11:44:56 2010 -0700 mm: fix page table unmap for stack guard page properly commit 11ac552477e32835cb6970bf0a70c210807f5673 upstream. We do in fact need to unmap the page table _before_ doing the whole stack guard page logic, because if it is needed (mainly 32-bit x86 with PAE and CONFIG_HIGHPTE, but other architectures may use it too) then it will do a kmap_atomic/kunmap_atomic. And those kmaps will create an atomic region that we cannot do allocations in. However, the whole stack expand code will need to do anon_vma_prepare() and vma_lock_anon_vma() and they cannot do that in an atomic region. Now, a better model might actually be to do the anon_vma_prepare() when _creating_ a VM_GROWSDOWN segment, and not have to worry about any of this at page fault time. But in the meantime, this is the straightforward fix for the issue. See https://bugzilla.kernel.org/show_bug.cgi?id=16588 for details. Reported-by: Wylda Reported-by: Sedat Dilek Reported-by: Mike Pagano Reported-by: François Valenduc Tested-by: Ed Tomlinson Cc: Pekka Enberg Cc: Greg KH Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c8fe7a0e856eda82e595618a6ebe020a82df0adc Author: Linus Torvalds Date: Fri Aug 13 09:24:04 2010 -0700 mm: fix missing page table unmap for stack guard page failure case commit 5528f9132cf65d4d892bcbc5684c61e7822b21e9 upstream. .. which didn't show up in my tests because it's a no-op on x86-64 and most other architectures. But we enter the function with the last-level page table mapped, and should unmap it at exit. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 96a82b14baf22492429323e4ce3ea739ec52b1ca Author: Linus Torvalds Date: Thu Aug 12 17:54:33 2010 -0700 mm: keep a guard page below a grow-down stack segment commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream. This is a rather minimally invasive patch to solve the problem of the user stack growing into a memory mapped area below it. Whenever we fill the first page of the stack segment, expand the segment down by one page. Now, admittedly some odd application might _want_ the stack to grow down into the preceding memory mapping, and so we may at some point need to make this a process tunable (some people might also want to have more than a single page of guarding), but let's try the minimal approach first. Tested with trivial application that maps a single page just below the stack, and then starts recursing. Without this, we will get a SIGSEGV _after_ the stack has smashed the mapping. With this patch, we'll get a nice SIGBUS just as the stack touches the page just above the mapping. Requested-by: Keith Packard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 86e2f6345053ce66ab9a4b735f3029d445eaed70 Author: Larry Finger Date: Sat Nov 13 13:01:56 2010 -0600 staging: rtl8187se: Change panic to warn when RF switch turned off commit f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream. This driver issues a kernel panic over conditions that do not justify such drastic action. Change these to log entries with a stack dump. This patch fixes the system crash reported in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285. Signed-off-by: Larry Finger Reported-and-Tested-by: Robie Basik Signed-off-by: Greg Kroah-Hartman commit 0c8089f2405e9b6876d4a767cecc9d804d9bb843 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:18:33 2010 -0800 Staging: frontier: fix up some sysfs attribute permissions commit 3bad28ec006ad6ab2bca4e5103860b75391e3c9d and 2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream merged together. They should not be writable by any user Reported-by: Linus Torvalds Cc: David Taht Signed-off-by: Greg Kroah-Hartman commit 6acee6aa3ecac4d1beb3ff3b63c77e42be236508 Author: Greg Kroah-Hartman Date: Thu Nov 18 11:21:04 2010 -0800 Staging: samsung-laptop: fix up my fixup for some sysfs attribute permissions commit 4d7bc388b44e42a1feafa35e50eef4f24d6ca59d upstream. They should be writable by root, not readable. Doh, stupid me with the wrong flags. Reported-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2ce8da7202e4f2e8c26626a7a18dc4ffda8ab189 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:21:03 2010 -0800 Staging: samsung-laptop: fix up some sysfs attribute permissions commit 90c05b97fdec8d2196e420d98f774bab731af7aa upstream. They should not be writable by any user Reported-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d9362bc3dd2f35992c07b7088a32f51d65fc6c01 Author: Eric Dumazet Date: Wed Sep 8 05:08:44 2010 +0000 udp: add rehash on connect() commit 719f835853a92f6090258114a72ffe41f09155cd upstream. commit 30fff923 introduced in linux-2.6.33 (udp: bind() optimisation) added a secondary hash on UDP, hashed on (local addr, local port). Problem is that following sequence : fd = socket(...) connect(fd, &remote, ...) not only selects remote end point (address and port), but also sets local address, while UDP stack stored in secondary hash table the socket while its local address was INADDR_ANY (or ipv6 equivalent) Sequence is : - autobind() : choose a random local port, insert socket in hash tables [while local address is INADDR_ANY] - connect() : set remote address and port, change local address to IP given by a route lookup. When an incoming UDP frame comes, if more than 10 sockets are found in primary hash table, we switch to secondary table, and fail to find socket because its local address changed. One solution to this problem is to rehash datagram socket if needed. We add a new rehash(struct socket *) method in "struct proto", and implement this method for UDP v4 & v6, using a common helper. This rehashing only takes care of secondary hash table, since primary hash (based on local port only) is not changed. Reported-by: Krzysztof Piotr Oledzki Signed-off-by: Eric Dumazet Tested-by: Krzysztof Piotr Oledzki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 179b606f56b25889f66845da8aa965c9bd495dde Author: Steven Rostedt Date: Wed Nov 24 12:56:52 2010 -0800 leds: fix bug with reading NAS SS4200 dmi code commit 50d431e8a15701b599c98afe2b464eb33c952477 upstream. While running randconfg with ktest.pl I stumbled upon this bug: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003 IP: [] strstr+0x39/0x86 PGD 0 Oops: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.37-rc1-test+ #6 DG965MQ/ RIP: 0010:[] [] strstr+0x39/0x86 RSP: 0018:ffff8800797cbd80 EFLAGS: 00010213 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffffffffffff RDX: 0000000000000000 RSI: ffffffff82eb7ac9 RDI: 0000000000000003 RBP: ffff8800797cbda0 R08: ffff880000000003 R09: 0000000000030725 R10: ffff88007d294c00 R11: 0000000000014c00 R12: 0000000000000020 R13: ffffffff82eb7ac9 R14: ffffffffffffffff R15: ffffffff82eb7b08 FS: 0000000000000000(0000) GS:ffff88007d200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000003 CR3: 0000000002a1d000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff8800797ca000, task ffff8800797d0000) Stack: 00000000000000ba ffffffff82eb7ac9 ffffffff82eb7ab8 00000000000000ba ffff8800797cbdf0 ffffffff81e2050f ffff8800797cbdc0 00000000815f913b ffff8800797cbe00 ffffffff82eb7ab8 0000000000000000 0000000000000000 Call Trace: [] dmi_matches+0x117/0x154 [] dmi_check_system+0x3d/0x8d [] ? nas_gpio_init+0x0/0x2c8 [] nas_gpio_init+0x24/0x2c8 [] ? wm8350_led_init+0x0/0x20 [] ? nas_gpio_init+0x0/0x2c8 [] do_one_initcall+0xab/0x1b2 [] kernel_init+0x248/0x331 [] kernel_thread_helper+0x4/0x10 [] ? kernel_init+0x0/0x331 Found that the nas_led_whitelist dmi_system_id structure array had no NULL end delimiter, causing the dmi_check_system() loop to read an undefined entry. Signed-off-by: Steven Rostedt Acked-by: Dave Hansen Acked-by: Richard Purdie Acked-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f20378d48a50593755e94f157f55d058f2f92202 Author: James Jones Date: Wed Nov 24 00:21:37 2010 +0100 ARM: 6482/2: Fix find_next_zero_bit and related assembly commit 0e91ec0c06d2cd15071a6021c94840a50e6671aa upstream. The find_next_bit, find_first_bit, find_next_zero_bit and find_first_zero_bit functions were not properly clamping to the maxbit argument at the bit level. They were instead only checking maxbit at the byte level. To fix this, add a compare and a conditional move instruction to the end of the common bit-within-the- byte code used by all the functions and be sure not to clobber the maxbit argument before it is used. Reviewed-by: Nicolas Pitre Tested-by: Stephen Warren Signed-off-by: James Jones Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit bcaefff16de46a7ca217e71f95de384786ebb4d5 Author: Will Deacon Date: Fri Nov 19 13:18:31 2010 +0100 ARM: 6489/1: thumb2: fix incorrect optimisation in usracc commit 1142b71d85894dcff1466dd6c871ea3c89e0352c upstream. Commit 8b592783 added a Thumb-2 variant of usracc which, when it is called with \rept=2, calls usraccoff once with an offset of 0 and secondly with a hard-coded offset of 4 in order to avoid incrementing the pointer again. If \inc != 4 then we will store the data to the wrong offset from \ptr. Luckily, the only caller that passes \rept=2 to this function is __clear_user so we haven't been actively corrupting user data. This patch fixes usracc to pass \inc instead of #4 to usraccoff when it is called a second time. Reported-by: Tony Thompson Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 3a27414883e624fdfc62b747a19f106448fb62ca Author: Pekka Enberg Date: Mon Nov 8 21:29:07 2010 +0200 perf_events: Fix perf_counter_mmap() hook in mprotect() commit 63bfd7384b119409685a17d5c58f0b56e5dc03da upstream. As pointed out by Linus, commit dab5855 ("perf_counter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to merging. Fix the problem by moving perf_event_mmap() hook to mprotect_fixup(). Note: there's another successful return path from mprotect_fixup() if old flags equal to new flags. We don't, however, need to call perf_event_mmap() there because 'perf' already knows the VMA is executable. Reported-by: Dave Jones Analyzed-by: Linus Torvalds Cc: Ingo Molnar Reviewed-by: Peter Zijlstra Signed-off-by: Pekka Enberg Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 61280b33e84e7d940b1dd978e6e401eca98fc64f Author: Dan Rosenberg Date: Tue Nov 23 11:02:13 2010 +0000 DECnet: don't leak uninitialized stack byte commit 3c6f27bf33052ea6ba9d82369fb460726fb779c0 upstream. A single uninitialized padding byte is leaked to userspace. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 528b8cc1bea342b6cf56b20449ebc89eae3e107b Author: Frederic Weisbecker Date: Thu Nov 11 21:18:43 2010 +0100 x86: Ignore trap bits on single step exceptions commit 6c0aca288e726405b01dacb12cac556454d34b2a upstream. When a single step exception fires, the trap bits, used to signal hardware breakpoints, are in a random state. These trap bits might be set if another exception will follow, like a breakpoint in the next instruction, or a watchpoint in the previous one. Or there can be any junk there. So if we handle these trap bits during the single step exception, we are going to handle an exception twice, or we are going to handle junk. Just ignore them in this case. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=21332 Reported-by: Michael Stefaniuc Signed-off-by: Frederic Weisbecker Cc: Rafael J. Wysocki Cc: Maciej Rutecki Cc: Alexandre Julliard Cc: Jason Wessel Signed-off-by: Greg Kroah-Hartman commit 5b10d682e08cb68b9d4581057f4719fe53da6245 Author: Steven J. Magnani Date: Wed Nov 24 12:56:54 2010 -0800 nommu: yield CPU while disposing VM commit 04c3496152394d17e3bc2316f9731ee3e8a026bc upstream. Depending on processor speed, page size, and the amount of memory a process is allowed to amass, cleanup of a large VM may freeze the system for many seconds. This can result in a watchdog timeout. Make sure other tasks receive some service when cleaning up large VMs. Signed-off-by: Steven J. Magnani Cc: Greg Ungerer Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5c1cd3ddd72f5ccd5f40e9e176a9cd69b8fd9506 Author: Uwe Kleine-König Date: Wed Nov 24 12:57:14 2010 -0800 backlight: grab ops_lock before testing bd->ops commit d1d73578e053b981c3611e5a211534290d24a5eb upstream. According to the comment describing ops_lock in the definition of struct backlight_device and when comparing with other functions in backlight.c the mutex must be hold when checking ops to be non-NULL. Fixes a problem added by c835ee7f4154992e6 ("backlight: Add suspend/resume support to the backlight core") in Jan 2009. Signed-off-by: Uwe Kleine-König Acked-by: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 787ee53f0f1c0d9ac1a2023bd813e1c796d1e200 Author: Nelson Elhage Date: Thu Dec 2 14:31:21 2010 -0800 do_exit(): make sure that we run with get_fs() == USER_DS commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 upstream. If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not otherwise reset before do_exit(). do_exit may later (via mm_release in fork.c) do a put_user to a user-controlled address, potentially allowing a user to leverage an oops into a controlled write into kernel memory. This is only triggerable in the presence of another bug, but this potentially turns a lot of DoS bugs into privilege escalations, so it's worth fixing. I have proof-of-concept code which uses this bug along with CVE-2010-3849 to write a zero to an arbitrary kernel address, so I've tested that this is not theoretical. A more logical place to put this fix might be when we know an oops has occurred, before we call do_exit(), but that would involve changing every architecture, in multiple places. Let's just stick it in do_exit instead. [akpm@linux-foundation.org: update code comment] Signed-off-by: Nelson Elhage Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a60d4074da9aa368a668d53c17fb1033a8a256fe Author: Ken Sumrall Date: Wed Nov 24 12:57:00 2010 -0800 fuse: fix attributes after open(O_TRUNC) commit a0822c55779d9319939eac69f00bb729ea9d23da upstream. The attribute cache for a file was not being cleared when a file is opened with O_TRUNC. If the filesystem's open operation truncates the file ("atomic_o_trunc" feature flag is set) then the kernel should invalidate the cached st_mtime and st_ctime attributes. Also i_size should be explicitly be set to zero as it is used sometimes without refreshing the cache. Signed-off-by: Ken Sumrall Cc: Anfei Cc: "Anand V. Avati" Signed-off-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit eef5b035840ebdcdaa6ed18591c8e9e9cebb668c Author: Zhang Rui Date: Tue Oct 12 09:09:37 2010 +0800 acpi-cpufreq: fix a memleak when unloading driver commit dab5fff14df2cd16eb1ad4c02e83915e1063fece upstream. We didn't free per_cpu(acfreq_data, cpu)->freq_table when acpi_freq driver is unloaded. Resulting in the following messages in /sys/kernel/debug/kmemleak: unreferenced object 0xf6450e80 (size 64): comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s) hex dump (first 32 bytes): 00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$. 02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5.. backtrace: [] kmemleak_alloc+0x27/0x50 [] __kmalloc+0xcf/0x110 [] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq] [] cpufreq_add_dev+0x142/0x3a0 [] sysdev_driver_register+0x97/0x110 [] cpufreq_register_driver+0x86/0x140 [] 0xf9dad080 [] do_one_initcall+0x30/0x160 [] sys_init_module+0x99/0x1e0 [] sysenter_do_call+0x12/0x26 [] 0xffffffff https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21 Tested-by: Toralf Forster Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit a7cfab492b5912fe64e170693f402ad35cc06ed2 Author: Jacques Viviers Date: Wed Nov 24 11:56:38 2010 +0200 USB: serial: ftdi_sio: Vardaan USB RS422/485 converter PID added commit 6fdbad8021151a9e93af8159a6232c8f26415c09 upstream. Add the PID for the Vardaan Enterprises VEUSB422R3 USB to RS422/485 converter. It uses the same chip as the FTDI_8U232AM_PID 0x6001. This should also work with the stable branches for: 2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36 Signed-off-by: Jacques Viviers Signed-off-by: Greg Kroah-Hartman commit 319170a8f2e3b23729456e226227053031c65fd7 Author: Michael Stuermer Date: Thu Nov 18 00:45:43 2010 +0100 USB: ftdi_sio: Add ID for RT Systems USB-29B radio cable commit 28942bb6a9dd4e2ed793675e515cfb8297ed355b upstream. Another variant of the RT Systems programming cable for ham radios. Signed-off-by: Michael Stuermer Signed-off-by: Greg Kroah-Hartman commit aa8bdc8721d399c32f26a597578c5bb777123511 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:36:44 2010 -0800 USB: misc: usbsevseg: fix up some sysfs attribute permissions commit e24d7ace4e822debcb78386bf279c9aba4d7fbd1 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Cc: Harrison Metzger Signed-off-by: Greg Kroah-Hartman commit f1f0a2db03038ad5eeae8e47b3aea030ac62ce17 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:34:26 2010 -0800 USB: misc: trancevibrator: fix up a sysfs attribute permission commit d489a4b3926bad571d404ca6508f6744b9602776 upstream. It should not be writable by any user. Reported-by: Linus Torvalds Cc: Sam Hocevar Signed-off-by: Greg Kroah-Hartman commit 3b63c721e4bb4d869cb623e8f24e053ecf05418e Author: Johan Hovold Date: Sun Sep 12 16:31:45 2010 +0200 USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes" commit 677aeafe19e88c282af74564048243ccabb1c590 upstream. This reverts commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd. RTS and DTR should not be modified based on CRTSCTS when calling set_termios. Modem control lines are raised at port open by the tty layer and should stay raised regardless of whether hardware flow control is enabled or not. This is in conformance with the way serial ports work today and many applications depend on this behaviour to be able to talk to hardware implementing hardware flow control (without the applications actually using it). Hardware which expects different behaviour on these lines can always use TIOCMSET/TIOCMBI[SC] after port open to change them. Reported-by: Daniel Mack Reported-by: Dave Mielke Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 967e5c6eb86a2ac562a62e142d36cdad451d36b0 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:35:49 2010 -0800 USB: misc: usbled: fix up some sysfs attribute permissions commit 48f115470e68d443436b76b22dad63ffbffd6b97 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a154f54e15663e700edafbf953fecb01b8ca7765 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:32:38 2010 -0800 USB: misc: cypress_cy7c63: fix up some sysfs attribute permissions commit c990600d340641150f7270470a64bd99a5c0b225 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Cc: Oliver Bock Signed-off-by: Greg Kroah-Hartman commit 92ff7352975cc5e700e853a8eec15a328a46267f Author: Greg Kroah-Hartman Date: Mon Nov 15 11:11:45 2010 -0800 USB: atm: ueagle-atm: fix up some permissions on the sysfs files commit e502ac5e1eca99d7dc3f12b2a6780ccbca674858 upstream. Some of the sysfs files had the incorrect permissions. Some didn't make sense at all (writable for a file that you could not write to?) Reported-by: Linus Torvalds Cc: Matthieu Castet Cc: Stanislaw Gruszka Cc: Damien Bergamini Signed-off-by: Greg Kroah-Hartman commit 6d8870840bf5289d11b3d131ccc1ab0cdb5ff83e Author: Greg Kroah-Hartman Date: Mon Nov 15 11:17:52 2010 -0800 USB: storage: sierra_ms: fix sysfs file attribute commit d9624e75f6ad94d8a0718c1fafa89186d271a78c upstream. A non-writable sysfs file shouldn't have writable attributes. Reported-by: Linus Torvalds Cc: Kevin Lloyd Cc: Matthew Dharm Signed-off-by: Greg Kroah-Hartman commit 5ae53c3f9f290b391063046414e297af58aa7817 Author: Alan Stern Date: Tue Nov 16 10:57:37 2010 -0500 USB: EHCI: fix obscure race in ehci_endpoint_disable commit 02e2c51ba3e80acde600721ea784c3ef84da5ea1 upstream. This patch (as1435) fixes an obscure and unlikely race in ehci-hcd. When an async URB is unlinked, the corresponding QH is removed from the async list. If the QH's endpoint is then disabled while the URB is being given back, ehci_endpoint_disable() won't find the QH on the async list, causing it to believe that the QH has been lost. This will lead to a memory leak at best and quite possibly to an oops. The solution is to trust usbcore not to lose track of endpoints. If the QH isn't on the async list then it doesn't need to be taken off the list, but the driver should still wait for the QH to become IDLE before disabling it. In theory this fixes Bugzilla #20182. In fact the race is so rare that it's not possible to tell whether the bug is still present. However, adding delays and making other changes to force the race seems to show that the patch works. Signed-off-by: Alan Stern Reported-by: Stefan Richter CC: David Brownell Signed-off-by: Greg Kroah-Hartman commit 458b0b08eff05179b09855eb36aa39a065b17d32 Author: John Tapsell Date: Thu Mar 25 13:30:45 2010 +0000 Staging: rt2870: Add USB ID for Buffalo Airstation WLI-UC-GN commit 251d380034c6c34efe75ffb89d863558ba68ec6a upstream. BugLink: http://bugs.launchpad.net/bugs/441990 This was tested to successfully enable the hardware. Signed-off-by: John Tapsell Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman commit 9f34fd7e76428bdd07f4ad10320b06f53b0b6ab2 Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:28 2010 +0300 usb: core: fix information leak to userland commit 886ccd4520064408ce5876cfe00554ce52ecf4a7 upstream. Structure usbdevfs_connectinfo is copied to userland with padding byted after "slow" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman commit d66dbddd744d6bd67258bbc89dc01b4704374ff2 Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:31 2010 +0300 usb: misc: iowarrior: fix information leak to userland commit eca67aaeebd6e5d22b0d991af1dd0424dc703bfb upstream. Structure iowarrior_info is copied to userland with padding byted between "serial" and "revision" fields uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Acked-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 0bd0e38c333e5bb69921ece2ba1d9c3e2d237b42 Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:35 2010 +0300 usb: misc: sisusbvga: fix information leak to userland commit 5dc92cf1d0b4b0debbd2e333b83f9746c103533d upstream. Structure sisusb_info is copied to userland with "sisusb_reserved" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman commit 2516ccd05a94fc8298bb71d72aaacc1c5f820f2f Author: ma rui Date: Mon Nov 1 11:32:18 2010 +0800 USB: option: fix when the driver is loaded incorrectly for some Huawei devices. commit 58c0d9d70109bd7e82bdb9517007311a48499960 upstream. When huawei datacard with PID 0x14AC is insterted into Linux system, the present kernel will load the "option" driver to all the interfaces. But actually, some interfaces run as other function and do not need "option" driver. In this path, we modify the id_tables, when the PID is 0x14ac ,VID is 0x12d1, Only when the interface's Class is 0xff,Subclass is 0xff, Pro is 0xff, it does need "option" driver. Signed-off-by: ma rui Signed-off-by: Greg Kroah-Hartman commit b4a4132d624d2ca0498f51597a82a167f3efd598 Author: Peter Jones Date: Wed Sep 22 13:05:04 2010 -0700 efifb: check that the base address is plausible on pci systems commit 85a00d9bbfb4704fbf368944b1cb9fed8f1598c5 upstream. Some Apple machines have identical DMI data but different memory configurations for the video. Given that, check that the address in our table is actually within the range of a PCI BAR on a VGA device in the machine. This also fixes up the return value from set_system(), which has always been wrong, but never resulted in bad behavior since there's only ever been one matching entry in the dmi table. The patch 1) stops people's machines from crashing when we get their display wrong, which seems to be unfortunately inevitable, 2) allows us to support identical dmi data with differing video memory configurations This also adds me as the efifb maintainer, since I've effectively been acting as such for quite some time. Signed-off-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 574f1725a7bda106e8eee1f979c49697feb42d20 Author: Darrick J. Wong Date: Tue Nov 16 09:13:41 2010 -0800 PCI: fix offset check for sysfs mmapped files commit 8c05cd08a7504b855c265263e84af61aabafa329 upstream. I just loaded 2.6.37-rc2 on my machines, and I noticed that X no longer starts. Running an strace of the X server shows that it's doing this: open("/sys/bus/pci/devices/0000:07:00.0/resource0", O_RDWR) = 10 mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 EINVAL (Invalid argument) This code seems to be asking for a shared read/write mapping of 16MB worth of BAR0 starting at file offset 0, and letting the kernel assign a starting address. Unfortunately, this -EINVAL causes X not to start. Looking into dmesg, there's a complaint like so: process "Xorg" tried to map 0x01000000 bytes at page 0x00000000 on 0000:07:00.0 BAR 0 (start 0x 96000000, size 0x 1000000) ...with the following code in pci_mmap_fits: pci_start = (mmap_api == PCI_MMAP_SYSFS) ? pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; if (start >= pci_start && start < pci_start + size && start + nr <= pci_start + size) It looks like the logic here is set up such that when the mmap call comes via sysfs, the check in pci_mmap_fits wants vma->vm_pgoff to be between the resource's start and end address, and the end of the vma to be no farther than the end. However, the sysfs PCI resource files always start at offset zero, which means that this test always fails for programs that mmap the sysfs files. Given the comment in the original commit 3b519e4ea618b6943a82931630872907f9ac2c2b, I _think_ the old procfs files require that the file offset be equal to the resource's base address when mmapping. I think what we want here is for pci_start to be 0 when mmap_api == PCI_MMAP_PROCFS. The following patch makes that change, after which the Matrox and Mach64 X drivers work again. Acked-by: Martin Wilck Signed-off-by: Darrick J. Wong Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit db75b7e8269de3dd6768e55625f3139785fba3a8 Author: Martin Wilck Date: Wed Nov 10 11:03:21 2010 +0100 PCI: fix size checks for mmap() on /proc/bus/pci files commit 3b519e4ea618b6943a82931630872907f9ac2c2b upstream. The checks for valid mmaps of PCI resources made through /proc/bus/pci files that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several problems: 1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0, whereas under /sys/bus/pci/devices, the start of the resource corresponds to offset 0. This may lead to false negatives in pci_mmap_fits(), which implicitly assumes the /sys/bus/pci/devices layout. 2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads to false positives, because pci_mmap_fits() doesn't treat empty resources correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT) in this case!). 3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus WARNINGS for the first resources that don't fit until the correct one is found. On many controllers the first 2-4 BARs are used, and the others are empty. In this case, an mmap attempt will first fail on the non-empty BARs (including the "right" BAR because of 1.) and emit bogus WARNINGS because of 3., and finally succeed on the first empty BAR because of 2. This is certainly not the intended behaviour. This patch addresses all 3 issues. Updated with an enum type for the additional parameter for pci_mmap_fits(). Signed-off-by: Martin Wilck Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit decc61d9f1f97a1f35e1ba69be343f9c4274bd52 Author: Tejun Heo Date: Mon Nov 1 11:39:19 2010 +0100 libata: fix NULL sdev dereference race in atapi_qc_complete() commit 2a5f07b5ec098edc69e05fdd2f35d3fbb1235723 upstream. SCSI commands may be issued between __scsi_add_device() and dev->sdev assignment, so it's unsafe for ata_qc_complete() to dereference dev->sdev->locked without checking whether it's NULL or not. Fix it. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit fa63cf8d7fda913e5c473219ed4027ccf6d1d727 Author: Francisco Jerez Date: Tue Sep 21 02:15:15 2010 +0200 drm/ttm: Clear the ghost cpu_writers flag on ttm_buffer_object_transfer. commit 0fbecd400dd0a82d465b3086f209681e8c54cb0f upstream. It makes sense for a BO to move after a process has requested exclusive RW access on it (e.g. because the BO used to be located in unmappable VRAM and we intercepted the CPU access from the fault handler). If we let the ghost object inherit cpu_writers from the original object, ttm_bo_release_list() will raise a kernel BUG when the ghost object is destroyed. This can be reproduced with the nouveau driver on nv5x. Reported-by: Marcin Slusarz Reviewed-by: Jerome Glisse Tested-by: Marcin Slusarz Signed-off-by: Francisco Jerez Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e04e0db0e3c8fe2aafc618c1dd1bd1357e14be58 Author: Jens Axboe Date: Wed Nov 10 14:36:25 2010 +0100 bio: take care not overflow page count when mapping/copying user data commit cb4644cac4a2797afc847e6c92736664d4b0ea34 upstream. If the iovec is being set up in a way that causes uaddr + PAGE_SIZE to overflow, we could end up attempting to map a huge number of pages. Check for this invalid input type. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 459af1da6108bd3cc9dcee2df7399b7659f95426 Author: Dave Hansen Date: Thu Nov 11 14:05:15 2010 -0800 mm/vfs: revalidate page->mapping in do_generic_file_read() commit 8d056cb965b8fb7c53c564abf28b1962d1061cd3 upstream. 70 hours into some stress tests of a 2.6.32-based enterprise kernel, we ran into a NULL dereference in here: int block_is_partially_uptodate(struct page *page, read_descriptor_t *desc, unsigned long from) { ----> struct inode *inode = page->mapping->host; It looks like page->mapping was the culprit. (xmon trace is below). After closer examination, I realized that do_generic_file_read() does a find_get_page(), and eventually locks the page before calling block_is_partially_uptodate(). However, it doesn't revalidate the page->mapping after the page is locked. So, there's a small window between the find_get_page() and ->is_partially_uptodate() where the page could get truncated and page->mapping cleared. We _have_ a reference, so it can't get reclaimed, but it certainly can be truncated. I think the correct thing is to check page->mapping after the trylock_page(), and jump out if it got truncated. This patch has been running in the test environment for a month or so now, and we have not seen this bug pop up again. xmon info: 1f:mon> e cpu 0x1f: Vector: 300 (Data Access) at [c0000002ae36f770] pc: c0000000001e7a6c: .block_is_partially_uptodate+0xc/0x100 lr: c000000000142944: .generic_file_aio_read+0x1e4/0x770 sp: c0000002ae36f9f0 msr: 8000000000009032 dar: 0 dsisr: 40000000 current = 0xc000000378f99e30 paca = 0xc000000000f66300 pid = 21946, comm = bash 1f:mon> r R00 = 0025c0500000006d R16 = 0000000000000000 R01 = c0000002ae36f9f0 R17 = c000000362cd3af0 R02 = c000000000e8cd80 R18 = ffffffffffffffff R03 = c0000000031d0f88 R19 = 0000000000000001 R04 = c0000002ae36fa68 R20 = c0000003bb97b8a0 R05 = 0000000000000000 R21 = c0000002ae36fa68 R06 = 0000000000000000 R22 = 0000000000000000 R07 = 0000000000000001 R23 = c0000002ae36fbb0 R08 = 0000000000000002 R24 = 0000000000000000 R09 = 0000000000000000 R25 = c000000362cd3a80 R10 = 0000000000000000 R26 = 0000000000000002 R11 = c0000000001e7b60 R27 = 0000000000000000 R12 = 0000000042000484 R28 = 0000000000000001 R13 = c000000000f66300 R29 = c0000003bb97b9b8 R14 = 0000000000000001 R30 = c000000000e28a08 R15 = 000000000000ffff R31 = c0000000031d0f88 pc = c0000000001e7a6c .block_is_partially_uptodate+0xc/0x100 lr = c000000000142944 .generic_file_aio_read+0x1e4/0x770 msr = 8000000000009032 cr = 22000488 ctr = c0000000001e7a60 xer = 0000000020000000 trap = 300 dar = 0000000000000000 dsisr = 40000000 1f:mon> t [link register ] c000000000142944 .generic_file_aio_read+0x1e4/0x770 [c0000002ae36f9f0] c000000000142a14 .generic_file_aio_read+0x2b4/0x770 (unreliable) [c0000002ae36fb40] c0000000001b03e4 .do_sync_read+0xd4/0x160 [c0000002ae36fce0] c0000000001b153c .vfs_read+0xec/0x1f0 [c0000002ae36fd80] c0000000001b1768 .SyS_read+0x58/0xb0 [c0000002ae36fe30] c00000000000852c syscall_exit+0x0/0x40 --- Exception: c00 (System Call) at 00000080a840bc54 SP (fffca15df30) is in userspace 1f:mon> di c0000000001e7a6c c0000000001e7a6c e9290000 ld r9,0(r9) c0000000001e7a70 418200c0 beq c0000000001e7b30 # .block_is_partially_uptodate+0xd0/0x100 c0000000001e7a74 e9440008 ld r10,8(r4) c0000000001e7a78 78a80020 clrldi r8,r5,32 c0000000001e7a7c 3c000001 lis r0,1 c0000000001e7a80 812900a8 lwz r9,168(r9) c0000000001e7a84 39600001 li r11,1 c0000000001e7a88 7c080050 subf r0,r8,r0 c0000000001e7a8c 7f805040 cmplw cr7,r0,r10 c0000000001e7a90 7d6b4830 slw r11,r11,r9 c0000000001e7a94 796b0020 clrldi r11,r11,32 c0000000001e7a98 419d00a8 bgt cr7,c0000000001e7b40 # .block_is_partially_uptodate+0xe0/0x100 c0000000001e7a9c 7fa55840 cmpld cr7,r5,r11 c0000000001e7aa0 7d004214 add r8,r0,r8 c0000000001e7aa4 79080020 clrldi r8,r8,32 c0000000001e7aa8 419c0078 blt cr7,c0000000001e7b20 # .block_is_partially_uptodate+0xc0/0x100 Signed-off-by: Dave Hansen Reviewed-by: Minchan Kim Reviewed-by: Johannes Weiner Acked-by: Rik van Riel Cc: Cc: Cc: Christoph Hellwig Cc: Al Viro Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 08f41fe804d2c008e38b199afbb06e6d5d493d85 Author: Ken Chen Date: Thu Nov 11 14:05:16 2010 -0800 latencytop: fix per task accumulator commit 38715258aa2e8cd94bd4aafadc544e5104efd551 upstream. Per task latencytop accumulator prematurely terminates due to erroneous placement of latency_record_count. It should be incremented whenever a new record is allocated instead of increment on every latencytop event. Also fix search iterator to only search known record events instead of blindly searching all pre-allocated space. Signed-off-by: Ken Chen Reviewed-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8bef02493a914dbb950c0782f23d0c1fa4687303 Author: Eric Dumazet Date: Thu Oct 28 12:34:21 2010 +0200 netfilter: nf_conntrack: allow nf_ct_alloc_hashtable() to get highmem pages commit 6b1686a71e3158d3c5f125260effce171cc7852b upstream. commit ea781f197d6a8 (use SLAB_DESTROY_BY_RCU and get rid of call_rcu()) did a mistake in __vmalloc() call in nf_ct_alloc_hashtable(). I forgot to add __GFP_HIGHMEM, so pages were taken from LOWMEM only. Signed-off-by: Eric Dumazet Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit a689967c41a4bff4f652dcd6f9f5c8d14502aea5 Author: Daniel T Chen Date: Wed Dec 1 19:16:07 2010 -0500 ALSA: hda: Use "alienware" model quirk for another SSID commit 0defe09ca70daccdc83abd9c3c24cd89ae6a1141 upstream. BugLink: https://launchpad.net/bugs/683695 The original reporter states that headphone jacks do not appear to work. Upon inspecting his codec dump, and upon further testing, it is confirmed that the "alienware" model quirk is correct. Reported-and-tested-by: Cody Thierauf Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 36598470fcd3de077f1e39e5b1cc38639403475c Author: David Henningsson Date: Wed Nov 24 14:17:47 2010 +0100 ALSA: HDA: Add an extra DAC for Realtek ALC887-VD commit cc1c452e509aefc28f7ad2deed75bc69d4f915f7 upstream. The patch enables ALC887-VD to use the DAC at nid 0x26, which makes it possible to use this DAC for e g Headphone volume. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d96791016c2890df955320a8fe973801543314b Author: Daniel T Chen Date: Mon Nov 1 01:14:51 2010 -0400 ALSA: ac97: Apply quirk for Dell Latitude D610 binding Master and Headphone controls commit 0613a59456980161d0cd468bae6c63d772743102 upstream. BugLink: https://launchpad.net/bugs/669279 The original reporter states: "The Master mixer does not change the volume from the headphone output (which is affected by the headphone mixer). Instead it only seems to control the on-board speaker volume. This confuses PulseAudio greatly as the Master channel is merged into the volume mix." Fix this symptom by applying the hp_only quirk for the reporter's SSID. The fix is applicable to all stable kernels. Reported-and-tested-by: Ben Gamari Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 629a1b5e416d5710216d29feb511e7663f14b43e Author: Kailang Yang Date: Mon Nov 22 10:59:36 2010 +0100 ALSA: hda - Fixed ALC887-VD initial error commit 01e0f1378c47947b825eac05c98697ab1be1c86f upstream. ALC887-VD is like ALC888-VD. It can not be initialized as ALC882. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 577a1f5152a24d2a8a93a6d8c31d8601081d5ce3 Author: Clemens Ladisch Date: Mon Oct 25 11:42:20 2010 +0200 firewire: ohci: fix race in AR split packet handling commit a1f805e5e73a8fe166b71c6592d3837df0cd5e2e upstream. When handling an AR buffer that has been completely filled, we assumed that its descriptor will not be read by the controller and can be overwritten. However, when the last received packet happens to end at the end of the buffer, the controller might not yet have moved on to the next buffer and might read the branch address later. If we overwrite and free the page before that, the DMA context will either go dead because of an invalid Z value, or go off into some random memory. To fix this, ensure that the descriptor does not get overwritten by using only the actual buffer instead of the entire page for reassembling the split packet. Furthermore, to avoid freeing the page too early, move on to the next buffer only when some data in it guarantees that the controller has moved on. This should eliminate the remaining firewire-net problems. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 72f7e77b79a00ea56c7d76e3a95833ace58e4b9a Author: Clemens Ladisch Date: Mon Oct 25 11:41:53 2010 +0200 firewire: ohci: fix buffer overflow in AR split packet handling commit 85f7ffd5d2b320f73912b15fe8cef34bae297daf upstream. When the controller had to split a received asynchronous packet into two buffers, the driver tries to reassemble it by copying both parts into the first page. However, if size + rest > PAGE_SIZE, i.e., if the yet unhandled packets before the split packet, the split packet itself, and any received packets after the split packet are together larger than one page, then the memory after the first page would get overwritten. To fix this, do not try to copy the data of all unhandled packets at once, but copy the possibly needed data every time when handling a packet. This gets rid of most of the infamous crashes and data corruptions when using firewire-net. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit fd001db6fa4b80657520cb070efee71cd1f560fa Author: Jiri Slaby Date: Thu Nov 25 00:27:54 2010 +0100 TTY: ldisc, fix open flag handling commit 7f90cfc505d613f4faf096e0d84ffe99208057d9 upstream. When a concrete ldisc open fails in tty_ldisc_open, we forget to clear TTY_LDISC_OPEN. This causes a false warning on the next ldisc open: WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38() Hardware name: System Product Name Modules linked in: ... Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1 Call Trace: [] ? warn_slowpath_common+0x5e/0x8a [] ? warn_slowpath_null+0xa/0xc [] ? tty_ldisc_open+0x26/0x38 [] ? tty_set_ldisc+0x218/0x304 ... So clear the bit when failing... Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in 2.6.31-rc1. Signed-off-by: Jiri Slaby Cc: Alan Cox Reported-by: Sergey Lapin Tested-by: Sergey Lapin Signed-off-by: Greg Kroah-Hartman commit 28bda4eca2f7b1677087cc229cedf1a932fcc8fb Author: Philippe Rétornaz Date: Wed Oct 27 17:13:21 2010 +0200 tty_ldisc: Fix BUG() on hangup commit 1c95ba1e1de7edffc0c4e275e147f1a9eb1f81ae upstream. A kernel BUG when bluetooth rfcomm connection drop while the associated serial port is open is sometime triggered. It seems that the line discipline can disappear between the tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line discipline if the previous discipline is not available anymore. Signed-off-by: Philippe Retornaz Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 827136988433fec7a45b3b20b59bdf03e33cf918 Author: Jiri Slaby Date: Sun Oct 31 23:17:51 2010 +0100 TTY: restore tty_ldisc_wait_idle commit 100eeae2c5ce23b4db93ff320ee330ef1d740151 upstream. It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount), but we need to wait for last user to quit the ldisc before we close it in tty_set_ldisc. Otherwise weird things start to happen. There might be processes waiting in tty_read->n_tty_read on tty->read_wait for input to appear and at that moment, a change of ldisc is fatal. n_tty_close is called, it frees read_buf and the waiting process is still in the middle of reading and goes nuts after it is woken. Previously we prevented close to happen when others are in ldisc ops by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed that. So revoke the change and test whether there is 1 user (=we), and allow the close then. We can do that without ldisc/tty locks, because nobody else can open the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for everybody to leave. I don't understand why tty_ldisc_lock would be needed either when the counter is an atomic variable, so this is a lockless tty_ldisc_wait_idle. On the other hand, if we fail to wait (timeout or signal), we have to reenable the halted ldiscs, so we take ldisc lock and reuse the setup path at the end of tty_set_ldisc. Signed-off-by: Jiri Slaby Acked-by: Linus Torvalds Tested-by: Sebastian Andrzej Siewior LKML-Reference: <20101031104136.GA511@Chamillionaire.breakpoint.cc> LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@suse.cz> Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 83da3263835bfa8d6c9a6c475b95da219bd82c31 Author: Jiri Olsa Date: Mon Nov 8 19:01:47 2010 +0100 tty: prevent DOS in the flush_to_ldisc commit e045fec48970df84647a47930fcf7a22ff7229c0 upstream. There's a small window inside the flush_to_ldisc function, where the tty is unlocked and calling ldisc's receive_buf function. If in this window new buffer is added to the tty, the processing might never leave the flush_to_ldisc function. This scenario will hog the cpu, causing other tty processing starving, and making it impossible to interface the computer via tty. I was able to exploit this via pty interface by sending only control characters to the master input, causing the flush_to_ldisc to be scheduled, but never actually generate any output. To reproduce, please run multiple instances of following code. - SNIP #define _XOPEN_SOURCE #include #include #include #include #include int main(int argc, char **argv) { int i, slave, master = getpt(); char buf[8192]; sprintf(buf, "%s", ptsname(master)); grantpt(master); unlockpt(master); slave = open(buf, O_RDWR); if (slave < 0) { perror("open slave failed"); return 1; } for(i = 0; i < sizeof(buf); i++) buf[i] = rand() % 32; while(1) { write(master, buf, sizeof(buf)); } return 0; } - SNIP The attached patch (based on -next tree) fixes this by checking on the tty buffer tail. Once it's reached, the current work is rescheduled and another could run. Signed-off-by: Jiri Olsa Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 47755c2aa1e10d2b743716a7fc9dcc91ed36af33 Author: Justin Maggard Date: Wed Nov 24 16:36:17 2010 +1100 md: fix return value of rdev_size_change() commit c26a44ed1e552aaa1d4ceb71842002d235fe98d7 upstream. When trying to grow an array by enlarging component devices, rdev_size_store() expects the return value of rdev_size_change() to be in sectors, but the actual value is returned in KBs. This functionality was broken by commit dd8ac336c13fd8afdb082ebacb1cddd5cf727889 so this patch is suitable for any kernel since 2.6.30. Signed-off-by: Justin Maggard Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 440692ac192c43876bf2f21f7f215dd037e2a823 Author: NeilBrown Date: Wed Nov 24 16:39:46 2010 +1100 md/raid1: really fix recovery looping when single good device fails. commit 8f9e0ee38f75d4740daa9e42c8af628d33d19a02 upstream. Commit 4044ba58dd15cb01797c4fd034f39ef4a75f7cc3 supposedly fixed a problem where if a raid1 with just one good device gets a read-error during recovery, the recovery would abort and immediately restart in an infinite loop. However it depended on raid1_remove_disk removing the spare device from the array. But that does not happen in this case. So add a test so that in the 'recovery_disabled' case, the device will be removed. This suitable for any kernel since 2.6.29 which is when recovery_disabled was introduced. Reported-by: Sebastian Färber Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ffcac2098d79a1d68eaddcf05d5b6aecfde6a41c Author: Tyler Hicks Date: Thu Sep 23 02:35:04 2010 -0500 eCryptfs: Clear LOOKUP_OPEN flag when creating lower file commit 2e21b3f124eceb6ab5a07c8a061adce14ac94e14 upstream. eCryptfs was passing the LOOKUP_OPEN flag through to the lower file system, even though ecryptfs_create() doesn't support the flag. A valid filp for the lower filesystem could be returned in the nameidata if the lower file system's create() function supported LOOKUP_OPEN, possibly resulting in unencrypted writes to the lower file. However, this is only a potential problem in filesystems (FUSE, NFS, CIFS, CEPH, 9p) that eCryptfs isn't known to support today. https://bugs.launchpad.net/ecryptfs/+bug/641703 Reported-by: Kevin Buhr Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit dbd39f4c57e6bb0d941b19380b02992666bb1169 Author: Florian Tobias Schandinat Date: Wed Sep 22 02:33:52 2010 +0000 viafb: use proper register for colour when doing fill ops commit efd4f6398dc92b5bf392670df862f42a19f34cf2 upstream. The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323 Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan Cc: Daniel Drake Cc: Jon Nettleton Signed-off-by: Greg Kroah-Hartman commit d569283b9aef5cc8a56f81596018b9d09951a548 Author: Graham Gower Date: Wed Oct 27 15:33:00 2010 -0700 drivers/char/vt_ioctl.c: fix VT_OPENQRY error value commit 1e0ad2881d50becaeea70ec696a80afeadf944d2 upstream. When all VT's are in use, VT_OPENQRY casts -1 to unsigned char before returning it to userspace as an int. VT255 is not the next available console. Signed-off-by: Graham Gower Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 57a14e526c888cf99015f52320ffab89d8f2eda6 Author: Ben Hutchings Date: Fri Oct 22 04:38:26 2010 +0000 net: NETIF_F_HW_CSUM does not imply FCoE CRC offload commit 66c68bcc489fadd4f5e8839e966e3a366e50d1d5 upstream. NETIF_F_HW_CSUM indicates the ability to update an TCP/IP-style 16-bit checksum with the checksum of an arbitrary part of the packet data, whereas the FCoE CRC is something entirely different. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5572adc7b7f7694b2ea4abcc87eb81a6bb64656e Author: Dan Rosenberg Date: Thu Sep 30 15:15:31 2010 -0700 sys_semctl: fix kernel stack leakage commit 982f7c2b2e6a28f8f266e075d92e19c0dd4c6e56 upstream. The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO, IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete version of the semid_ds struct. The copy_semid_to_user() function declares a semid_ds struct on the stack and copies it back to the user without initializing or zeroing the "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers, allowing the leakage of 16 bytes of kernel stack memory. The code is still reachable on 32-bit systems - when calling semctl() newer glibc's automatically OR the IPC command with the IPC_64 flag, but invoking the syscall directly allows users to use the older versions of the struct. Signed-off-by: Dan Rosenberg Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cebb2f20e037878d8c4f7402f3e8b73e855b72d5 Author: Vasiliy Kulikov Date: Sat Oct 30 18:22:49 2010 +0400 ipc: shm: fix information leak to userland commit 3af54c9bd9e6f14f896aac1bb0e8405ae0bc7a44 upstream. The shmid_ds structure is copied to userland with shm_unused{,2,3} fields unitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3cb129c0ea32cb70e982551a8f6f578e46f0f0a8 Author: Dan Rosenberg Date: Wed Oct 27 15:34:17 2010 -0700 ipc: initialize structure memory to zero for compat functions commit 03145beb455cf5c20a761e8451e30b8a74ba58d9 upstream. This takes care of leaking uninitialized kernel stack memory to userspace from non-zeroed fields in structs in compat ipc functions. Signed-off-by: Dan Rosenberg Cc: Manfred Spraul Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7ee77118ebd4b01892adaef73633f61dcffc57b3 Author: Jeremy Fitzhardinge Date: Mon Nov 29 14:16:53 2010 -0800 xen: don't bother to stop other cpus on shutdown/reboot commit 31e323cca9d5c8afd372976c35a5d46192f540d1 upstream. Xen will shoot all the VCPUs when we do a shutdown hypercall, so there's no need to do it manually. In any case it will fail because all the IPI irqs have been pulled down by this point, so the cross-CPU calls will simply hang forever. Until change 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce the function calls were not synchronously waited for, so this wasn't apparent. However after that change the calls became synchronous leading to a hang on shutdown on multi-VCPU guests. Signed-off-by: Jeremy Fitzhardinge Cc: Alok Kataria Signed-off-by: Greg Kroah-Hartman commit daf650021ea06a0490f2cbb9709c422969b1d3ea Author: Ian Campbell Date: Fri Oct 8 16:59:12 2010 +0100 xen: ensure that all event channels start off bound to VCPU 0 commit b0097adeec27e30223c989561ab0f7aa60d1fe93 upstream. All event channels startbound to VCPU 0 so ensure that cpu_evtchn_mask is initialised to reflect this. Otherwise there is a race after registering an event channel but before the affinity is explicitly set where the event channel can be delivered. If this happens then the event channel remains pending in the L1 (evtchn_pending) array but is cleared in L2 (evtchn_pending_sel), this means the event channel cannot be reraised until another event channel happens to trigger the same L2 entry on that VCPU. sizeof(cpu_evtchn_mask(0))==sizeof(unsigned long*) which is not correct, and causes only the first 32 or 64 event channels (depending on architecture) to be initially bound to VCPU0. Use sizeof(struct cpu_evtchn_s) instead. Signed-off-by: Ian Campbell Cc: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 998eaeb0802f35212659849de50ff0ae751f4ad7 Author: Robin@sgi.com Date: Wed Nov 24 12:56:59 2010 -0800 sgi-xpc: XPC fails to discover partitions with all nasids above 128 commit c22c7aeff69796f46ae0fcec141538e28f50b24e upstream. UV hardware defines 256 memory protection regions versus the baseline 64 with increasing size for the SN2 ia64. This was overlooked when XPC was modified to accomodate both UV and SN2. Without this patch, a user could reconfigure their existing system and suddenly disable cross-partition communications with no indication of what has gone wrong. It also prevents larger configurations from using cross-partition communication. Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6b9f631802b55b9fbc1d2c1064ae10b67ecbbe2d Author: Daniel Klaffenbach Date: Fri Nov 19 21:25:21 2010 -0600 ssb: b43-pci-bridge: Add new vendor for BCM4318 commit 1d8638d4038eb8709edc80e37a0bbb77253d86e9 upstream. Add new vendor for Broadcom 4318. Signed-off-by: Daniel Klaffenbach Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4057f5d12cf78af68f68b089bce34376d238245f Author: KAMEZAWA Hiroyuki Date: Tue Oct 26 14:22:08 2010 -0700 mm: fix is_mem_section_removable() page_order BUG_ON check commit 572438f9b52236bd8938b1647cc15e027d27ef55 upstream. page_order() is called by memory hotplug's user interface to check the section is removable or not. (is_mem_section_removable()) It calls page_order() withoug holding zone->lock. So, even if the caller does if (PageBuddy(page)) ret = page_order(page) ... The caller may hit BUG_ON(). For fixing this, there are 2 choices. 1. add zone->lock. 2. remove BUG_ON(). is_mem_section_removable() is used for some "advice" and doesn't need to be 100% accurate. This is_removable() can be called via user program.. We don't want to take this important lock for long by user's request. So, this patch removes BUG_ON(). Signed-off-by: KAMEZAWA Hiroyuki Acked-by: Wu Fengguang Acked-by: Michal Hocko Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d7d57d893e18626af42e66bfa0c4692c6e592181 Author: KAMEZAWA Hiroyuki Date: Tue Oct 26 14:21:10 2010 -0700 mm: fix return value of scan_lru_pages in memory unplug commit f8f72ad5396987e05a42cf7eff826fb2a15ff148 upstream. scan_lru_pages returns pfn. So, it's type should be "unsigned long" not "int". Note: I guess this has been work until now because memory hotplug tester's machine has not very big memory.... physical address < 32bit << PAGE_SHIFT. Reported-by: KOSAKI Motohiro Signed-off-by: KAMEZAWA Hiroyuki Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 20c2cc34ba06450310c5d04e51a63fae619b3e1d Author: Jean Delvare Date: Thu Oct 28 20:31:50 2010 +0200 hwmon: (lm85) Fix ADT7468 frequency table commit fa7a5797e57d2ed71f9a6fb44f0ae42c2d7b74b7 upstream. The ADT7468 uses the same frequency table as the ADT7463. Signed-off-by: Jean Delvare Cc: Darrick J. Wong Acked-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 967074811d5e0cf62c2dd298e1a2cfa564979aca Author: Eric Dumazet Date: Wed Oct 27 19:33:43 2010 +0200 numa: fix slab_node(MPOL_BIND) commit 800416f799e0723635ac2d720ad4449917a1481c upstream. When a node contains only HighMem memory, slab_node(MPOL_BIND) dereferences a NULL pointer. [ This code seems to go back all the way to commit 19770b32609b: "mm: filter based on a nodemask as well as a gfp_mask". Which was back in April 2008, and it got merged into 2.6.26. - Linus ] Signed-off-by: Eric Dumazet Cc: Mel Gorman Cc: Christoph Lameter Cc: Lee Schermerhorn Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6295a5d0fa59cda35b9bcca230524a7397923663 Author: Richard Weinberger Date: Tue Oct 26 14:21:13 2010 -0700 um: fix global timer issue when using CONFIG_NO_HZ commit 482db6df1746c4fa7d64a2441d4cb2610249c679 upstream. This fixes a issue which was introduced by fe2cc53e ("uml: track and make up lost ticks"). timeval_to_ns() returns long long and not int. Due to that UML's timer did not work properlt and caused timer freezes. Signed-off-by: Richard Weinberger Acked-by: Pekka Enberg Cc: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 417bcaef1160833d07668a3394d292617c25d5f5 Author: Richard Weinberger Date: Tue Oct 26 14:21:16 2010 -0700 um: remove PAGE_SIZE alignment in linker script causing kernel segfault. commit 6915e04f8847bea16d0890f559694ad8eedd026c upstream. The linker script cleanup that I did in commit 5d150a97f93 ("um: Clean up linker script using standard macros.") (2.6.32) accidentally introduced an ALIGN(PAGE_SIZE) when converting to use INIT_TEXT_SECTION; Richard Weinberger reported that this causes the kernel to segfault with CONFIG_STATIC_LINK=y. I'm not certain why this extra alignment is a problem, but it seems likely it is because previously __init_begin = _stext = _text = _sinittext and with the extra ALIGN(PAGE_SIZE), _sinittext becomes different from the rest. So there is likely a bug here where something is assuming that _sinittext is the same as one of those other symbols. But reverting the accidental change fixes the regression, so it seems worth committing that now. Signed-off-by: Tim Abbott Reported-by: Richard Weinberger Cc: Jeff Dike Tested by: Antoine Martin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1f383de442a419719650d3ff4c0aa7542f301a92 Author: Masanori ITOH Date: Tue Oct 26 14:21:20 2010 -0700 percpu: fix list_head init bug in __percpu_counter_init() commit 8474b591faf3bb0a1e08a60d21d6baac498f15e4 upstream. WARNING: at lib/list_debug.c:26 __list_add+0x3f/0x81() Hardware name: Express5800/B120a [N8400-085] list_add corruption. next->prev should be prev (ffffffff81a7ea00), but was dead000000200200. (next=ffff88080b872d58). Modules linked in: aoe ipt_MASQUERADE iptable_nat nf_nat autofs4 sunrpc bridge 8021q garp stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_round_robin dm_multipath kvm_intel kvm uinput lpfc scsi_transport_fc igb ioatdma scsi_tgt i2c_i801 i2c_core dca iTCO_wdt iTCO_vendor_support pcspkr shpchp megaraid_sas [last unloaded: aoe] Pid: 54, comm: events/3 Tainted: G W 2.6.34-vanilla1 #1 Call Trace: [] warn_slowpath_common+0x7c/0x94 [] warn_slowpath_fmt+0x41/0x43 [] __list_add+0x3f/0x81 [] __percpu_counter_init+0x59/0x6b [] bdi_init+0x118/0x17e [] blk_alloc_queue_node+0x79/0x143 [] blk_alloc_queue+0x11/0x13 [] aoeblk_gdalloc+0x8e/0x1c9 [aoe] [] aoecmd_sleepwork+0x25/0xa8 [aoe] [] worker_thread+0x1a9/0x237 [] ? aoecmd_sleepwork+0x0/0xa8 [aoe] [] ? autoremove_wake_function+0x0/0x39 [] ? worker_thread+0x0/0x237 [] kthread+0x7f/0x87 [] kernel_thread_helper+0x4/0x10 [] ? kthread+0x0/0x87 [] ? kernel_thread_helper+0x0/0x10 It's because there is no initialization code for a list_head contained in the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up when block device drivers calling blk_alloc_queue() are used. In case of me, I got them by using aoe. Signed-off-by: Masanori Itoh Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f2318dc7f5c66e3cd21eaf8ce92d0b0298bed1fb Author: Richard A. Smith Date: Sat Sep 25 19:19:26 2010 +0100 olpc_battery: Fix endian neutral breakage for s16 values commit 7cfbb29466633e6ecdc14f76a693c8478c2b22af upstream. When the driver was updated to be endian neutral (8e9c7716c) the signed part of the s16 values was lost. This is because be16_to_cpu() returns an unsigned value. This patch casts the values back to a s16 number prior to the the implicit cast up to an int. Signed-off-by: Richard A. Smith Signed-off-by: Daniel Drake Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman commit a8db638a4812c4b171f567c973c6c4d67b9f15c2 Author: Jiri Slaby Date: Tue Oct 26 14:22:11 2010 -0700 hpet: unmap unused I/O space commit a56d5318716d120e040294bb258901ba89fb9c90 upstream. When the initialization code in hpet finds a memory resource and does not find an IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it is reported as: BUG: Bad page state in process md5sum pfn:3ed00 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0 page flags: 0x20000001000000(uncached) Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1 Call Trace: [] bad_page+0xb1/0x100 [] prep_new_page+0x1a5/0x1c0 [] get_page_from_freelist+0x3a1/0x640 [] __alloc_pages_nodemask+0x10f/0x6b0 ... In this particular case: 1) HPET returns 3ed00000 as memory region base, but it is not in reserved ranges reported by the BIOS (excerpt): BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable) BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved) 2) there is no IRQ resource reported by HPET method. On the other hand, the Intel HPET specs (1.0a) says (3.2.5.1): _CRS ( // Report 1K of memory consumed by this Timer Block memory range consumed // Optional: only used if BIOS allocates Interrupts [1] IRQs consumed ) [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as "consumed resources". So in theory we should check whether if it is the case and use those interrupts instead. Anyway the address reported by the BIOS here is bogus, so non-presence of IRQ doesn't mean the "optional" part in point 2). Since I got no reply previously, fix this by simply unmapping the space when IRQ is not found and memory region was mapped previously. It would be probably more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now. Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908 Reported-by: Olaf Hering Signed-off-by: Jiri Slaby Acked-by: Clemens Ladisch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 157a8a683026fdc98d0ba48e2cc3ce100403a2ce Author: Clemens Ladisch Date: Tue Oct 26 14:22:13 2010 -0700 hpet: fix unwanted interrupt due to stale irq status bit commit 96e9694df446d1154ec2f4fdba8908588b9cba38 upstream. Jaswinder Singh Rajput wrote: > By executing Documentation/timers/hpet_example.c > > for polling, I requested for 3 iterations but it seems iteration work > for only 2 as first expired time is always very small. > > # ./hpet_example poll /dev/hpet 10 3 > -hpet: executing poll > hpet_poll: info.hi_flags 0x0 > hpet_poll: expired time = 0x13 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x1868c > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x18645 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 Clearing the HPET interrupt enable bit disables interrupt generation but does not disable the timer, so the interrupt status bit will still be set when the timer elapses. If another interrupt arrives before the timer has been correctly programmed (due to some other device on the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an extra unwanted interrupt event because the status bit is likely to be set from comparator matches that happened before the device was opened. Therefore, we have to ensure that the interrupt status bit is and stays cleared until we actually program the timer. Signed-off-by: Clemens Ladisch Reported-by: Jaswinder Singh Rajput Cc: Ingo Molnar Cc: Thomas Gleixner Cc: john stultz Cc: Bob Picco Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cf4feb1acab5e9f00d7c64327d8508573f579420 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:23:33 2010 -0800 Staging: line6: fix up some sysfs attribute permissions commit 2018845b6a169f75341f8e68ad1089cb6697cf24 and 2018845b6a169f75341f8e68ad1089cb6697cf24 upstream merged together as it had to be backported by hand. They should not be writable by any user Reported-by: Linus Torvalds Cc: Markus Grabner Cc: Mariusz Kozlowski Signed-off-by: Greg Kroah-Hartman commit 2247463fc62ef3ccedd1d6b1e64e910b8c4fa276 Author: Greg Kroah-Hartman Date: Thu Nov 18 11:21:04 2010 -0800 Staging: asus_oled: fix up my fixup for some sysfs attribute permissions commit 515b4987ccd097cdf5416530b05fdf9e01afe95a upstream. They should be writable by root, not readable. Doh, stupid me with the wrong flags. Reported-by: Jonathan Cameron Cc: Jakub Schmidtke Signed-off-by: Greg Kroah-Hartman commit ea92789ccaa9db00d73079f669405b3d2c775e0b Author: Greg Kroah-Hartman Date: Tue Nov 16 11:17:01 2010 -0800 Staging: asus_oled: fix up some sysfs attribute permissions commit 590b0b9754bd8928926bae7194b6da7ead9bda3b upstream. They should not be writable by any user Reported-by: Linus Torvalds Cc: Jakub Schmidtke Signed-off-by: Greg Kroah-Hartman commit bc62f2056eefd5996afb73c4afe59d79da12c484 Author: Frederic Weisbecker Date: Thu Dec 2 14:31:16 2010 -0800 reiserfs: don't acquire lock recursively in reiserfs_acl_chmod commit 238af8751f64a75f8b638193353b1c31ea32e738 upstream. reiserfs_acl_chmod() can be called by reiserfs_set_attr() and then take the reiserfs lock a second time. Thereafter it may call journal_begin() that definitely requires the lock not to be nested in order to release it before taking the journal mutex because the reiserfs lock depends on the journal mutex already. So, aviod nesting the lock in reiserfs_acl_chmod(). Reported-by: Pawel Zawora Signed-off-by: Frederic Weisbecker Tested-by: Pawel Zawora Cc: Jeff Mahoney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c90039d59a6a4c8e675f44974a8d4affd4a55d8c Author: Kees Cook Date: Thu Oct 7 10:03:48 2010 +0000 net: clear heap allocation for ETHTOOL_GRXCLSRLALL commit ae6df5f96a51818d6376da5307d773baeece4014 upstream. Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace. Signed-off-by: Kees Cook Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cedb14039c279adef0b250a636da323ac904f1df Author: Samuel Ortiz Date: Wed Oct 6 01:03:12 2010 +0200 irda: Fix heap memory corruption in iriap.c commit 37f9fc452d138dfc4da2ee1ce5ae85094efc3606 upstream. While parsing the GetValuebyClass command frame, we could potentially write passed the skb->data pointer. Reported-by: Ilja Van Sprundel Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit a2014bf8aa1568b2a4e77a1ed38370f8c80cb89d Author: Samuel Ortiz Date: Mon Oct 11 01:17:56 2010 +0200 irda: Fix parameter extraction stack overflow commit efc463eb508798da4243625b08c7396462cabf9f upstream. Reported-by: Ilja Van Sprundel Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 3b8bd6c1f25dcff1b83bb7873e9eb8bee47e0483 Author: Jens Axboe Date: Fri Oct 29 08:10:18 2010 -0600 block: check for proper length of iov entries in blk_rq_map_user_iov() commit 9284bcf4e335e5f18a8bc7b26461c33ab60d0689 upstream. Ensure that we pass down properly validated iov segments before calling into the mapping or copy functions. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b82a78188b15bf15da8279a6022504122abf39fd Author: Jens Axboe Date: Fri Oct 29 11:31:42 2010 -0600 block: take care not to overflow when calculating total iov length commit 9f864c80913467312c7b8690e41fb5ebd1b50e92 upstream. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a39d84dc4380145211331849f12f8af781fb6c83 Author: Jens Axboe Date: Fri Oct 29 11:46:56 2010 -0600 block: limit vec count in bio_kmalloc() and bio_alloc_map_data() commit f3f63c1c28bc861a931fac283b5bc3585efb8967 upstream. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 43e069893c8749d04924e12cd81ce10c583ae6be Author: Martin K. Petersen Date: Wed Oct 13 21:18:03 2010 +0200 block: Ensure physical block size is unsigned int commit 892b6f90db81cccb723d5d92f4fddc2d68b206e1 upstream. Physical block size was declared unsigned int to accomodate the maximum size reported by READ CAPACITY(16). Make sure we use the right type in the related functions. Signed-off-by: Martin K. Petersen Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 63676c6866f8d4711a44968c8247f59fdae1e287 Author: Mike Christie Date: Wed Oct 6 03:10:59 2010 -0500 Fix regressions in scsi_internal_device_block commit 986fe6c7f50974e871b8ab5a800f5310ea25b361 upstream. Deleting a SCSI device on a blocked fc_remote_port (before fast_io_fail_tmo fires) results in a hanging thread: STACK: 0 schedule+1108 [0x5cac48] 1 schedule_timeout+528 [0x5cb7fc] 2 wait_for_common+266 [0x5ca6be] 3 blk_execute_rq+160 [0x354054] 4 scsi_execute+324 [0x3b7ef4] 5 scsi_execute_req+162 [0x3b80ca] 6 sd_sync_cache+138 [0x3cf662] 7 sd_shutdown+138 [0x3cf91a] 8 sd_remove+112 [0x3cfe4c] 9 __device_release_driver+124 [0x3a08b8] 10 device_release_driver+60 [0x3a0a5c] 11 bus_remove_device+266 [0x39fa76] 12 device_del+340 [0x39d818] 13 __scsi_remove_device+204 [0x3bcc48] 14 scsi_remove_device+66 [0x3bcc8e] 15 sysfs_schedule_callback_work+50 [0x260d66] 16 worker_thread+622 [0x162326] 17 kthread+160 [0x1680b0] 18 kernel_thread_starter+6 [0x10aaea] During the delete, the SCSI device is in moved to SDEV_CANCEL. When the FC transport class later calls scsi_target_unblock, this has no effect, since scsi_internal_device_unblock ignores SCSI devics in this state. It looks like all these are regressions caused by: 5c10e63c943b4c67561ddc6bf61e01d4141f881f [SCSI] limit state transitions in scsi_internal_device_unblock Fix by rejecting offline and cancel in the state transition. Signed-off-by: Christof Schmitt [jejb: Original patch by Christof Schmitt, modified by Mike Christie] Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a66903bae9ce78bf61056b9b9c2741fcd9c000b7 Author: Christof Schmitt Date: Wed Oct 6 13:19:44 2010 +0200 Fix race when removing SCSI devices commit 546ae796bfac6399e30da4b5af2cf7a6d0f8a4ec upstream. Removing SCSI devices through echo 1 > /sys/bus/scsi/devices/ ... /delete while the FC transport class removes the SCSI target can lead to an oops: Unable to handle kernel pointer dereference at virtual kernel address 00000000b6815000 Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: sunrpc qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 qeth ccwgroup [last unloaded: scsi_wait_scan] CPU: 1 Not tainted 2.6.35.5-45.x.20100924-s390xdefault #1 Process fc_wq_0 (pid: 861, task: 00000000b7331240, ksp: 00000000b735bac0) Krnl PSW : 0704200180000000 00000000003ff6e4 (__scsi_remove_device+0x24/0xd0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 Krnl GPRS: 0000000000000001 0000000000000000 00000000b6815000 00000000bc24a8c0 00000000003ff7c8 000000000056dbb8 0000000000000002 0000000000835d80 ffffffff00000000 0000000000001000 00000000b6815000 00000000bc24a7f0 00000000b68151a0 00000000b6815000 00000000b735bc20 00000000b735bbf8 Krnl Code: 00000000003ff6d6: a7840001 brc 8,3ff6d8 00000000003ff6da: a7fbffd8 aghi %r15,-40 00000000003ff6de: e3e0f0980024 stg %r14,152(%r15) >00000000003ff6e4: e31021200004 lg %r1,288(%r2) 00000000003ff6ea: a71f0000 cghi %r1,0 00000000003ff6ee: a7a40011 brc 10,3ff710 00000000003ff6f2: a7390003 lghi %r3,3 00000000003ff6f6: c0e5ffffc8b1 brasl %r14,3f8858 Call Trace: ([<0000000000001000>] 0x1000) [<00000000003ff7d2>] scsi_remove_device+0x42/0x54 [<00000000003ff8ba>] __scsi_remove_target+0xca/0xfc [<00000000003ff99a>] __remove_child+0x3a/0x48 [<00000000003e3246>] device_for_each_child+0x72/0xbc [<00000000003ff93a>] scsi_remove_target+0x4e/0x74 [<0000000000406586>] fc_rport_final_delete+0xb2/0x23c [<000000000015d080>] worker_thread+0x200/0x344 [<000000000016330c>] kthread+0xa0/0xa8 [<0000000000106c1a>] kernel_thread_starter+0x6/0xc [<0000000000106c14>] kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. Last Breaking-Event-Address: [<00000000003ff7cc>] scsi_remove_device+0x3c/0x54 The function __scsi_remove_target iterates through the SCSI devices on the host, but it drops the host_lock before calling scsi_remove_device. When the SCSI device is deleted from another thread, the pointer to the SCSI device in scsi_remove_device can become invalid. Fix this by getting a reference to the SCSI device before dropping the host_lock to keep the SCSI device alive for the call to scsi_remove_device. Signed-off-by: Christof Schmitt Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 02a88fedb4923da2a99f83c351a2fcc2ffab9a2a Author: Dan Carpenter Date: Fri Oct 8 09:03:07 2010 +0200 gdth: integer overflow in ioctl commit f63ae56e4e97fb12053590e41a4fa59e7daa74a4 upstream. gdth_ioctl_alloc() takes the size variable as an int. copy_from_user() takes the size variable as an unsigned long. gen.data_len and gen.sense_len are unsigned longs. On x86_64 longs are 64 bit and ints are 32 bit. We could pass in a very large number and the allocation would truncate the size to 32 bits and allocate a small buffer. Then when we do the copy_from_user(), it would result in a memory corruption. Signed-off-by: Dan Carpenter Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit c960e1e3eafdf8b09b376dd15496c6447eee245d Author: David Milburn Date: Fri Sep 3 17:13:03 2010 -0500 libsas: fix NCQ mixing with non-NCQ commit f0ad30d3d2dc924decc0e10b1ff6dc32525a5d99 upstream. Some cards (like mvsas) have issue troubles if non-NCQ commands are mixed with NCQ ones. Fix this by using the libata default NCQ check routine which waits until all NCQ commands are complete before issuing a non-NCQ one. The impact to cards (like aic94xx) which don't need this logic should be minimal Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit f1c532c57f510a26886d8ee8650cfd1926e47b36 Author: Michael Reed Date: Mon Sep 20 11:20:22 2010 -0500 sd name space exhaustion causes system hang commit 1a03ae0f556a931aa3747b70e44b78308f5b0590 upstream. Following a site power outage which re-enabled all the ports on my FC switches, my system subsequently booted with far too many luns! I had let it run hoping it would make multi-user. It didn't. :( It hung solid after exhausting the last sd device, sdzzz, and attempting to create sdaaaa and beyond. I was unable to get a dump. Discovered using a 2.6.32.13 based system. correct this by detecting when the last index is utilized and failing the sd probe of the device. Patch applies to scsi-misc-2.6. Signed-off-by: Michael Reed Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 3c2feffd253e2c9f27c6b4d5af377d5aa9ae9233 Author: Alan Stern Date: Thu Oct 14 15:25:21 2010 -0400 USB: accept some invalid ep0-maxpacket values commit 56626a72a47bf3e50875d960d6b5f17b9bee0ab2 upstream. A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so. This patch (as1432) softens our acceptance criterion by allowing high-speed devices to have ep0-maxpacket sizes other than 64. A warning is printed in the system log when this happens, and the existing error message is clarified. Signed-off-by: Alan Stern Reported-by: James Signed-off-by: Greg Kroah-Hartman commit 3812790e565781417cc93fc5486f7f7624bbdad1 Author: Alon Ziv Date: Sun Oct 10 08:32:18 2010 +0200 USB: opticon: Fix long-standing bugs in opticon driver commit 97cd8dc4ca9a1a5efb2cc38758e01492e3b013e2 upstream. The bulk-read callback had two bugs: a) The bulk-in packet's leading two zeros were returned (and the two last bytes truncated) b) The wrong URB was transmitted for the second (and later) read requests, causing further reads to return the entire packet (including leading zeros) Signed-off-by: Alon Ziv Signed-off-by: Greg Kroah-Hartman commit 4002f1cd2d58821fb269f1756a9aa109c5355fe0 Author: Alan Stern Date: Thu Sep 30 15:16:23 2010 -0400 USB: disable endpoints after unbinding interfaces, not before commit 80f0cf3947889014d3a3dc0ad60fb87cfda4b12a upstream. This patch (as1430) fixes a bug in usbcore. When a device configuration change occurs or a device is removed, the endpoints for the old config should be completely disabled. However it turns out they aren't; this is because usb_unbind_interface() calls usb_enable_interface() or usb_set_interface() to put interfaces back in altsetting 0, which re-enables the interfaces' endpoints. As a result, when a device goes through a config change or is unconfigured, the ep_in[] and ep_out[] arrays may be left holding old pointers to usb_host_endpoint structures. If the device is deauthorized these structures get freed, and the stale pointers cause errors when the the device is eventually unplugged. The solution is to disable the endpoints after unbinding the interfaces instead of before. This isn't as large a change as it sounds, since usb_unbind_interface() disables all the interface's endpoints anyway before calling the driver's disconnect routine, unless the driver claims to support "soft" unbind. This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing the underlying cause of the problem. Signed-off-by: Alan Stern Tested-by: Carsten Sommer Signed-off-by: Greg Kroah-Hartman commit e87b55b054520085a5367585b7cd7d5b0684c649 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Mon Sep 20 18:31:07 2010 +0200 USB: atmel_usba_udc: force vbus_pin at -EINVAL when gpio_request failled commit 969affff54702785330de553b790372e261e93f9 upstream. to ensure gpio_is_valid return false Signed-off-by: Nicolas Ferre Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Greg Kroah-Hartman commit edcbf7a884544d364893699b3a04b8d8f8871b68 Author: Anders Larsen Date: Wed Oct 6 23:46:25 2010 +0200 USB: cp210x: Add WAGO 750-923 Service Cable device ID commit 93ad03d60b5b18897030038234aa2ebae8234748 upstream. The WAGO 750-923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH. Bus 004 Device 002: ID 1be3:07a6 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1be3 idProduct 0x07a6 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 WAGO USB Service Cable iSerial 3 1277796751 . . . Signed-off-by: Anders Larsen Signed-off-by: Greg Kroah-Hartman commit f621a8720db433836973abf1259807c2918b3724 Author: DJ Delorie Date: Fri Sep 17 11:09:06 2010 -0400 USB: cp210x: Add Renesas RX-Stick device ID commit 2f1136d1d08a63dcdbcd462621373f30d8dfe590 upstream. RX610 development board by Renesas Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x045b Hitachi, Ltd idProduct 0x0053 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 RX-Stick iSerial 3 0001 . . . http://am.renesas.com/rx610stick Signed-off-by: DJ Delorie Signed-off-by: Greg Kroah-Hartman commit 994881281d3c4d36e747064f8e6d132ae85cb848 Author: Mauro Carvalho Chehab Date: Sun Sep 12 11:41:50 2010 -0300 USB: option: Add more ZTE modem USB id's commit ecfa153ef616b901e86d9a051b329fcda7a6ce7b upstream. There are lots of ZTE USB id's currently not covered by usb/serial. Adds them, to allow those devices to work properly on Linux. While here, put the USB ID's for 0x2002/0x2003 at the sorted order. This patch is based on zte.c file found on MF645. PS.: The ZTE driver is commenting the USB ID for 0x0053. It also adds, commented, an USB ID for 0x0026. Not sure why, but I think that 0053 is used by their devices in storage mode only. So, I opted to keep the comment on this patch. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d5ecedd26ef34071322434d53fa2f900aa1d87bd Author: Sergei Shtylyov Date: Wed Sep 29 09:54:31 2010 +0300 usb: musb: blackfin: call gpio_free() on error path in musb_platform_init() commit 00be545e49d83485d49a598d3b7e090088934be8 upstream. Blackfin's musb_platform_init() needs to call gpio_free() for error cleanup iff otg_get_transceiver() call returns NULL. Signed-off-by: Sergei Shtylyov Acked-by: Mike Frysinger Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit fdae8723f974ef235711568c0581384bbc17245b Author: Daniel Suchy Date: Tue Oct 12 15:44:24 2010 +0200 USB: ftdi_sio: new VID/PIDs for various Papouch devices commit 59c6ccd9f9aecfa59c99ceba6d4d34b180547a05 upstream. This patch for FTDI USB serial driver ads new VID/PIDs used on various devices manufactured by Papouch (http://www.papouch.com). These devices have their own VID/PID, although they're using standard FTDI chip. In ftdi_sio.c, I also made small cleanup to have declarations for all Papouch devices together. Signed-off-by: Daniel Suchy Signed-off-by: Greg Kroah-Hartman commit 1a6ece17d81ef58bc8e1685f5903ac0a31ae2768 Author: Rainer Keller Date: Tue Sep 28 12:27:43 2010 +0200 USB: add PID for FTDI based OpenDCC hardware commit 99c1e4f89d1033444ce4d0c064bd2826e81c3775 upstream. The OpenDCC project is developing a new hardware. This patch adds its PID to the list of known FTDI devices. The PID can be found at http://www.opendcc.de/elektronik/usb/opendcc_usb.html Signed-off-by: Rainer Keller Signed-off-by: Greg Kroah-Hartman commit 28d963f504c62c5b5da25ec3411540c82966114f Author: Julia Lawall Date: Fri Oct 15 15:00:06 2010 +0200 drivers/net/wireless/p54/eeprom.c: Return -ENOMEM on memory allocation failure commit 0d91f22b75347d9503b17a42b6c74d3f7750acd6 upstream. In this code, 0 is returned on memory allocation failure, even though other failures return -ENOMEM or other similar values. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression ret; expression x,e1,e2,e3; @@ ret = 0 ... when != ret = e1 *x = \(kmalloc\|kcalloc\|kzalloc\)(...) ... when != ret = e2 if (x == NULL) { ... when != ret = e3 return ret; } // Signed-off-by: Julia Lawall Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1d60e5b3695461f708440473de9e7bd1137d9ec1 Author: Christian Lamparter Date: Fri Oct 1 22:01:24 2010 +0200 p54usb: add five more USBIDs commit 1a92795dac419128eb511dce30a6aad672064b88 upstream. Source: http://www.wikidevi.com/wiki/Intersil/p54/usb/windows Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 52415acdc04c4aa4ec6713001bcaffb79a33d9fb Author: Christian Lamparter Date: Sun Aug 22 22:41:33 2010 +0200 p54usb: fix off-by-one on !CONFIG_PM commit 11791a6f7534906b4a01ffb54ba0b02ca39398ef upstream. The ISL3887 chip needs a USB reset, whenever the usb-frontend module "p54usb" is reloaded. This patch fixes an off-by-one bug, if the user is running a kernel without the CONFIG_PM option set and for some reason (e.g.: compat-wireless) wants to switch between different p54usb modules. Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b96f78245da8bcb4eea3eee851de67aff2708cdf Author: Nicolas Kaiser Date: Thu Oct 21 14:56:00 2010 +0200 pipe: fix failure to return error code on ->confirm() commit e5953cbdff26f7cbae7eff30cd9b18c4e19b7594 upstream. The arguments were transposed, we want to assign the error code to 'ret', which is being returned. Signed-off-by: Nicolas Kaiser Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 910a36c7e4bc6bac32c6c7c0a7f08208f5bfaaa5 Author: Cliff Wickman Date: Wed Sep 8 10:14:27 2010 -0500 x86, kdump: Change copy_oldmem_page() to use cached addressing commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream. The copy of /proc/vmcore to a user buffer proceeds much faster if the kernel addresses memory as cached. With this patch we have seen an increase in transfer rate from less than 15MB/s to 80-460MB/s, depending on size of the transfer. This makes a big difference in time needed to save a system dump. Signed-off-by: Cliff Wickman Acked-by: "Eric W. Biederman" Cc: kexec@lists.infradead.org LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 37d4d10815a27b22ca1a64b1e2bf6ab6fc127749 Author: Suresh Siddha Date: Fri Aug 27 11:09:48 2010 -0700 x86, intr-remap: Set redirection hint in the IRTE commit 75e3cfbed6f71a8f151dc6e413b6ce3c390030cb upstream. Currently the redirection hint in the interrupt-remapping table entry is set to 0, which means the remapped interrupt is directed to the processors listed in the destination. So in logical flat mode in the presence of intr-remapping, this results in a single interrupt multi-casted to multiple cpu's as specified by the destination bit mask. But what we really want is to send that interrupt to one of the cpus based on the lowest priority delivery mode. Set the redirection hint in the IRTE to '1' to indicate that we want the remapped interrupt to be directed to only one of the processors listed in the destination. This fixes the issue of same interrupt getting delivered to multiple cpu's in the logical flat mode in the presence of interrupt-remapping. While there is no functional issue observed with this behavior, this will impact performance of such configurations (<=8 cpu's using logical flat mode in the presence of interrupt-remapping) Signed-off-by: Suresh Siddha LKML-Reference: <20100827181049.013051492@sbsiddha-MOBL3.sc.intel.com> Cc: Weidong Han Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 33f71188e94dcd34cacc8fd9e4e7a9bcf15d4eb8 Author: Andreas Herrmann Date: Thu Sep 30 14:32:35 2010 +0200 x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d upstream. Instead of adapting the CPU family check in amd_special_default_mtrr() for each new CPU family assume that all new AMD CPUs support the necessary bits in SYS_CFG MSR. Tom2Enabled is architectural (defined in APM Vol.2). Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT. In pre K8-NPT BKDG this bit is reserved (read as zero). W/o this adaption Linux would unnecessarily complain about bad MTRR settings on every new AMD CPU family, e.g. [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM. Signed-off-by: Andreas Herrmann LKML-Reference: <20100930123235.GB20545@loge.amd.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit f7ccf80244281eb78192832d075c989788f5f62f Author: Paul Fox Date: Fri Oct 1 18:17:19 2010 +0100 x86, olpc: Don't retry EC commands forever commit 286e5b97eb22baab9d9a41ca76c6b933a484252c upstream. Avoids a potential infinite loop. It was observed once, during an EC hacking/debugging session - not in regular operation. Signed-off-by: Daniel Drake Cc: dilinger@queued.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 566707d3db2f92e74c25e8f948ced035d6756f7e Author: Alok Kataria Date: Mon Oct 11 14:37:08 2010 -0700 x86, kexec: Make sure to stop all CPUs before exiting the kernel commit 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce upstream. x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait" this allows the caller to specify if it wants to stop until all the cpus have processed the stop IPI. This is required specifically for the kexec case where we should wait for all the cpus to be stopped before starting the new kernel. We now wait for the cpus to stop in all cases except for panic/kdump where we expect things to be broken and we are doing our best to make things work anyway. This patch fixes a legitimate regression, which was introduced during 2.6.30, by commit id 4ef702c10b5df18ab04921fc252c26421d4d6c75. Signed-off-by: Alok N Kataria LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com> Cc: Eric W. Biederman Cc: Jeremy Fitzhardinge Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit c68924b5a8894fe8e30221ded2a7eebd5835a437 Author: Andre Przywara Date: Mon Sep 6 15:14:17 2010 +0200 x86, cpu: Fix renamed, not-yet-shipping AMD CPUID feature bit commit 7ef8aa72ab176e0288f363d1247079732c5d5792 upstream. The AMD SSE5 feature set as-it has been replaced by some extensions to the AVX instruction set. Thus the bit formerly advertised as SSE5 is re-used for one of these extensions (XOP). Although this changes the /proc/cpuinfo output, it is not user visible, as there are no CPUs (yet) having this feature. To avoid confusion this should be added to the stable series, too. Signed-off-by: Andre Przywara LKML-Reference: <1283778860-26843-2-git-send-email-andre.przywara@amd.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 1928814fabf0662556cd28f248b3c1069a2c3383 Author: Cliff Wickman Date: Thu Sep 16 11:44:02 2010 -0500 mm, x86: Saving vmcore with non-lazy freeing of vmas commit 3ee48b6af49cf534ca2f481ecc484b156a41451d upstream. During the reading of /proc/vmcore the kernel is doing ioremap()/iounmap() repeatedly. And the buildup of un-flushed vm_area_struct's is causing a great deal of overhead. (rb_next() is chewing up most of that time). This solution is to provide function set_iounmap_nonlazy(). It causes a subsequent call to iounmap() to immediately purge the vma area (with try_purge_vmap_area_lazy()). With this patch we have seen the time for writing a 250MB compressed dump drop from 71 seconds to 44 seconds. Signed-off-by: Cliff Wickman Cc: Andrew Morton Cc: kexec@lists.infradead.org LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 94e7c8dcd91617fa426ef140c55d9c6496359b92 Author: Darren Hart Date: Sun Oct 17 08:35:04 2010 -0700 futex: Fix errors in nested key ref-counting commit 7ada876a8703f23befbb20a7465a702ee39b1704 upstream. futex_wait() is leaking key references due to futex_wait_setup() acquiring an additional reference via the queue_lock() routine. The nested key ref-counting has been masking bugs and complicating code analysis. queue_lock() is only called with a previously ref-counted key, so remove the additional ref-counting from the queue_(un)lock() functions. Also futex_wait_requeue_pi() drops one key reference too many in unqueue_me_pi(). Remove the key reference handling from unqueue_me_pi(). This was paired with a queue_lock() in futex_lock_pi(), so the count remains unchanged. Document remaining nested key ref-counting sites. Signed-off-by: Darren Hart Reported-and-tested-by: Matthieu Fertré Reported-by: Louis Rilling Cc: Peter Zijlstra Cc: Eric Dumazet Cc: John Kacur Cc: Rusty Russell LKML-Reference: <4CBB17A8.70401@linux.intel.com> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit c5d70fb75393ca814b90fa088ba42cb6ac4fff69 Author: Alan Cox Date: Fri Oct 22 14:11:26 2010 +0100 bluetooth: Fix missing NULL check commit c19483cc5e56ac5e22dd19cf25ba210ab1537773 upstream. Fortunately this is only exploitable on very unusual hardware. [Reported a while ago but nothing happened so just fixing it] Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7d6f5dbe923973537d25b07ae67bca552341cdf3 Author: Mathieu Desnoyers Date: Mon Sep 13 17:47:00 2010 -0400 sched: Fix string comparison in /proc/sched_features commit 7740191cd909b75d75685fb08a5d1f54b8a9d28b upstream. Fix incorrect handling of the following case: INTERACTIVE INTERACTIVE_SOMETHING_ELSE The comparison only checks up to each element's length. Changelog since v1: - Embellish using some Rostedtisms. [ mingo: ^^ == smaller and cleaner ] Signed-off-by: Mathieu Desnoyers Reviewed-by: Steven Rostedt Cc: Peter Zijlstra Cc: Tony Lindgren LKML-Reference: <20100913214700.GB16118@Krystal> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 8e1eb27c298533705a1561d4ea4dec31e80407b2 Author: Vasiliy Kulikov Date: Sun Oct 17 18:41:24 2010 +0400 pcmcia: synclink_cs: fix information leak to userland commit 5b917a1420d3d1a9c8da49fb0090692dc9aaee86 upstream. Structure new_line is copied to userland with some padding fields unitialized. It leads to leaking of stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Dominik Brodowski Signed-off-by: Greg Kroah-Hartman commit 824737ff1ea5a699b7122862e2698bbf14bc601c Author: Paul Mackerras Date: Thu Sep 9 19:02:40 2010 +0000 powerpc/perf: Fix sampling enable for PPC970 commit 9f5f9ffe50e90ed73040d2100db8bfc341cee352 upstream. The logic to distinguish marked instruction events from ordinary events on PPC970 and derivatives was flawed. The result is that instruction sampling didn't get enabled in the PMU for some marked instruction events, so they would never trigger. This fixes it by adding the appropriate break statements in the switch statement. Reported-by: David Binderman Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3260b7324aa40b49b4aff1d7f170613bb81551e3 Author: Max Vozeler Date: Tue Sep 21 17:43:30 2010 +0200 staging: usbip: Process event flags without delay commit 584c5b7cf06194464240280483ee0376cdddbbae upstream. The way the event handler works can cause it to delay events until eventual wakeup for another event. For example, on device detach (vhci): - Write to sysfs detach file -> usbip_event_add(VDEV_EVENT_DOWN) -> wakeup() #define VDEV_EVENT_DOWN (USBIP_EH_SHUTDOWN | USBIP_EH_RESET). - Event thread wakes up and passes the event to event_handler() to process. - It processes and clears the USBIP_EH_SHUTDOWN flag then returns. - The outer event loop (event_handler_loop()) calls wait_event_interruptible(). The processing of the second flag which is part of VDEV_EVENT_DOWN (USBIP_EH_RESET) did not happen yet. It is delayed until the next event. This means the ->reset callback may not happen for a long time (if ever), leaving the usbip port in a weird state which prevents its reuse. This patch changes the handler to process all flags before waiting for another wakeup. I have verified this change to fix a problem which prevented reattach of a usbip device. It also helps for socket errors which missed the RESET as well. The delayed event processing also affects the stub side of usbip and the error handling there. Signed-off-by: Max Vozeler Reported-by: Marco Lancione Tested-by: Luc Jalbert Signed-off-by: Greg Kroah-Hartman commit ffd428f2fff8a30e1202e09a73c5436cbc562d06 Author: Max Vozeler Date: Tue Sep 21 17:31:40 2010 +0200 staging: usbip: Notify usb core of port status changes commit 0c9a32f0192e656daa2ff3c9149f6d71b4a1b873 upstream. This patch changes vhci to behave like dummy and other hcds when disconnecting a device. Previously detaching a device from the root hub did not notify the usb core of the disconnect and left the device visible. Signed-off-by: Max Vozeler Reported-by: Marco Lancione Tested-by: Luc Jalbert Signed-off-by: Greg Kroah-Hartman commit 39666accd74d34684fd97f92c41ce8c26da93584 Author: Larry Finger Date: Fri May 14 22:08:58 2010 -0500 ssb: Handle alternate SSPROM location commit 9d1ac34ec3a67713308ae0883c3359c557f14d17 upstream. In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread (http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a netbook owned by John Linville (http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports of ssb failing to detect an SPROM at the normal location. After studying the MMIO trace dump for the Broadcom wl driver, it was determined that the affected boxes had a relocated SPROM. This patch fixes all systems that have reported this problem. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit ab8504259739d876befc79252e73d8017cc28db7 Author: Christoph Fritz Date: Fri May 28 10:45:59 2010 +0200 ssb: fix NULL ptr deref when pcihost_wrapper is used commit da1fdb02d9200ff28b6f3a380d21930335fe5429 upstream. Ethernet driver b44 does register ssb by it's pcihost_wrapper and doesn't set ssb_chipcommon. A check on this value introduced with commit d53cdbb94a52a920d5420ed64d986c3523a56743 and ea2db495f92ad2cf3301623e60cb95b4062bc484 triggers: BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [] ssb_is_sprom_available+0x16/0x30 Signed-off-by: Christoph Fritz Signed-off-by: John W. Linville Cc: Larry Finger Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 3385fd807f064c6a526af75ad9c0f82ea307aa52 Author: Rafał Miłecki Date: Wed Mar 31 21:59:21 2010 +0200 ssb: Look for SPROM at different offset on higher rev CC commit ea2db495f92ad2cf3301623e60cb95b4062bc484 upstream. Our offset handling becomes even a little more hackish now. For some reason I do not understand all offsets as inrelative. It assumes base offset is 0x1000 but it will work for now as we make offsets relative anyway by removing base 0x1000. Should be cleaner however. Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville Cc: Larry Finger Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit b748b7161ec6b8d6d9505917514ea543a186381f Author: John W. Linville Date: Wed Mar 31 21:39:35 2010 +0200 ssb: do not read SPROM if it does not exist commit d53cdbb94a52a920d5420ed64d986c3523a56743 upstream. Attempting to read registers that don't exist on the SSB bus can cause hangs on some boxes. At least some b43 devices are 'in the wild' that don't have SPROMs at all. When the SSB bus support loads, it attempts to read these (non-existant) SPROMs and causes hard hangs on the box -- no console output, etc. This patch adds some intelligence to determine whether or not the SPROM is present before attempting to read it. This avoids those hard hangs on those devices with no SPROM attached to their SSB bus. The SSB-attached devices (e.g. b43, et al.) won't work, but at least the box will survive to test further patches. :-) Signed-off-by: John W. Linville Signed-off-by: Rafał Miłecki Cc: Larry Finger Cc: Michael Buesch Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit c954f13da265f08c380bcac25981b430d61ab52f Author: Greg Kroah-Hartman Date: Fri Aug 6 10:22:56 2010 -0700 Revert "ssb: Handle Netbook devices where the SPROM address is changed" Turns out this isn't the best way to resolve this issue. The individual patches will be applied instead. Cc: Larry Finger Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 213a00cc8577fa34295cea260bc9818667784432 Author: Hugh Dickins Date: Tue Aug 24 22:44:12 2010 -0700 x86, mm: Fix CONFIG_VMSPLIT_1G and 2G_OPT trampoline commit b7d460897739e02f186425b7276e3fdb1595cea7 upstream. rc2 kernel crashes when booting second cpu on this CONFIG_VMSPLIT_2G_OPT laptop: whereas cloning from kernel to low mappings pgd range does need to limit by both KERNEL_PGD_PTRS and KERNEL_PGD_BOUNDARY, cloning kernel pgd range itself must not be limited by the smaller KERNEL_PGD_BOUNDARY. Signed-off-by: Hugh Dickins LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 1edd44f1d53900dfc7c7737eee19849d5d5373d4 Author: H. Peter Anvin Date: Wed Aug 18 11:42:23 2010 -0700 x86-32: Fix dummy trampoline-related inline stubs commit 8848a91068c018bc91f597038a0f41462a0f88a4 upstream. Fix dummy inline stubs for trampoline-related functions when no trampolines exist (until we get rid of the no-trampoline case entirely.) Signed-off-by: H. Peter Anvin Cc: Joerg Roedel Cc: Borislav Petkov LKML-Reference: <4C6C294D.3030404@zytor.com> Signed-off-by: Greg Kroah-Hartman commit 5b48d8480bad7420846b372e4eff9f3c0966d925 Author: Joerg Roedel Date: Mon Aug 16 14:38:33 2010 +0200 x86-32: Separate 1:1 pagetables from swapper_pg_dir commit fd89a137924e0710078c3ae855e7cec1c43cb845 upstream. This patch fixes machine crashes which occur when heavily exercising the CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by AMD Erratum 383 and result in a fatal machine check exception. Here's the scenario: 1. On 32-bit, the swapper_pg_dir page table is used as the initial page table for booting a secondary CPU. 2. To make this work, swapper_pg_dir needs a direct mapping of physical memory in it (the low mappings). By adding those low, large page (2M) mappings (PAE kernel), we create the necessary conditions for Erratum 383 to occur. 3. Other CPUs which do not participate in the off- and onlining game may use swapper_pg_dir while the low mappings are present (when leave_mm is called). For all steps below, the CPU referred to is a CPU that is using swapper_pg_dir, and not the CPU which is being onlined. 4. The presence of the low mappings in swapper_pg_dir can result in TLB entries for addresses below __PAGE_OFFSET to be established speculatively. These TLB entries are marked global and large. 5. When the CPU with such TLB entry switches to another page table, this TLB entry remains because it is global. 6. The process then generates an access to an address covered by the above TLB entry but there is a permission mismatch - the TLB entry covers a large global page not accessible to userspace. 7. Due to this permission mismatch a new 4kb, user TLB entry gets established. Further, Erratum 383 provides for a small window of time where both TLB entries are present. This results in an uncorrectable machine check exception signalling a TLB multimatch which panics the machine. There are two ways to fix this issue: 1. Always do a global TLB flush when a new cr3 is loaded and the old page table was swapper_pg_dir. I consider this a hack hard to understand and with performance implications 2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit does. This patch implements solution 2. It introduces a trampoline_pg_dir which has the same layout as swapper_pg_dir with low_mappings. This page table is used as the initial page table of the booting CPU. Later in the bringup process, it switches to swapper_pg_dir and does a global TLB flush. This fixes the crashes in our test cases. -v2: switch to swapper_pg_dir right after entering start_secondary() so that we are able to access percpu data which might not be mapped in the trampoline page table. Signed-off-by: Joerg Roedel LKML-Reference: <20100816123833.GB28147@aftab> Signed-off-by: Borislav Petkov Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit fe6595caaea6d84fd1290df4dfe762235bd7662b Author: Roland McGrath Date: Tue Sep 7 19:37:06 2010 -0700 execve: make responsive to SIGKILL with large arguments commit 9aea5a65aa7a1af9a4236dfaeb0088f1624f9919 upstream. An execve with a very large total of argument/environment strings can take a really long time in the execve system call. It runs uninterruptibly to count and copy all the strings. This change makes it abort the exec quickly if sent a SIGKILL. Note that this is the conservative change, to interrupt only for SIGKILL, by using fatal_signal_pending(). It would be perfectly correct semantics to let any signal interrupt the string-copying in execve, i.e. use signal_pending() instead of fatal_signal_pending(). We'll save that change for later, since it could have user-visible consequences, such as having a timer set too quickly make it so that an execve can never complete, though it always happened to work before. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Cc: Chuck Ebbert Signed-off-by: Linus Torvalds commit 43bcb928c27f7a0fc53b95fac85354ee73b6cd1b Author: Roland McGrath Date: Tue Sep 7 19:36:28 2010 -0700 execve: improve interactivity with large arguments commit 7993bc1f4663c0db67bb8f0d98e6678145b387cd upstream. This adds a preemption point during the copying of the argument and environment strings for execve, in copy_strings(). There is already a preemption point in the count() loop, so this doesn't add any new points in the abstract sense. When the total argument+environment strings are very large, the time spent copying them can be much more than a normal user time slice. So this change improves the interactivity of the rest of the system when one process is doing an execve with very large arguments. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit b48366b5f84c8a52dca99b241c444793ec6dd771 Author: Roland McGrath Date: Tue Sep 7 19:35:49 2010 -0700 setup_arg_pages: diagnose excessive argument size commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 upstream. The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not check the size of the argument/environment area on the stack. When it is unworkably large, shift_arg_pages() hits its BUG_ON. This is exploitable with a very large RLIMIT_STACK limit, to create a crash pretty easily. Check that the initial stack is not too large to make it possible to map in any executable. We're not checking that the actual executable (or intepreter, for binfmt_elf) will fit. So those mappings might clobber part of the initial stack mapping. But that is just userland lossage that userland made happen, not a kernel problem. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 670bcc4109282d6e9c8b1774cf507296e156dd41 Author: Jacob Pan Date: Wed May 19 12:01:23 2010 -0700 x86: detect scattered cpuid features earlier commit 1dedefd1a066a795a87afca9c0236e1a94de9bf6 upstream. Some extra CPU features such as ARAT is needed in early boot so that x86_init function pointers can be set up properly. http://lkml.org/lkml/2010/5/18/519 At start_kernel() level, this patch moves init_scattered_cpuid_features() from check_bugs() to setup_arch() -> early_cpu_init() which is earlier than platform specific x86_init layer setup. Suggested by HPA. Signed-off-by: Jacob Pan LKML-Reference: <1274295685-6774-2-git-send-email-jacob.jun.pan@linux.intel.com> Acked-by: Thomas Gleixner Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit f115819a79eb3a8a39aadcf6f0de0e8ee3a94f65 Author: Zhang Rui Date: Tue Sep 28 22:48:55 2010 -0400 ACPI: Disable Windows Vista compatibility for Toshiba P305D commit 337279ce3aa85d81d34c0f837d1c204df105103b upstream. Disable the Windows Vista (SP1) compatibility for Toshiba P305D. http://bugzilla.kernel.org/show_bug.cgi?id=14736 Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f664e4a32dc900c8845de24672bbcde93bcb9771 Author: Len Brown Date: Tue Sep 28 17:51:51 2010 -0400 ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355 commit 7a1d602f5fc35d14907b7da98d5627acb69589d1 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=12641 Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 05f7676dc3559c2b9061fda4e44c085a8d32fb05 Author: Len Brown Date: Fri Sep 24 21:02:27 2010 -0400 intel_idle: PCI quirk to prevent Lenovo Ideapad s10-3 boot hang commit 4731fdcf6f7bdab3e369a3f844d4ea4d4017284d upstream. When the Lenovo Ideapad S10-3 is booted with HT enabled, it hits a boot hang in the intel_idle driver. This occurs when entering ATM-C4 for the first time, unless BM_STS is first cleared. acpi_idle doesn't see this because it first checks and clears BM_STS, but it would hit the same hang if that check were disabled. http://bugs.meego.com/show_bug.cgi?id=7093 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/634702 Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 91b3824071a9dc7ca4bb8c41bda045e223837564 Author: Colin Ian King Date: Mon Aug 2 15:14:43 2010 +0000 ACPI: enable repeated PCIEXP wakeup by clearing PCIEXP_WAKE_STS on resume commit 573b638158029898caf9470c8214b7ddd29751e3 upstream. Section 4.7.3.1.1 (PM1 Status Registers) of version 4.0 of the ACPI spec concerning PCIEXP_WAKE_STS points out in in the final note field in table 4-11 that if this bit is set to 1 and the system is put into a sleeping state then the system will not automatically wake. This bit gets set by hardware to indicate that the system woke up due to a PCI Express wakeup event, so clear it during acpi_hw_clear_acpi_status() calls to enable subsequent resumes to work. BugLink: http://bugs.launchpad.net/bugs/613381 Signed-off-by: Colin Ian King Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 469bc41db02a457a5661c9f47760e6ac94cc91dd Author: Paul Fertser Date: Mon Oct 11 15:45:35 2010 -0700 b44: fix carrier detection on bind commit bcf64aa379fcadd074449cbf0c049da70071b06f upstream. For carrier detection to work properly when binding the driver with a cable unplugged, netif_carrier_off() should be called after register_netdev(), not before. Signed-off-by: Paul Fertser Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b19dda10c483c0a4fa02310653a441e413b98397 Author: Ben Hutchings Date: Fri Oct 15 04:36:53 2010 +0100 r6040: Fix multicast list iteration when hash filter is used This was fixed in mainline by the interface change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249. After walking the multicast list to set up the hash filter, this function will walk off the end of the list when filling the exact-match entries. This was fixed in mainline by the interface change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249. Reported-by: spamalot@hispeed.ch Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355 Reported-by: Jason Heeris Reference: http://bugs.debian.org/600155 Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 8a194c449871648f25c56ec050e6948d19a7d78a Author: Florian Fainelli Date: Wed Apr 7 16:50:58 2010 -0700 r6040: fix r6040_multicast_list commit 3bcf8229a8c49769e48d3e0bd1e20d8e003f8106 upstream. As reported in , r6040_ multicast_list currently crashes. This is due a wrong maximum of multicast entries. This patch fixes the following issues with multicast: - number of maximum entries if off-by-one (4 instead of 3) - the writing of the hash table index is not necessary and leads to invalid values being written into the MCR1 register, so the MAC is simply put in a non coherent state - when we exceed the maximum number of mutlticast address, writing the broadcast address should be done in registers MID_1{L,M,H} instead of MID_O{L,M,H}, otherwise we would loose the adapter's MAC address [bwh: Adjust for 2.6.32; should also apply to 2.6.27] Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 95e6f3cf39fc0d337c0f792af92a3347ceba3a3d Author: FUJITA Tomonori Date: Fri Sep 17 00:46:42 2010 +0900 bsg: fix incorrect device_status value commit 478971600e47cb83ff2d3c63c5c24f2b04b0d6a1 upstream. bsg incorrectly returns sg's masked_status value for device_status. [jejb: fix up expression logic] Reported-by: Douglas Gilbert Signed-off-by: FUJITA Tomonori Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7ee72472c6fe2994c9195fb3da665aa4ec1d9928 Author: Ulrich Weber Date: Tue Oct 5 13:46:19 2010 +0200 xfrm4: strip ECN and IP Precedence bits in policy lookup [ Upstream commit 94e2238969e89f5112297ad2a00103089dde7e8f ] dont compare ECN and IP Precedence bits in find_bundle and use ECN bit stripped TOS value in xfrm_lookup Signed-off-by: Ulrich Weber Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a9108eedb9f2831904f9cb1250aabd4e3413fb02 Author: Tom Marshall Date: Mon Sep 20 15:42:05 2010 -0700 tcp: Fix race in tcp_poll [ Upstream commit a4d258036ed9b2a1811c3670c6099203a0f284a0 ] If a RST comes in immediately after checking sk->sk_err, tcp_poll will return POLLIN but not POLLOUT. Fix this by checking sk->sk_err at the end of tcp_poll. Additionally, ensure the correct order of operations on SMP machines with memory barriers. Signed-off-by: Tom Marshall Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb9ec4584b3afa1ab0a9b8d6060fe08a3290ea4d Author: David S. Miller Date: Mon Sep 27 20:24:54 2010 -0700 tcp: Fix >4GB writes on 64-bit. [ Upstream commit 01db403cf99f739f86903314a489fb420e0e254f ] Fixes kernel bugzilla #16603 tcp_sendmsg() truncates iov_len to an 'int' which a 4GB write to write zero bytes, for example. There is also the problem higher up of how verify_iovec() works. It wants to prevent the total length from looking like an error return value. However it does this using 'int', but syscalls return 'long' (and thus signed 64-bit on 64-bit machines). So it could trigger false-positives on 64-bit as written. So fix it to use 'long'. Reported-by: Olaf Bonorden Reported-by: Daniel Büse Reported-by: Andrew Morton Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ab274fcfec82a91a6232ac71d620b62beb80ef78 Author: David S. Miller Date: Mon Sep 20 15:40:35 2010 -0700 rose: Fix signedness issues wrt. digi count. [ Upstream commit 9828e6e6e3f19efcb476c567b9999891d051f52f ] Just use explicit casts, since we really can't change the types of structures exported to userspace which have been around for 15 years or so. Reported-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f6d37e73dcf0ba416ccf98fb4edc84509d097a1c Author: Kumar Sanghvi Date: Mon Sep 27 23:10:42 2010 +0000 Phonet: Correct header retrieval after pskb_may_pull [ Upstream commit a91e7d471e2e384035b9746ea707ccdcd353f5dd ] Retrieve the header after doing pskb_may_pull since, pskb_may_pull could change the buffer structure. This is based on the comment given by Eric Dumazet on Phonet Pipe controller patch for a similar problem. Signed-off-by: Kumar Sanghvi Acked-by: Linus Walleij Acked-by: Eric Dumazet Acked-by: Rémi Denis-Courmont Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40bb77169fefe5826d4f54fcc9c40a4fc22bf3e9 Author: Eric Dumazet Date: Tue Sep 21 13:04:04 2010 -0700 netxen: dont set skb->truesize [ Upstream commit 7e96dc7045bff8758804b047c0dfb6868f182500 ] skb->truesize is set in core network. Dont change it unless dealing with fragments. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1b592fd2ff0e08720e671afada80c753f7d8b202 Author: Nagendra Tomar Date: Sat Oct 2 23:45:06 2010 +0000 net: Fix the condition passed to sk_wait_event() [ Upstream commit 482964e56e1320cb7952faa1932d8ecf59c4bf75 ] This patch fixes the condition (3rd arg) passed to sk_wait_event() in sk_stream_wait_memory(). The incorrect check in sk_stream_wait_memory() causes the following soft lockup in tcp_sendmsg() when the global tcp memory pool has exhausted. >>> snip <<< localhost kernel: BUG: soft lockup - CPU#3 stuck for 11s! [sshd:6429] localhost kernel: CPU 3: localhost kernel: RIP: 0010:[sk_stream_wait_memory+0xcd/0x200] [sk_stream_wait_memory+0xcd/0x200] sk_stream_wait_memory+0xcd/0x200 localhost kernel: localhost kernel: Call Trace: localhost kernel: [sk_stream_wait_memory+0x1b1/0x200] sk_stream_wait_memory+0x1b1/0x200 localhost kernel: [] autoremove_wake_function+0x0/0x40 localhost kernel: [ipv6:tcp_sendmsg+0x6e6/0xe90] tcp_sendmsg+0x6e6/0xce0 localhost kernel: [sock_aio_write+0x126/0x140] sock_aio_write+0x126/0x140 localhost kernel: [xfs:do_sync_write+0xf1/0x130] do_sync_write+0xf1/0x130 localhost kernel: [] autoremove_wake_function+0x0/0x40 localhost kernel: [hrtimer_start+0xe3/0x170] hrtimer_start+0xe3/0x170 localhost kernel: [vfs_write+0x185/0x190] vfs_write+0x185/0x190 localhost kernel: [sys_write+0x50/0x90] sys_write+0x50/0x90 localhost kernel: [system_call+0x7e/0x83] system_call+0x7e/0x83 >>> snip <<< What is happening is, that the sk_wait_event() condition passed from sk_stream_wait_memory() evaluates to true for the case of tcp global memory exhaustion. This is because both sk_stream_memory_free() and vm_wait are true which causes sk_wait_event() to *not* call schedule_timeout(). Hence sk_stream_wait_memory() returns immediately to the caller w/o sleeping. This causes the caller to again try allocation, which again fails and again calls sk_stream_wait_memory(), and so on. [ Bug introduced by commit c1cbe4b7ad0bc4b1d98ea708a3fecb7362aa4088 ("[NET]: Avoid atomic xchg() for non-error case") -DaveM ] Signed-off-by: Nagendra Singh Tomar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 76eabea8a1b3384087c908499c206b72b9cf92d0 Author: Maciej Żenczykowski Date: Sun Oct 3 14:49:00 2010 -0700 net: Fix IPv6 PMTU disc. w/ asymmetric routes [ Upstream commit ae878ae280bea286ff2b1e1cb6e609dd8cb4501d ] Signed-off-by: Maciej Żenczykowski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 487a1f7338ff740bde0d15f97c44b7b8029cc9c7 Author: Kees Cook Date: Mon Oct 11 12:23:25 2010 -0700 net: clear heap allocations for privileged ethtool actions [ Upstream commit b00916b189d13a615ff05c9242201135992fcda3 ] Several other ethtool functions leave heap uncleared (potentially) by drivers. Some interfaces appear safe (eeprom, etc), in that the sizes are well controlled. In some situations (e.g. unchecked error conditions), the heap will remain unchanged in areas before copying back to userspace. Note that these are less of an issue since these all require CAP_NET_ADMIN. Cc: stable@kernel.org Signed-off-by: Kees Cook Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 217e4b61e6b5e14f950b5353ba261d9cd8142186 Author: Jianzhao Wang Date: Wed Sep 8 14:35:43 2010 -0700 net: blackhole route should always be recalculated [ Upstream commit ae2688d59b5f861dc70a091d003773975d2ae7fb ] Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error triggered by IKE for example), hence this kind of route is always temporary and so we should check if a better route exists for next packets. Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92. Signed-off-by: Jianzhao Wang Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 107ed4220f8884e3ac026636dfc19c45b8fc990a Author: Eric Dumazet Date: Tue Sep 21 08:47:45 2010 +0000 ip: fix truesize mismatch in ip fragmentation [ Upstream commit 3d13008e7345fa7a79d8f6438150dc15d6ba6e9d ] Special care should be taken when slow path is hit in ip_fragment() : When walking through frags, we transfert truesize ownership from skb to frags. Then if we hit a slow_path condition, we must undo this or risk uncharging frags->truesize twice, and in the end, having negative socket sk_wmem_alloc counter, or even freeing socket sooner than expected. Many thanks to Nick Bowler, who provided a very clean bug report and test program. Thanks to Jarek for reviewing my first patch and providing a V2 While Nick bisection pointed to commit 2b85a34e911 (net: No more expensive sock_hold()/sock_put() on each tx), underlying bug is older (2.6.12-rc5) A side effect is to extend work done in commit b2722b1c3a893e (ip_fragment: also adjust skb->truesize for packets not owned by a socket) to ipv6 as well. Reported-and-bisected-by: Nick Bowler Tested-by: Nick Bowler Signed-off-by: Eric Dumazet CC: Jarek Poplawski CC: Patrick McHardy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b4ae8715e06c5e10bb6f86bd3085e5c3236ed81e Author: Dave Airlie Date: Sat Sep 25 17:45:50 2010 +1000 drm/radeon: fix PCI ID 5657 to be an RV410 commit f459ffbdfd04edb4a8ce6eea33170eb057a5e695 upstream. fixes https://bugzilla.kernel.org/show_bug.cgi?id=19012 Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 68a10eccaf635730f524e56f1eb49fb1f819968e Author: Linus Torvalds Date: Fri Oct 15 11:09:28 2010 -0700 De-pessimize rds_page_copy_user commit 799c10559d60f159ab2232203f222f18fa3c4a5f upstream. Don't try to "optimize" rds_page_copy_user() by using kmap_atomic() and the unsafe atomic user mode accessor functions. It's actually slower than the straightforward code on any reasonable modern CPU. Back when the code was written (although probably not by the time it was actually merged, though), 32-bit x86 may have been the dominant architecture. And there kmap_atomic() can be a lot faster than kmap() (unless you have very good locality, in which case the virtual address caching by kmap() can overcome all the downsides). But these days, x86-64 may not be more populous, but it's getting there (and if you care about performance, it's definitely already there - you'd have upgraded your CPU's already in the last few years). And on x86-64, the non-kmap_atomic() version is faster, simply because the code is simpler and doesn't have the "re-try page fault" case. People with old hardware are not likely to care about RDS anyway, and the optimization for the 32-bit case is simply buggy, since it doesn't verify the user addresses properly. Reported-by: Dan Rosenberg Acked-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4a0dc321316356feb2613ac57df087aebdb2ddc7 Author: Borislav Petkov Date: Fri Oct 8 12:08:34 2010 +0200 x86, AMD, MCE thresholding: Fix the MCi_MISCj iteration order commit 6dcbfe4f0b4e17e289d56fa534b7ce5a6b7f63a3 upstream. This fixes possible cases of not collecting valid error info in the MCE error thresholding groups on F10h hardware. The current code contains a subtle problem of checking only the Valid bit of MSR0000_0413 (which is MC4_MISC0 - DRAM thresholding group) in its first iteration and breaking out if the bit is cleared. But (!), this MSR contains an offset value, BlkPtr[31:24], which points to the remaining MSRs in this thresholding group which might contain valid information too. But if we bail out only after we checked the valid bit in the first MSR and not the block pointer too, we miss that other information. The thing is, MC4_MISC0[BlkPtr] is not predicated on MCi_STATUS[MiscV] or MC4_MISC0[Valid] and should be checked prior to iterating over the MCI_MISCj thresholding group, irrespective of the MC4_MISC0[Valid] setting. Signed-off-by: Borislav Petkov Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1e103c2da78c3e946c72910f98f6b38268705be8 Author: Yinghai Lu Date: Sun Oct 10 19:52:15 2010 -0700 x86, numa: For each node, register the memory blocks actually used commit 73cf624d029d776a33d0a80c695485b3f9b36231 upstream. Russ reported SGI UV is broken recently. He said: | The SRAT table shows that memory range is spread over two nodes. | | SRAT: Node 0 PXM 0 100000000-800000000 | SRAT: Node 1 PXM 1 800000000-1000000000 | SRAT: Node 0 PXM 0 1000000000-1080000000 | |Previously, the kernel early_node_map[] would show three entries |with the proper node. | |[ 0.000000] 0: 0x00100000 -> 0x00800000 |[ 0.000000] 1: 0x00800000 -> 0x01000000 |[ 0.000000] 0: 0x01000000 -> 0x01080000 | |The problem is recent community kernel early_node_map[] shows |only two entries with the node 0 entry overlapping the node 1 |entry. | | 0: 0x00100000 -> 0x01080000 | 1: 0x00800000 -> 0x01000000 After looking at the changelog, Found out that it has been broken for a while by following commit |commit 8716273caef7f55f39fe4fc6c69c5f9f197f41f1 |Author: David Rientjes |Date: Fri Sep 25 15:20:04 2009 -0700 | | x86: Export srat physical topology Before that commit, register_active_regions() is called for every SRAT memory entry right away. Use nodememblk_range[] instead of nodes[] in order to make sure we capture the actual memory blocks registered with each node. nodes[] contains an extended range which spans all memory regions associated with a node, but that does not mean that all the memory in between are included. Reported-by: Russ Anderson Tested-by: Russ Anderson Signed-off-by: Yinghai Lu LKML-Reference: <4CB27BDF.5000800@kernel.org> Acked-by: David Rientjes Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 3220aa132790e798b2ebb3b43aa6545d25f24b8e Author: Luca Tettamanti Date: Wed Sep 22 10:41:58 2010 +0000 atl1: fix resume commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream. adapter->cmb.cmb is initialized when the device is opened and freed when it's closed. Accessing it unconditionally during resume results either in a crash (NULL pointer dereference, when the interface has not been opened yet) or data corruption (when the interface has been used and brought down adapter->cmb.cmb points to a deallocated memory area). Signed-off-by: Luca Tettamanti Acked-by: Chris Snook Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 99d1bac7375639ceb89e20f5a56b000a2fbf434b Author: Johannes Berg Date: Fri Sep 17 00:38:25 2010 +0200 wext: fix potential private ioctl memory content leak commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream. When a driver doesn't fill the entire buffer, old heap contents may remain, and if it also doesn't update the length properly, this old heap content will be copied back to userspace. It is very unlikely that this happens in any of the drivers using private ioctls since it would show up as junk being reported by iwpriv, but it seems better to be safe here, so use kzalloc. Reported-by: Jeff Mahoney Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 027e59fe6262fc24b38b5a734029e5289bb0b9f6 Author: Joel Becker Date: Wed Sep 29 17:33:05 2010 -0700 ocfs2: Don't walk off the end of fast symlinks. commit 1fc8a117865b54590acd773a55fbac9221b018f0 upstream. ocfs2 fast symlinks are NUL terminated strings stored inline in the inode data area. However, disk corruption or a local attacker could, in theory, remove that NUL. Because we're using strlen() (my fault, introduced in a731d1 when removing vfs_follow_link()), we could walk off the end of that string. Signed-off-by: Joel Becker Signed-off-by: Greg Kroah-Hartman commit 98d4499fbe16dd02e3846b2a05c07490e8aeeb33 Author: Frederic Weisbecker Date: Thu Sep 30 15:15:38 2010 -0700 reiserfs: fix unwanted reiserfs lock recursion commit 9d8117e72bf453dd9d85e0cd322ce4a0f8bccbc0 upstream. Prevent from recursively locking the reiserfs lock in reiserfs_unpack() because we may call journal_begin() that requires the lock to be taken only once, otherwise it won't be able to release the lock while taking other mutexes, ending up in inverted dependencies between the journal mutex and the reiserfs lock for example. This fixes: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.35.4.4a #3 ------------------------------------------------------- lilo/1620 is trying to acquire lock: (&journal->j_mutex){+.+...}, at: [] do_journal_begin_r+0x7f/0x340 [reiserfs] but task is already holding lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [] lock_acquire+0x67/0x80 [] __mutex_lock_common+0x4d/0x410 [] mutex_lock_nested+0x18/0x20 [] reiserfs_write_lock+0x28/0x40 [reiserfs] [] do_journal_begin_r+0x86/0x340 [reiserfs] [] journal_begin+0x77/0x140 [reiserfs] [] reiserfs_remount+0x224/0x530 [reiserfs] [] do_remount_sb+0x60/0x110 [] do_mount+0x625/0x790 [] sys_mount+0x84/0xb0 [] syscall_call+0x7/0xb -> #0 (&journal->j_mutex){+.+...}: [] __lock_acquire+0x1026/0x1180 [] lock_acquire+0x67/0x80 [] __mutex_lock_common+0x4d/0x410 [] mutex_lock_nested+0x18/0x20 [] do_journal_begin_r+0x7f/0x340 [reiserfs] [] journal_begin+0x77/0x140 [reiserfs] [] reiserfs_persistent_transaction+0x41/0x90 [reiserfs] [] reiserfs_get_block+0x22c/0x1530 [reiserfs] [] __block_prepare_write+0x1bb/0x3a0 [] block_prepare_write+0x26/0x40 [] reiserfs_prepare_write+0x88/0x170 [reiserfs] [] reiserfs_unpack+0xe6/0x120 [reiserfs] [] reiserfs_ioctl+0x272/0x320 [reiserfs] [] vfs_ioctl+0x28/0xa0 [] do_vfs_ioctl+0x32d/0x5c0 [] sys_ioctl+0x63/0x70 [] syscall_call+0x7/0xb other info that might help us debug this: 2 locks held by lilo/1620: #0: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [] reiserfs_unpack+0x6a/0x120 [reiserfs] #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs] stack backtrace: Pid: 1620, comm: lilo Not tainted 2.6.35.4.4a #3 Call Trace: [] __lock_acquire+0x1026/0x1180 [] lock_acquire+0x67/0x80 [] __mutex_lock_common+0x4d/0x410 [] mutex_lock_nested+0x18/0x20 [] do_journal_begin_r+0x7f/0x340 [reiserfs] [] journal_begin+0x77/0x140 [reiserfs] [] reiserfs_persistent_transaction+0x41/0x90 [reiserfs] [] reiserfs_get_block+0x22c/0x1530 [reiserfs] [] __block_prepare_write+0x1bb/0x3a0 [] block_prepare_write+0x26/0x40 [] reiserfs_prepare_write+0x88/0x170 [reiserfs] [] reiserfs_unpack+0xe6/0x120 [reiserfs] [] reiserfs_ioctl+0x272/0x320 [reiserfs] [] vfs_ioctl+0x28/0xa0 [] do_vfs_ioctl+0x32d/0x5c0 [] sys_ioctl+0x63/0x70 [] syscall_call+0x7/0xb Reported-by: Jarek Poplawski Tested-by: Jarek Poplawski Signed-off-by: Frederic Weisbecker Cc: Jeff Mahoney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 34f63f1b1791a97ab6d90de421c4091341a02cb4 Author: Frederic Weisbecker Date: Thu Sep 30 15:15:37 2010 -0700 reiserfs: fix dependency inversion between inode and reiserfs mutexes commit 3f259d092c7a2fdf217823e8f1838530adb0cdb0 upstream. The reiserfs mutex already depends on the inode mutex, so we can't lock the inode mutex in reiserfs_unpack() without using the safe locking API, because reiserfs_unpack() is always called with the reiserfs mutex locked. This fixes: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.35c #13 ------------------------------------------------------- lilo/1606 is trying to acquire lock: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [] reiserfs_unpack+0x60/0x110 [reiserfs] but task is already holding lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [] lock_acquire+0x67/0x80 [] __mutex_lock_common+0x4d/0x410 [] mutex_lock_nested+0x18/0x20 [] reiserfs_write_lock+0x28/0x40 [reiserfs] [] reiserfs_lookup_privroot+0x2a/0x90 [reiserfs] [] reiserfs_fill_super+0x941/0xe60 [reiserfs] [] get_sb_bdev+0x117/0x170 [] get_super_block+0x21/0x30 [reiserfs] [] vfs_kern_mount+0x6a/0x1b0 [] do_kern_mount+0x39/0xe0 [] do_mount+0x340/0x790 [] sys_mount+0x84/0xb0 [] syscall_call+0x7/0xb -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}: [] __lock_acquire+0x1026/0x1180 [] lock_acquire+0x67/0x80 [] __mutex_lock_common+0x4d/0x410 [] mutex_lock_nested+0x18/0x20 [] reiserfs_unpack+0x60/0x110 [reiserfs] [] reiserfs_ioctl+0x272/0x320 [reiserfs] [] vfs_ioctl+0x28/0xa0 [] do_vfs_ioctl+0x32d/0x5c0 [] sys_ioctl+0x63/0x70 [] syscall_call+0x7/0xb other info that might help us debug this: 1 lock held by lilo/1606: #0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs] stack backtrace: Pid: 1606, comm: lilo Not tainted 2.6.35c #13 Call Trace: [] __lock_acquire+0x1026/0x1180 [] lock_acquire+0x67/0x80 [] __mutex_lock_common+0x4d/0x410 [] mutex_lock_nested+0x18/0x20 [] reiserfs_unpack+0x60/0x110 [reiserfs] [] reiserfs_ioctl+0x272/0x320 [reiserfs] [] vfs_ioctl+0x28/0xa0 [] do_vfs_ioctl+0x32d/0x5c0 [] sys_ioctl+0x63/0x70 [] syscall_call+0x7/0xb Reported-by: Jarek Poplawski Tested-by: Jarek Poplawski Signed-off-by: Frederic Weisbecker Cc: Jeff Mahoney Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 40086df2f497219b5fe9039a6518f61739c5ce58 Author: Salman Qazi Date: Tue Oct 12 07:25:19 2010 -0700 hrtimer: Preserve timer state in remove_hrtimer() commit f13d4f979c518119bba5439dd2364d76d31dcd3f upstream. The race is described as follows: CPU X CPU Y remove_hrtimer // state & QUEUED == 0 timer->state = CALLBACK unlock timer base timer->f(n) //very long hrtimer_start lock timer base remove_hrtimer // no effect hrtimer_enqueue timer->state = CALLBACK | QUEUED unlock timer base hrtimer_start lock timer base remove_hrtimer mode = INACTIVE // CALLBACK bit lost! switch_hrtimer_base CALLBACK bit not set: timer->base changes to a different CPU. lock this CPU's timer base The bug was introduced with commit ca109491f (hrtimer: removing all ur callback modes) in 2.6.29 [ tglx: Feed new state via local variable and add a comment. ] Signed-off-by: Salman Qazi Cc: akpm@linux-foundation.org Cc: Peter Zijlstra LKML-Reference: <20101012142351.8485.21823.stgit@dungbeetle.mtv.corp.google.com> Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 518fcb0dc96dc4d16df66a768edcf0e2d844364d Author: Simon Guinot Date: Fri Sep 17 23:33:51 2010 +0200 dmaengine: fix interrupt clearing for mv_xor commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream. When using simultaneously the two DMA channels on a same engine, some transfers are never completed. For example, an endless lock can occur while writing heavily on a RAID5 array (with async-tx offload support enabled). Note that this issue can also be reproduced by using the DMA test client. On a same engine, the interrupt cause register is shared between two DMA channels. This patch make sure that the cause bit is only cleared for the requested channel. Signed-off-by: Simon Guinot Tested-by: Luc Saillard Acked-by: saeed bishara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit aa9600084478249072bc5a40449b967d8c4466f8 Author: Steven Rostedt Date: Tue Oct 12 12:06:43 2010 -0400 ring-buffer: Fix typo of time extends per page commit d01343244abdedd18303d0323b518ed9cdcb1988 upstream. Time stamps for the ring buffer are created by the difference between two events. Each page of the ring buffer holds a full 64 bit timestamp. Each event has a 27 bit delta stamp from the last event. The unit of time is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events happen more than 134 milliseconds apart, a time extend is inserted to add more bits for the delta. The time extend has 59 bits, which is good for ~18 years. Currently the time extend is committed separately from the event. If an event is discarded before it is committed, due to filtering, the time extend still exists. If all events are being filtered, then after ~134 milliseconds a new time extend will be added to the buffer. This can only happen till the end of the page. Since each page holds a full timestamp, there is no reason to add a time extend to the beginning of a page. Time extends can only fill a page that has actual data at the beginning, so there is no fear that time extends will fill more than a page without any data. When reading an event, a loop is made to skip over time extends since they are only used to maintain the time stamp and are never given to the caller. As a paranoid check to prevent the loop running forever, with the knowledge that time extends may only fill a page, a check is made that tests the iteration of the loop, and if the iteration is more than the number of time extends that can fit in a page a warning is printed and the ring buffer is disabled (all of ftrace is also disabled with it). There is another event type that is called a TIMESTAMP which can hold 64 bits of data in the theoretical case that two events happen 18 years apart. This code has not been implemented, but the name of this event exists, as well as the structure for it. The size of a TIMESTAMP is 16 bytes, where as a time extend is only 8 bytes. The macro used to calculate how many time extends can fit on a page used the TIMESTAMP size instead of the time extend size cutting the amount in half. The following test case can easily trigger the warning since we only need to have half the page filled with time extends to trigger the warning: # cd /sys/kernel/debug/tracing/ # echo function > current_tracer # echo 'common_pid < 0' > events/ftrace/function/filter # echo > trace # echo 1 > trace_marker # sleep 120 # cat trace Enabling the function tracer and then setting the filter to only trace functions where the process id is negative (no events), then clearing the trace buffer to ensure that we have nothing in the buffer, then write to trace_marker to add an event to the beginning of a page, sleep for 2 minutes (only 35 seconds is probably needed, but this guarantees the bug), and then finally reading the trace which will trigger the bug. This patch fixes the typo and prevents the false positive of that warning. Reported-by: Hans J. Koch Tested-by: Hans J. Koch Cc: Thomas Gleixner Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a56f2b573a488d3d7a1a41e50711347862fa1f83 Author: Tejun Heo Date: Fri Oct 15 12:56:21 2010 +0200 ubd: fix incorrect sector handling during request restart commit 47526903feb52f4c26a6350370bdf74e337fcdb1 upstream. Commit f81f2f7c (ubd: drop unnecessary rq->sector manipulation) dropped request->sector manipulation in preparation for global request handling cleanup; unfortunately, it incorrectly assumed that the updated sector wasn't being used. ubd tries to issue as many requests as possible to io_thread. When issuing fails due to memory pressure or other reasons, the device is put on the restart list and issuing stops. On IO completion, devices on the restart list are scanned and IO issuing is restarted. ubd issues IOs sg-by-sg and issuing can be stopped in the middle of a request, so each device on the restart queue needs to remember where to restart in its current request. ubd needs to keep track of the issue position itself because, * blk_rq_pos(req) is now updated by the block layer to keep track of _completion_ position. * Multiple io_req's for the current request may be in flight, so it's difficult to tell where blk_rq_pos(req) currently is. Add ubd->rq_pos to keep track of the issue position and use it to correctly restart io_req issue. Signed-off-by: Tejun Heo Reported-by: Richard Weinberger Tested-by: Richard Weinberger Tested-by: Chris Frey Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8b6487c4d921d5e4dc061209364222c9848deae5 Author: Thomas Gleixner Date: Tue Sep 28 20:57:19 2010 +0200 x86, irq: Plug memory leak in sparse irq commit 1cf180c94e9166cda083ff65333883ab3648e852 upstream. free_irq_cfg() is not freeing the cpumask_vars in irq_cfg. Fixing this triggers a use after free caused by the fact that copying struct irq_cfg is done with memcpy, which copies the pointer not the cpumask. Fix both places. Signed-off-by: Thomas Gleixner Cc: Yinghai Lu LKML-Reference: Signed-off-by: Thomas Gleixner Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 79f991c4c845efef76a5481bb0e040915e972d0e Author: Thomas Gleixner Date: Tue Sep 28 23:20:23 2010 +0200 x86, hpet: Fix bogus error check in hpet_assign_irq() commit 021989622810b02aab4b24f91e1f5ada2b654579 upstream. create_irq() returns -1 if the interrupt allocation failed, but the code checks for irq == 0. Use create_irq_nr() instead. Signed-off-by: Thomas Gleixner Cc: Venkatesh Pallipadi LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 3f10d217f3744132e9f896d7d4b5cedf7ee2e821 Author: Johannes Berg Date: Fri Sep 24 11:20:47 2010 +0200 mac80211: fix use-after-free commit cd87a2d3a33d75a646f1aa1aa2ee5bf712d6f963 upstream. commit 8c0c709eea5cbab97fb464cd68b06f24acc58ee1 Author: Johannes Berg Date: Wed Nov 25 17:46:15 2009 +0100 mac80211: move cmntr flag out of rx flags moved the CMTR flag into the skb's status, and in doing so introduced a use-after-free -- when the skb has been handed to cooked monitors the status setting will touch now invalid memory. Additionally, moving it there has effectively discarded the optimisation -- since the bit is only ever set on freed SKBs, and those were a copy, it could never be checked. For the current release, fixing this properly is a bit too involved, so let's just remove the problematic code and leave userspace with one copy of each frame for each virtual interface. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2ac21c50ae99b349fff21b8c49d12b3867752f4b Author: Kenneth Waters Date: Tue Sep 21 00:58:23 2010 -0700 Input: joydev - fix JSIOCSAXMAP ioctl commit d2520a426dc3033c00077e923a553fc6c98c7564 upstream. Fixed JSIOCSAXMAP ioctl to update absmap, the map from hardware axis to event axis in addition to abspam. This fixes a regression introduced by 999b874f. Signed-off-by: Kenneth Waters Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit b73a9cba501f233a005392d971208033c6fbef0d Author: Mauro Carvalho Chehab Date: Sat Sep 11 11:37:51 2010 -0300 V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0) commit c10469c637602c2385e2993d8c730cc44fd47d23 upstream. As reported by: Carlos Americo Domiciano : [ 220.033500] cx231xx v4l2 driver loaded. [ 220.033571] cx231xx #0: New device Conexant Corporation Polaris AV Capturb @ 480 Mbps (1554:5010) with 6 interfaces [ 220.033577] cx231xx #0: registering interface 0 [ 220.033591] cx231xx #0: registering interface 1 [ 220.033654] cx231xx #0: registering interface 6 [ 220.033910] cx231xx #0: Identified as Unknown CX231xx video grabber (card=0) [ 220.033946] BUG: unable to handle kernel NULL pointer dereference at (null) [ 220.033955] IP: [] cx231xx_pre_card_setup+0x5d/0xb0 [cx231xx] Thanks-to: Carlos Americo Domiciano Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ef40b724e656c3e7dd46b7b57f1f735baf4cd074 Author: Linus Torvalds Date: Fri Oct 15 11:12:38 2010 -0700 v4l1: fix 32-bit compat microcode loading translation commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream. The compat code for the VIDIOCSMICROCODE ioctl is totally buggered. It's only used by the VIDEO_STRADIS driver, and that one is scheduled to staging and eventually removed unless somebody steps up to maintain it (at which point it should use request_firmware() rather than some magic ioctl). So we'll get rid of it eventually. But in the meantime, the compatibility ioctl code is broken, and this tries to get it to at least limp along (even if Mauro suggested just deleting it entirely, which may be the right thing to do - I don't think the compatibility translation code has ever worked unless you were very lucky). Reported-by: Kees Cook Cc: Mauro Carvalho Chehab Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit db0500894559756a53aefe16ec3319529d69f050 Author: Steven Rostedt Date: Wed Sep 22 22:22:25 2010 -0400 tracing/x86: Don't use mcount in kvmclock.c commit 258af47479980d8238a04568b94a4e55aa1cb537 upstream. The guest can use the paravirt clock in kvmclock.c which is used by sched_clock(), which in turn is used by the tracing mechanism for timestamps, which leads to infinite recursion. Disable mcount/tracing for kvmclock.o. Cc: Jeremy Fitzhardinge Cc: Avi Kivity Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 908d3f38fb48a812de839258b391bd6f7092ffb4 Author: Jeremy Fitzhardinge Date: Wed Sep 22 17:07:27 2010 -0700 tracing/x86: Don't use mcount in pvclock.c commit 9ecd4e1689208afe9b059a5ce1333acb2f42c4d2 upstream. When using a paravirt clock, pvclock.c can be used by sched_clock(), which in turn is used by the tracing mechanism for timestamps, which leads to infinite recursion. Disable mcount/tracing for pvclock.o. Signed-off-by: Jeremy Fitzhardinge LKML-Reference: <4C9A9A3F.4040201@goop.org> Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a255b2005130c1e313461166a25b98956b2d6ef9 Author: Joerg Roedel Date: Thu Sep 23 15:15:19 2010 +0200 x86/amd-iommu: Work around S3 BIOS bug commit 4c894f47bb49284008073d351c0ddaac8860864e upstream. This patch adds a workaround for an IOMMU BIOS problem to the AMD IOMMU driver. The result of the bug is that the IOMMU does not execute commands anymore when the system comes out of the S3 state resulting in system failure. The bug in the BIOS is that is does not restore certain hardware specific registers correctly. This workaround reads out the contents of these registers at boot time and restores them on resume from S3. The workaround is limited to the specific IOMMU chipset where this problem occurs. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 1ce5058b79eb16d2b3de69141353a8c0192a9729 Author: Joerg Roedel Date: Thu Sep 23 16:12:48 2010 +0200 x86/amd-iommu: Fix rounding-bug in __unmap_single commit 04e0463e088b41060c08c255eb0d3278a504f094 upstream. In the __unmap_single function the dma_addr is rounded down to a page boundary before the dma pages are unmapped. The address is later also used to flush the TLB entries for that mapping. But without the offset into the dma page the amount of pages to flush might be miscalculated in the TLB flushing path. This patch fixes this bug by using the original address to flush the TLB. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 43b0a24bedb7474ae1546e860db57a515e1fda49 Author: Joerg Roedel Date: Mon Sep 20 14:33:07 2010 +0200 x86/amd-iommu: Set iommu configuration flags in enable-loop commit e9bf51971157e367aabfc111a8219db010f69cd4 upstream. This patch moves the setting of the configuration and feature flags out out the acpi table parsing path and moves it into the iommu-enable path. This is needed to reliably fix resume-from-s3. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 7f9d0491c3671118a29ab13523bec1ffb963feb8 Author: Marek Szyprowski Date: Thu Sep 23 16:22:05 2010 +0200 mmc: sdhci-s3c: fix NULL ptr access in sdhci_s3c_remove commit 9320f7cbbdd5febf013b0e91db29189724057738 upstream. If not all clocks have been defined in platform data, the driver will cause a null pointer dereference when it is removed. This patch fixes this issue. Signed-off-by: Marek Szyprowski Signed-off-by: Kyungmin Park Signed-off-by: Andrew Morton Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 6ee5c420acc062e2beaa8df205cfc73925e26f8e Author: Steve Wise Date: Sat Sep 18 19:38:21 2010 -0500 RDMA/cxgb3: Turn off RX coalescing for iWARP connections commit bec658ff31453a5726b1c188674d587a5d40c482 upstream. The HW by default has RX coalescing on. For iWARP connections, this causes a 100ms delay in connection establishement due to the ingress MPA Start message being stalled in HW. So explicitly turn RX coalescing off when setting up iWARP connections. This was causing very bad performance for NP64 gather operations using Open MPI, due to the way it sets up connections on larger jobs. Signed-off-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 474a2b3bcead877bd50ac976c875af48c532864d Author: Alan Stern Date: Tue Sep 21 15:01:53 2010 -0400 USB: fix bug in initialization of interface minor numbers commit 0026e00523a85b90a92a93ddf6660939ecef3e54 upstream. Recent changes in the usbhid layer exposed a bug in usbcore. If CONFIG_USB_DYNAMIC_MINORS is enabled then an interface may be assigned a minor number of 0. However interfaces that aren't registered as USB class devices also have their minor number set to 0, during initialization. As a result usb_find_interface() may return the wrong interface, leading to a crash. This patch (as1418) fixes the problem by initializing every interface's minor number to -1. It also cleans up the usb_register_dev() function, which besides being somewhat awkwardly written, does not unwind completely on all its error paths. Signed-off-by: Alan Stern Tested-by: Philip J. Turmel Tested-by: Gabriel Craciunescu Tested-by: Alex Riesen Tested-by: Matthias Bayer CC: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9d55dc791385be8da4013a166f82db745c48e3dd Author: Clemens Ladisch Date: Fri Oct 15 12:06:18 2010 +0200 ALSA: rawmidi: fix oops (use after free) when unloading a driver module commit aa73aec6c385e2c797ac25cc7ccf0318031de7c8 upstream. When a driver module is unloaded and the last still open file is a raw MIDI device, the card and its devices will be actually freed in the snd_card_file_remove() call when that file is closed. Afterwards, rmidi and rmidi->card point into freed memory, so the module pointer is likely to be garbage. (This was introduced by commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a.) Signed-off-by: Clemens Ladisch Reported-by: Krzysztof Foltman Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b259026c5eb96fae5c3c3884a7da7fd13886267f Author: Dan Rosenberg Date: Tue Sep 28 14:18:20 2010 -0400 ALSA: prevent heap corruption in snd_ctl_new() commit 5591bf07225523600450edd9e6ad258bb877b779 upstream. The snd_ctl_new() function in sound/core/control.c allocates space for a snd_kcontrol struct by performing arithmetic operations on a user-provided size without checking for integer overflow. If a user provides a large enough size, an overflow will occur, the allocated chunk will be too small, and a second user-influenced value will be written repeatedly past the bounds of this chunk. This code is reachable by unprivileged users who have permission to open a /dev/snd/controlC* device (on many distros, this is group "audio") via the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 64ba4c140e3a025b6e3bd4b303b22a7a02ed3f68 Author: Luke Yelavich Date: Tue Sep 21 17:05:46 2010 +1000 ALSA: hda - Add Dell Latitude E6400 model quirk commit 0f9f1ee9d1412d45a22bfd69dfd4d4324b506e9e upstream. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/643891 Set the Dell Latitude E6400 (1028:0233) SSID to use AD1984_DELL_DESKTOP Signed-off-by: Luke Yelavich Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 980a96c276db63b160ce7923806ce75c626d10fa Author: Erik J. Staab Date: Wed Sep 22 11:07:41 2010 +0200 ALSA: oxygen: fix analog capture on Claro halo cards commit 0873a5ae747847ee55a63db409dff3476e45bcd9 upstream. On the HT-Omega Claro halo card, the ADC data must be captured from the second I2S input. Using the default first input, which isn't connected to anything, would result in silence. Signed-off-by: Erik J. Staab Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ecadb3f423ba4913d8c8ba6e98b3f78f271cc8f Author: Dan Rosenberg Date: Sat Sep 25 11:07:27 2010 -0400 ALSA: sound/pci/rme9652: prevent reading uninitialized stack memory commit e68d3b316ab7b02a074edc4f770e6a746390cb7d upstream. The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow unprivileged users to read uninitialized kernel stack memory, because several fields of the hdsp{m}_config_info structs declared on the stack are not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bfe4ecf769c30630b23a69c2441c6ab0a247ceaa Author: H. Peter Anvin Date: Tue Sep 28 15:35:01 2010 -0700 x86, cpu: After uncapping CPUID, re-run CPU feature detection commit d900329e20f4476db6461752accebcf7935a8055 upstream. After uncapping the CPUID level, we need to also re-run the CPU feature detection code. This resolves kernel bugzilla 16322. Reported-by: boris64 LKML-Reference: Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman