commit 3499d6424f682a58761d827012567c552b053842 Author: Greg Kroah-Hartman Date: Wed Jan 25 16:39:32 2012 -0800 Linux 3.2.2 commit 4556a6d95ae899263a3e63df1d3556e5cc6d3dd7 Author: Hugh Dickins Date: Fri Jan 20 14:34:21 2012 -0800 SHM_UNLOCK: fix Unevictable pages stranded after swap commit 245132643e1cfcd145bbc86a716c1818371fcb93 upstream. Commit cc39c6a9bbde ("mm: account skipped entries to avoid looping in find_get_pages") correctly fixed an infinite loop; but left a problem that find_get_pages() on shmem would return 0 (appearing to callers to mean end of tree) when it meets a run of nr_pages swap entries. The only uses of find_get_pages() on shmem are via pagevec_lookup(), called from invalidate_mapping_pages(), and from shmctl SHM_UNLOCK's scan_mapping_unevictable_pages(). The first is already commented, and not worth worrying about; but the second can leave pages on the Unevictable list after an unusual sequence of swapping and locking. Fix that by using shmem_find_get_pages_and_swap() (then ignoring the swap) instead of pagevec_lookup(). But I don't want to contaminate vmscan.c with shmem internals, nor shmem.c with LRU locking. So move scan_mapping_unevictable_pages() into shmem.c, renaming it shmem_unlock_mapping(); and rename check_move_unevictable_page() to check_move_unevictable_pages(), looping down an array of pages, oftentimes under the same lock. Leave out the "rotate unevictable list" block: that's a leftover from when this was used for /proc/sys/vm/scan_unevictable_pages, whose flawed handling involved looking at pages at tail of LRU. Was there significance to the sequence first ClearPageUnevictable, then test page_evictable, then SetPageUnevictable here? I think not, we're under LRU lock, and have no barriers between those. Signed-off-by: Hugh Dickins Reviewed-by: KOSAKI Motohiro Cc: Minchan Kim Cc: Rik van Riel Cc: Shaohua Li Cc: Eric Dumazet Cc: Johannes Weiner Cc: Michel Lespinasse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2a4073c2bb288193f5e7a0d57e9cf2f9786dddc3 Author: Hugh Dickins Date: Fri Jan 20 14:34:19 2012 -0800 SHM_UNLOCK: fix long unpreemptible section commit 85046579bde15e532983438f86b36856e358f417 upstream. scan_mapping_unevictable_pages() is used to make SysV SHM_LOCKed pages evictable again once the shared memory is unlocked. It does this with pagevec_lookup()s across the whole object (which might occupy most of memory), and takes 300ms to unlock 7GB here. A cond_resched() every PAGEVEC_SIZE pages would be good. However, KOSAKI-san points out that this is called under shmem.c's info->lock, and it's also under shm.c's shm_lock(), both spinlocks. There is no strong reason for that: we need to take these pages off the unevictable list soonish, but those locks are not required for it. So move the call to scan_mapping_unevictable_pages() from shmem.c's unlock handling up to shm.c's unlock handling. Remove the recently added barrier, not needed now we have spin_unlock() before the scan. Use get_file(), with subsequent fput(), to make sure we have a reference to mapping throughout scan_mapping_unevictable_pages(): that's something that was previously guaranteed by the shm_lock(). Remove shmctl's lru_add_drain_all(): we don't fault in pages at SHM_LOCK time, and we lazily discover them to be Unevictable later, so it serves no purpose for SHM_LOCK; and serves no purpose for SHM_UNLOCK, since pages still on pagevec are not marked Unevictable. The original code avoided redundant rescans by checking VM_LOCKED flag at its level: now avoid them by checking shp's SHM_LOCKED. The original code called scan_mapping_unevictable_pages() on a locked area at shm_destroy() time: perhaps we once had accounting cross-checks which required that, but not now, so skip the overhead and just let inode eviction deal with them. Put check_move_unevictable_page() and scan_mapping_unevictable_pages() under CONFIG_SHMEM (with stub for the TINY case when ramfs is used), more as comment than to save space; comment them used for SHM_UNLOCK. Signed-off-by: Hugh Dickins Reviewed-by: KOSAKI Motohiro Cc: Minchan Kim Cc: Rik van Riel Cc: Shaohua Li Cc: Eric Dumazet Cc: Johannes Weiner Cc: Michel Lespinasse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 671f9c9e2ff7679ddcbc67572fd3e678843e725b Author: Stanislaw Gruszka Date: Fri Dec 23 08:13:50 2011 +0100 iwlegacy: 3945: fix hw passive scan on radar channels commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream. Patch fix firmware error on "iw dev wlan0 scan passive" for hardware scanning (with disable_hw_scan=0 module parameter). iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008. iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9 iwl3945 0000:03:00.0: Start IWL Error Log Dump: iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1 iwl3945 0000:03:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line iwl3945 0000:03:00.0: SYSASSERT (0x5) 0041263900 0x13756 0x0031C 0x00000 764 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error iwl3945 0000:03:00.0: Can't stop Rx DMA. We have disable ability to change passive scanning to active on particular channel when traffic is detected on that channel. Otherwise firmware will report error, when we try to do passive scan on radar channels. Reported-and-debugged-by: Pedro Francisco Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit fd7c0921d854fd7e3fd11e63effa6c2a3f213994 Author: Wey-Yi Guy Date: Thu Nov 10 06:55:04 2011 -0800 iwlagn: check for SMPS mode commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream. Check and report WARN only when its invalid Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=42621 https://bugzilla.redhat.com/show_bug.cgi?id=766071 Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 3a508e6e619f89eb35ba280f41feca1f74d7196d Author: Michal Hocko Date: Fri Jan 20 14:33:55 2012 -0800 mm: fix NULL ptr dereference in __count_immobile_pages commit 687875fb7de4a95223af20ee024282fa9099f860 upstream. Fix the following NULL ptr dereference caused by cat /sys/devices/system/memory/memory0/removable Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade RIP: __count_immobile_pages+0x4/0x100 Process sed (pid: 13979, threadinfo ffff880221c36000, task ffff88022e788480) Call Trace: is_pageblock_removable_nolock+0x34/0x40 is_mem_section_removable+0x74/0xf0 show_mem_removable+0x41/0x70 sysfs_read_file+0xfe/0x1c0 vfs_read+0xc7/0x130 sys_read+0x53/0xa0 system_call_fastpath+0x16/0x1b We are crashing because we are trying to dereference NULL zone which came from pfn=0 (struct page ffffea0000000000). According to the boot log this page is marked reserved: e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) and early_node_map confirms that: early_node_map[3] active PFN ranges 1: 0x00000010 -> 0x0000009c 1: 0x00000100 -> 0x000bffa3 1: 0x00100000 -> 0x00240000 The problem is that memory_present works in PAGE_SECTION_MASK aligned blocks so the reserved range sneaks into the the section as well. This also means that free_area_init_node will not take care of those reserved pages and they stay uninitialized. When we try to read the removable status we walk through all available sections and hope that the zone is valid for all pages in the section. But this is not true in this case as the zone and nid are not initialized. We have only one node in this particular case and it is marked as node=1 (rather than 0) and that made the problem visible because page_to_nid will return 0 and there are no zones on the node. Let's check that the zone is valid and that the given pfn falls into its boundaries and mark the section not removable. This might cause some false positives, probably, but we do not have any sane way to find out whether the page is reserved by the platform or it is just not used for whatever other reasons. Signed-off-by: Michal Hocko Acked-by: Mel Gorman Cc: KAMEZAWA Hiroyuki Cc: Andrea Arcangeli Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd1dc8b1059670627315706d0a53ffbdf5cbeed3 Author: Will Deacon Date: Fri Jan 20 14:34:09 2012 -0800 proc: clear_refs: do not clear reserved pages commit 85e72aa5384b1a614563ad63257ded0e91d1a620 upstream. /proc/pid/clear_refs is used to clear the Referenced and YOUNG bits for pages and corresponding page table entries of the task with PID pid, which includes any special mappings inserted into the page tables in order to provide things like vDSOs and user helper functions. On ARM this causes a problem because the vectors page is mapped as a global mapping and since ec706dab ("ARM: add a vma entry for the user accessible vector page"), a VMA is also inserted into each task for this page to aid unwinding through signals and syscall restarts. Since the vectors page is required for handling faults, clearing the YOUNG bit (and subsequently writing a faulting pte) means that we lose the vectors page *globally* and cannot fault it back in. This results in a system deadlock on the next exception. To see this problem in action, just run: $ echo 1 > /proc/self/clear_refs on an ARM platform (as any user) and watch your system hang. I think this has been the case since 2.6.37 This patch avoids clearing the aforementioned bits for reserved pages, therefore leaving the vectors page intact on ARM. Since reserved pages are not candidates for swap, this change should not have any impact on the usefulness of clear_refs. Signed-off-by: Will Deacon Reported-by: Moussa Ba Acked-by: Hugh Dickins Cc: David Rientjes Cc: Russell King Acked-by: Nicolas Pitre Cc: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6ee7663e972835367a550bd6b9fecc1a9dc14ce1 Author: Ananth N Mavinakayanahalli Date: Fri Jan 20 14:34:04 2012 -0800 kprobes: initialize before using a hlist commit d496aab567e7e52b3e974c9192a5de6e77dce32c upstream. Commit ef53d9c5e ("kprobes: improve kretprobe scalability with hashed locking") introduced a bug where we can potentially leak kretprobe_instances since we initialize a hlist head after having used it. Initialize the hlist head before using it. Reported by: Jim Keniston Acked-by: Jim Keniston Signed-off-by: Ananth N Mavinakayanahalli Acked-by: Masami Hiramatsu Cc: Srinivasa D S Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bdac3a105a1c8fdf89ea15404ad5c7bcec73d37a Author: Jeff Layton Date: Tue Jan 17 16:08:51 2012 -0500 cifs: lower default wsize when unix extensions are not used commit ce91acb3acae26f4163c5a6f1f695d1a1e8d9009 upstream. We've had some reports of servers (namely, the Solaris in-kernel CIFS server) that don't deal properly with writes that are "too large" even though they set CAP_LARGE_WRITE_ANDX. Change the default to better mirror what windows clients do. Cc: Pavel Shilovsky Reported-by: Nick Davis Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5f4972712d070a70b2ac50c7f75a6b2dac1be74b Author: Dan Rosenberg Date: Fri Jan 20 14:34:27 2012 -0800 score: fix off-by-one index into syscall table commit c25a785d6647984505fa165b5cd84cfc9a95970b upstream. If the provided system call number is equal to __NR_syscalls, the current check will pass and a function pointer just after the system call table may be called, since sys_call_table is an array with total size __NR_syscalls. Whether or not this is a security bug depends on what the compiler puts immediately after the system call table. It's likely that this won't do anything bad because there is an additional NULL check on the syscall entry, but if there happens to be a non-NULL value immediately after the system call table, this may result in local privilege escalation. Signed-off-by: Dan Rosenberg Cc: Chen Liqin Cc: Lennox Wu Cc: Eugene Teo Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8d7385000114bd38bdeb6ca175262b56aecd1931 Author: Toshiharu Okada Date: Mon Sep 26 16:16:23 2011 +0900 i2c-eg20t: modified the setting of transfer rate. commit ff35e8b18984ad2a82cbd259fc07f0be4b34b1aa upstream. This patch modified the setting value of I2C Bus Transfer Rate Setting Counter regisrer. Signed-off-by: Toshiharu Okada Signed-off-by: Ben Dooks Signed-off-by: Greg Kroah-Hartman commit afa2f5f83ea3ab46e90206e39578eaa61daf49f0 Author: Dave Chinner Date: Wed Jan 18 14:41:45 2012 -0600 xfs: fix endian conversion issue in discard code commit b1c770c273a4787069306fc82aab245e9ac72e9d upstream When finding the longest extent in an AG, we read the value directly out of the AGF buffer without endian conversion. This will give an incorrect length, resulting in FITRIM operations potentially not trimming everything that it should. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit e9651ec2db7b69a2e41a76d1fdd7932aeef04aae Author: Stanislaw Gruszka Date: Fri Jan 13 12:59:32 2012 +0100 rt2800pci: fix spurious interrupts generation commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream. Same devices can generate interrupt without properly setting bit in INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line will be disabled by interrupts controller driver. We discovered that clearing INT_MASK_CSR stops such behaviour. We previously first read that register, and then clear all know interrupt sources bits and do not touch reserved bits. After this patch, we write to all register content (I believe writing to reserved bits on that register will not cause any problems, I tested that on my rt2800pci device). This fix very bad performance problem, practically making device unusable (since worked without interrupts), reported in: https://bugzilla.redhat.com/show_bug.cgi?id=658451 We previously tried to workaround that issue in commit 4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious interrupts", but it was reverted in commit 82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6 as thing, that will prevent to detect real spurious interrupts. Reported-and-tested-by: Amir Hedayaty Signed-off-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b4a82a0a2e32777267b2c997fa55b90056447a40 Author: Felix Fietkau Date: Sat Jan 14 15:08:34 2012 +0100 ath9k_hw: fix interpretation of the rx KeyMiss flag commit 7a532fe7131216a02c81a6c1b1f8632da1195a58 upstream. Documentation states that the KeyMiss flag is only valid if RxFrameOK is unset, however empirical evidence has shown that this is false. When KeyMiss is set (and RxFrameOK is 1), the hardware passes a valid frame which has not been decrypted. The driver then falsely marks the frame as decrypted, and when using CCMP this corrupts the rx CCMP PN, leading to connection hangs. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ebd11e15ac4b85124de9f41c335bd3b00661e49d Author: Cliff Wickman Date: Mon Jan 16 15:19:47 2012 -0600 x86/UV2: Work around BAU bug commit c5d35d399e685acccc85a675e8765c26b2a9813a upstream. This patch implements a workaround for a UV2 hardware bug. The bug is a non-atomic update of a memory-mapped register. When hardware message delivery and software message acknowledge occur simultaneously the pending message acknowledge for the arriving message may be lost. This causes the sender's message status to stay busy. Part of the workaround is to not acknowledge a completed message until it is verified that no other message is actually using the resource that is mistakenly recorded in the completed message. Part of the workaround is to test for long elapsed time in such a busy condition, then handle it by using a spare sending descriptor. The stay-busy condition is eventually timed out by hardware, and then the original sending descriptor can be re-used. Most of that logic change is in keeping track of the current descriptor and the state of the spares. The occurrences of the workaround are added to the BAU statistics. Signed-off-by: Cliff Wickman Link: http://lkml.kernel.org/r/20120116211947.GC5767@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5869dc3cc783cea391d787832f2b925e5c5159c0 Author: Cliff Wickman Date: Mon Jan 16 15:18:48 2012 -0600 x86/UV2: Fix BAU destination timeout initialization commit d059f9fa84a30e04279c6ff615e9e2cf3b260191 upstream. Move the call to enable_timeouts() forward so that BAU_MISC_CONTROL is initialized before using it in calculate_destination_timeout(). Fix the calculation of a BAU destination timeout for UV2 (in calculate_destination_timeout()). Signed-off-by: Cliff Wickman Link: http://lkml.kernel.org/r/20120116211848.GB5767@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 40434094065aaa6ec566725be43f0da70ab56172 Author: Cliff Wickman Date: Mon Jan 16 15:17:50 2012 -0600 x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode commit da87c937e5a2374686edd58df06cfd5050b125fa upstream. Update the use of the Broadcast Assist Unit on SGI Altix UV2 to the use of native UV2 mode on new hardware (not the legacy mode). UV2 native mode has a different format for a broadcast message. We also need quick differentiaton between UV1 and UV2. Signed-off-by: Cliff Wickman Link: http://lkml.kernel.org/r/20120116211750.GA5767@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a92ad2dcdcb74c7813e2dd88d2635a1831894808 Author: Alexander Aring Date: Thu Dec 8 15:43:53 2011 +0100 I2C: OMAP: correct SYSC register offset for OMAP4 commit 2727b1753934e154931d6b3bdf20c9b2398457a2 upstream. Correct OMAP_I2C_SYSC_REG offset in omap4 register map. Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset. Signed-off-by: Alexander Aring [khilman@ti.com: minor changelog edits] Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 8962e9fcab14954ac4489089827e24e8c29f7038 Author: Steven Rostedt Date: Fri Jan 13 21:40:59 2012 -0500 tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT commit c10076c4304083af15a41f6bc5e657e781c1f9a6 upstream. Tracepoints are disabled for tainted modules, which is usually because the module is either proprietary or was forced, and we don't want either of them using kernel tracepoints. But, a module can also be tainted by being in the staging directory or compiled out of tree. Either is fine for use with tracepoints, no need to punish them. I found this out when I noticed that my sample trace event module, when done out of tree, stopped working. Cc: Mathieu Desnoyers Cc: Ben Hutchings Cc: Dave Jones Cc: Greg Kroah-Hartman Cc: Rusty Russell Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8f3ceefaed1493edfbd622026bced706055b8318 Author: Miroslav Slugen Date: Sun Dec 11 18:47:32 2011 -0300 tuner: Fix numberspace conflict between xc4000 and pti 5nf05 tuners commit cd4ca7afc61d3b18fcd635002459fb6b1d701099 upstream. Update xc4000 tuner definition, number 81 is already in use by TUNER_PARTSNIC_PTI_5NF05. Signed-off-by: Miroslav Slugen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit fe77de3ae1000a00349dc680df0bd34c49199efb Author: Miroslav Slugen Date: Sun Dec 11 19:00:06 2011 -0300 cx88: fix: don't duplicate xc4000 entry for radio commit b6854e3f31402476bcc9d2f41570389fa491de17 upstream. All radio tuners in cx88 driver using same address for radio and tuner, so there is no need to probe it twice for same tuner and we can use radio_type UNSET, this also fix broken radio since kernel 2.6.39-rc1 for those tuners. Signed-off-by: Miroslav Slugen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 60dfee83be0262141968a4ee6b48786bc5767073 Author: Miroslav Slugen Date: Sun Dec 11 18:57:58 2011 -0300 cx23885-dvb: check if dvb_attach() succeded commit a7c8aadad39428b64d26c3971d967f8314e2397d upstream. Fix possible null dereference for Leadtek DTV 3200H XC4000 tuner when no firmware file available. Signed-off-by: Miroslav Slugen Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c893fe01b35036f062a9c7d7f6b7fc926fc91115 Author: Rafał Miłecki Date: Fri Jan 13 23:58:38 2012 +0100 bcma: invalidate the mapped core over suspend/resume commit 28e7d218da975f6ae1751e293aed938952c55c98 upstream. This clears the currently mapped core when suspending, to force re-mapping after resume. Without that we were touching default core registers believing some other core is mapped. Such a behaviour resulted in lockups on some machines. Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8967b2b814f94a752b65e672e79c065887fe005f Author: Roland Dreier Date: Tue Dec 13 14:55:33 2011 -0800 target: Set additional sense length field in sense data commit 895f3022523361e9b383cf48f51feb1f7d5e7e53 upstream. The target code was not setting the additional sense length field in the sense data it returned, which meant that at least the Linux stack ignored the ASC/ASCQ fields. For example, without this patch, on a tcm_loop device: # sg_raw -v /dev/sda 2 0 0 0 0 0 gives cdb to send: 02 00 00 00 00 00 SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Raw sense data (in hex): 70 00 05 00 00 00 00 00 while after the patch we correctly get the following (which matches what a regular disk returns): cdb to send: 02 00 00 00 00 00 SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Invalid command operation code Raw sense data (in hex): 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 9ce1ae0acda051d7378c5726d5e63a45dc88beb6 Author: Roland Dreier Date: Tue Dec 6 10:02:09 2011 -0800 target: Set response format in INQUIRY response commit ce136176fea522fc8f4c16dcae7e8ed1d890ca39 upstream. Current SCSI specs say that the "response format" field in the standard INQUIRY response should be set to 2, and all the real SCSI devices I have do put 2 here. So let's do that too. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b328e18f8ba3c8a32ba45952ae5bf8dd39d73120 Author: Stratos Psomadakis Date: Sun Dec 4 02:23:54 2011 +0200 sym53c8xx: Fix NULL pointer dereference in slave_destroy commit cced5041ed5a2d1352186510944b0ddfbdbe4c0b upstream. sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference (exposed by commit 4e6c82b). Signed-off-by: Stratos Psomadakis Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b9547c0e2ff53f68325d7be563d41308e04ab1ac Author: Lin Ming Date: Tue Dec 13 09:36:03 2011 +0800 ACPI: processor: fix acpi_get_cpuid for UP processor commit d640113fe80e45ebd4a5b420b220d3f6bf37f682 upstream. For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Reported-and-tested-by: wallak@free.fr Signed-off-by: Lin Ming Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 0726687ca114dfbba266452fefa6fd05080c9826 Author: Lin Ming Date: Tue Nov 29 22:13:35 2011 +0800 ACPICA: Put back the call to acpi_os_validate_address commit da4d8b287abe783d30e968155614531a0937d090 upstream. The call to acpi_os_validate_address in acpi_ds_get_region_arguments was removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and dsload.c files). Put it back. Reported-and-bisected-by: Luca Tettamanti Signed-off-by: Lin Ming Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit a591555d5dad4b3ab47ced3f775dce73e8ce00e6 Author: Kurt Garloff Date: Tue Jan 17 04:21:49 2012 -0500 ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64) commit 9f10f6a520deb3639fac78d81151a3ade88b4e7f upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. ia64 did handle the PXM fields almost consistently, but depending on sgi's sn2 platform. This patch leaves the sn2 logic in, but does also use 16/32 bits for PXM if the SRAT has rev 2 or higher. The patch also adds __init to the two pxm accessor functions, as they access __initdata now and are called from an __init function only anyway. Note that the code only uses 16 bits for the PXM field in the processor proximity field; the patch does not address this as 16 bits are more than enough. Signed-off-by: Kurt Garloff Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f318322990f13f251a650209f541546faec03a19 Author: Kurt Garloff Date: Tue Jan 17 04:20:31 2012 -0500 ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64) commit cd298f60a2451a16e0f077404bf69b62ec868733 upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits for the pxm field in cpu_affinity, but 32 bits in mem_affinity. This patch makes it consistent: Either use 8 bits consistently (SRAT rev 1 or lower) or 32 bits (SRAT rev 2 or higher). cc: x86@kernel.org Signed-off-by: Kurt Garloff Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 45ed93deefc42db6c0cf3154f50f5f6404d7ecf5 Author: Kurt Garloff Date: Tue Jan 17 04:18:02 2012 -0500 ACPI: Store SRAT table revision commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. In order to know whether or not, we must know what version the SRAT table has. This patch stores the SRAT table revision for later consumption by arch specific __init functions. Signed-off-by: Kurt Garloff Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit caa3e3bed0bf0ec356101811dcd46c9603ec3788 Author: Shaohua Li Date: Tue Jan 10 15:48:19 2012 -0800 intel_idle: fix API misuse commit 39a74fdedd1c1461d6fb6d330b5266886513c98f upstream. smp_call_function() only lets all other CPUs execute a specific function, while we expect all CPUs do in intel_idle. Without the fix, we could have one cpu which has auto_demotion enabled or has no broadcast timer setup. Usually we don't see impact because auto demotion just harms power and the intel_idle init is called in CPU 0, where boradcast timer delivers interrupt, but this still could be a problem. Signed-off-by: Shaohua Li Signed-off-by: Andrew Morton Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 872f97c4e073b6e23a232cbdceb212aaac51d7df Author: Thomas Renninger Date: Sun Dec 4 22:17:29 2011 +0100 intel idle: Make idle driver more robust commit 5c2a9f06a9cd7194f884cdc88144866235dec07d upstream. kvm -cpu host passes the original cpuid info to the guest. Latest kvm version seem to return true for mwait_leaf cpuid function on recent Intel CPUs. But it does not return mwait C-states (mwait_substates), instead zero is returned. While real CPUs seem to always return non-zero values, the intel idle driver should not get active in kvm (mwait_substates == 0) case and bail out. Otherwise a Null pointer exception will happen later when the cpuidle subsystem tries to get active: [0.984807] BUG: unable to handle kernel NULL pointer dereference at (null) [0.984807] IP: [<(null)>] (null) ... [0.984807][] ? cpuidle_idle_call+0xb4/0x340 [0.984807][] ? __atomic_notifier_call_chain+0x4c/0x70 [0.984807][] ? cpu_idle+0x78/0xd0 Reference: https://bugzilla.novell.com/show_bug.cgi?id=726296 Signed-off-by: Thomas Renninger CC: Bruno Friedmann Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f42395415b6b335ddd8c32776d3fa44dae3cdf21 Author: Tetsuo Handa Date: Sun Jan 15 11:05:59 2012 +0900 TOMOYO: Accept \000 as a valid character. commit 25add8cf99c9ec8b8dc0acd8b9241e963fc0d29c upstream. TOMOYO 2.5 in Linux 3.2 and later handles Unix domain socket's address. Thus, tomoyo_correct_word2() needs to accept \000 as a valid character, or TOMOYO 2.5 cannot handle Unix domain's abstract socket address. Reported-by: Steven Allen Signed-off-by: Tetsuo Handa Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 3991280f9562f5cdb13d7b4999f63dd8b9c3f207 Author: David Henningsson Date: Mon Jan 16 10:52:20 2012 +0100 ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645 commit ffe535edb9a9c5b4d5fe03dfa3d89a1495580f1b upstream. More than one user reports that changing the model from "both" to "dmic" makes their Internal Mic work. Tested-by: Martin Ling BugLink: https://bugs.launchpad.net/bugs/795823 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c1f9335c011c2d2c2071ffb7ac44872088a22fa3 Author: Clemens Ladisch Date: Sat Jan 14 16:42:24 2012 +0100 ALSA: virtuoso: Xonar DS: fix polarity of front output commit f0e48b6bd4e407459715240cd241ddb6b89bdf81 upstream. The two DACs for the front output and the surround/center/LFE/back outputs are wired up out of phase, so when channels are duplicated, their sound can cancel out each other and result in a weaker bass response. To fix this, reverse the polarity of the neutron flow to the front output. Reported-any-tested-by: Daniel Hill Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2f1bce58c239b3b71e4eeb25d241aa6bcac5a2e2 Author: David Henningsson Date: Thu Jan 12 16:31:14 2012 +0100 ALSA: HDA: Use LPIB position fix for Macbook Pro 7,1 commit b01de4fb40137fbda7530550ff0cd37171dafb0c upstream. Several users have reported "choppy" audio under the 3.2 kernel, and that changing position_fix to 1 has resolved their problem. The chip is an nVidia Corporation MCP89 High Definition Audio, [10de:0d94] (rev a2). BugLink: https://bugs.launchpad.net/bugs/909419 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4d96a0c102dfa7b1c009e5b6dbd8fe35e93e1a79 Author: Linus Torvalds Date: Tue Jan 17 15:21:19 2012 -0800 proc: clean up and fix /proc//mem handling commit e268337dfe26dfc7efd422a804dbb27977a3cccc upstream. Jüri Aedla reported that the /proc//mem handling really isn't very robust, and it also doesn't match the permission checking of any of the other related files. This changes it to do the permission checks at open time, and instead of tracking the process, it tracks the VM at the time of the open. That simplifies the code a lot, but does mean that if you hold the file descriptor open over an execve(), you'll continue to read from the _old_ VM. That is different from our previous behavior, but much simpler. If somebody actually finds a load where this matters, we'll need to revert this commit. I suspect that nobody will ever notice - because the process mapping addresses will also have changed as part of the execve. So you cannot actually usefully access the fd across a VM change simply because all the offsets for IO would have changed too. Reported-by: Jüri Aedla Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 10f176d299c6598b3a94d1257f39410da5ba08e5 Author: Paolo Bonzini Date: Thu Jan 12 16:01:29 2012 +0100 dm: do not forward ioctls from logical volumes to the underlying device commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream. A logical volume can map to just part of underlying physical volume. In this case, it must be treated like a partition. Based on a patch from Alasdair G Kergon. Cc: Alasdair G Kergon Cc: dm-devel@redhat.com Signed-off-by: Paolo Bonzini Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d33310de0d7914f2e27ed4fef67a1979f10037e1 Author: Paolo Bonzini Date: Thu Jan 12 16:01:28 2012 +0100 block: fail SCSI passthrough ioctls on partition devices commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream. [ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl and -ENOIOCTLCMD from sd_compat_ioctl. ] Linux allows executing the SG_IO ioctl on a partition or LVM volume, and will pass the command to the underlying block device. This is well-known, but it is also a large security problem when (via Unix permissions, ACLs, SELinux or a combination thereof) a program or user needs to be granted access only to part of the disk. This patch lets partitions forward a small set of harmless ioctls; others are logged with printk so that we can see which ioctls are actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred. Of course it was being sent to a (partition on a) hard disk, so it would have failed with ENOTTY and the patch isn't changing anything in practice. Still, I'm treating it specially to avoid spamming the logs. In principle, this restriction should include programs running with CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and /dev/sdb, it still should not be able to read/write outside the boundaries of /dev/sda2 independent of the capabilities. However, for now programs with CAP_SYS_RAWIO will still be allowed to send the ioctls. Their actions will still be logged. This patch does not affect the non-libata IDE driver. That driver however already tests for bd != bd->bd_contains before issuing some ioctl; it could be restricted further to forbid these ioctls even for programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO. Cc: linux-scsi@vger.kernel.org Cc: Jens Axboe Cc: James Bottomley Signed-off-by: Paolo Bonzini [ Make it also print the command name when warning - Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 36a7ce632fb11cce578b7fdf4b4bbc8fbb99987a Author: Paolo Bonzini Date: Thu Jan 12 16:01:27 2012 +0100 block: add and use scsi_blk_cmd_ioctl commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream. Introduce a wrapper around scsi_cmd_ioctl that takes a block device. The function will then be enhanced to detect partition block devices and, in that case, subject the ioctls to whitelisting. Cc: linux-scsi@vger.kernel.org Cc: Jens Axboe Cc: James Bottomley Signed-off-by: Paolo Bonzini Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ca4a557300dd9e22aea5a8e86eb1cfb2b2ad99a5 Author: Martin Schwidefsky Date: Thu Dec 15 14:56:10 2011 +0100 fix cputime overflow in uptime_proc_show commit c3e0ef9a298e028a82ada28101ccd5cf64d209ee upstream. For 32-bit architectures using standard jiffies the idletime calculation in uptime_proc_show will quickly overflow. It takes (2^32 / HZ) seconds of idle-time, or e.g. 12.45 days with no load on a quad-core with HZ=1000. Switch to 64-bit calculations. Cc: Michael Abbott Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit b44d4773ae952dff1f04032138e566810b77115d Author: Masatoshi Hoshikawa Date: Thu Jan 5 11:53:46 2012 +0900 HID: hid-multitouch: add support 9 new Xiroku devices commit 11576c6114c3b6505aea2e0c988bedb856a0e20c upstream. This patch adds support for the Xiroku Inc. panels (SPX/MPX/CSR/etc.). Signed-off-by: Masatoshi Hoshikawa Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 087a51c4c1c1c3103a2e45c51e80d921877f4c27 Author: Benjamin Tissoires Date: Fri Dec 23 15:41:00 2011 +0100 HID: multitouch: add support for 3M 32" commit c4fad877cd0efb51d8180ae2eaa791c99c92051c upstream. Signed-off-by: Benjamin Tissoires Acked-by: Henrik Rydberg Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 990848a5b6506264c7758c7f650c87af363edb7b Author: Benjamin Tissoires Date: Fri Dec 23 15:40:59 2011 +0100 HID: multitouch: add support of Atmel multitouch panels commit b105712469d957cf1ab223c1ea72b7ba88edb926 upstream. Signed-off-by: Benjamin Tissoires Acked-by: Henrik Rydberg Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 45bc79a2dcd8e087e1d7075b74553f22d6e8161c Author: Benjamin Tissoires Date: Tue Nov 29 13:13:12 2011 +0100 HID: hid-multitouch: add support for new Hanvon panels commit 545803651da8dde248eeb8ce3ed1e547e9e4ac0a upstream. Signed-off-by: Benjamin Tissoires Acked-by: Henrik Rydberg Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 020aef897ab51a3ac83160971b1a4b0000e4e348 Author: Benjamin Tissoires Date: Wed Nov 23 10:54:33 2011 +0100 HID: multitouch: add support for the MSI Windpad 110W commit 66f06127f34ad6e8a1b24a2c03144b694d19f99f upstream. Just another eGalax device. Please note that adding this device to have_special_driver in hid-core.c is not required anymore. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 00ba434244112ea6ec5b7f9544a3af3c070e6efd Author: Marek Vasut Date: Wed Nov 23 10:54:32 2011 +0100 HID: multitouch: Add egalax ID for Acer Iconia W500 commit bb9ff21072043634f147c05ac65dbf8185d4af6d upstream. This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel supports up to five fingers, therefore the need for a new addition of panel types. Signed-off-by: Marek Vasut Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 13ceb211f7742e046c077a5e8ff9f805161b208b Author: Benjamin Tissoires Date: Wed Nov 23 10:54:31 2011 +0100 HID: multitouch: cleanup with eGalax PID definitions commit e36f690b37945e0a9bb1554e1546eeec93f7d1f6 upstream. This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N} to USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_{PID} to handle more eGalax devices. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 67285c330dced065222122260051b141dd81aa9f Author: Chris Bagwell Date: Wed Nov 23 10:54:27 2011 +0100 HID: hid-multitouch - add another eGalax id commit 1fd8f047490dd0ec4e4db710fcbc1bd4798d944c upstream. This allows ASUS Eee Slate touchscreens to work. Signed-off-by: Chris Bagwell Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 5cb46f3196c0ede3738abe1f1b01523d2a603dad Author: Johannes Berg Date: Tue Nov 29 10:20:02 2011 +0100 mac80211: revert on-channel work optimisations commit e76aadc572288a158ae18ae1c10fe395c7bca066 upstream. Backport note: This patch it's a full revert of commit b23b025f "mac80211: Optimize scans on current operating channel.". On upstrem revert e76aadc5 we keep some bits from that commit, which are needed for upstream version of mac80211. The on-channel work optimisations have caused a number of issues, and the code is unfortunately very complex and almost impossible to follow. Instead of attempting to put in more workarounds let's just remove those optimisations, we can work on them again later, after we change the whole auth/assoc design. This should fix rate_control_send_low() warnings, see RH bug 731365. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Stanislaw Gruszka Signed-off-by: Greg Kroah-Hartman commit b4e8ff2994fa04444d813a3dfd2e8762756a00ec Author: Peng Tao Date: Thu Jan 12 23:18:48 2012 +0800 pnfsblock: limit bio page count commit 74a6eeb44ca6174d9cc93b9b8b4d58211c57bc80 upstream. One bio can have at most BIO_MAX_PAGES pages. We should limit it bec otherwise bio_alloc will fail when there are many pages in one read/write_pagelist. Signed-off-by: Peng Tao Signed-off-by: Benny Halevy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7e0f9f47b49048c1a809a9bfff85002cb7fbf8e3 Author: Peng Tao Date: Thu Jan 12 23:18:47 2012 +0800 pnfsblock: don't spinlock when freeing block_dev commit 93a3844ee0f843b05a1df4b52e1a19ff26b98d24 upstream. bl_free_block_dev() may sleep. We can not call it with spinlock held. Besides, there is no need to take bm_lock as we are last user freeing bm_devlist. Signed-off-by: Peng Tao Signed-off-by: Benny Halevy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit ae6481331e29dd7a055c70b7abaaef9e01c60ced Author: Peng Tao Date: Thu Jan 12 23:18:41 2012 +0800 pnfsblock: acquire im_lock in _preload_range commit 39e567ae36fe03c2b446e1b83ee3d39bea08f90b upstream. When calling _add_entry, we should take the im_lock to protect agains other modifiers. Signed-off-by: Peng Tao Signed-off-by: Benny Halevy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1f489b2d822abdaf2bf6b7101073edec767e77c3 Author: Miklos Szeredi Date: Tue Jan 10 18:22:25 2012 +0100 fix shrink_dcache_parent() livelock commit eaf5f9073533cde21c7121c136f1c3f072d9cf59 upstream. Two (or more) concurrent calls of shrink_dcache_parent() on the same dentry may cause shrink_dcache_parent() to loop forever. Here's what appears to happen: 1 - CPU0: select_parent(P) finds C and puts it on dispose list, returns 1 2 - CPU1: select_parent(P) locks P->d_lock 3 - CPU0: shrink_dentry_list() locks C->d_lock dentry_kill(C) tries to lock P->d_lock but fails, unlocks C->d_lock 4 - CPU1: select_parent(P) locks C->d_lock, moves C from dispose list being processed on CPU0 to the new dispose list, returns 1 5 - CPU0: shrink_dentry_list() finds dispose list empty, returns 6 - Goto 2 with CPU0 and CPU1 switched Basically select_parent() steals the dentry from shrink_dentry_list() and thinks it found a new one, causing shrink_dentry_list() to think it's making progress and loop over and over. One way to trigger this is to make udev calls stat() on the sysfs file while it is going away. Having a file in /lib/udev/rules.d/ with only this one rule seems to the trick: ATTR{vendor}=="0x8086", ATTR{device}=="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="/bin/true" Then execute the following loop: while true; do echo -bond0 > /sys/class/net/bonding_masters echo +bond0 > /sys/class/net/bonding_masters echo -bond1 > /sys/class/net/bonding_masters echo +bond1 > /sys/class/net/bonding_masters done One fix would be to check all callers and prevent concurrent calls to shrink_dcache_parent(). But I think a better solution is to stop the stealing behavior. This patch adds a new dentry flag that is set when the dentry is added to the dispose list. The flag is cleared in dentry_lru_del() in case the dentry gets a new reference just before being pruned. If the dentry has this flag, select_parent() will skip it and let shrink_dentry_list() retry pruning it. With select_parent() skipping those dentries there will not be the appearance of progress (new dentries found) when there is none, hence shrink_dcache_parent() will not loop forever. Set the flag is also set in prune_dcache_sb() for consistency as suggested by Linus. Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 9ba5dc56ab1d476761ed408742a23ad8290e81d2 Author: Dave Chinner Date: Tue Aug 23 18:56:24 2011 +1000 dcache: use a dispose list in select_parent commit b48f03b319ba78f3abf9a7044d1f436d8d90f4f9 upstream. select_parent currently abuses the dentry cache LRU to provide cleanup features for child dentries that need to be freed. It moves them to the tail of the LRU, then tells shrink_dcache_parent() to calls __shrink_dcache_sb to unconditionally move them to a dispose list (as DCACHE_REFERENCED is ignored). __shrink_dcache_sb() has to relock the dentries to move them off the LRU onto the dispose list, but otherwise does not touch the dentries that select_parent() moved to the tail of the LRU. It then passses the dispose list to shrink_dentry_list() which tries to free the dentries. IOWs, the use of __shrink_dcache_sb() is superfluous - we can build exactly the same list of dentries for disposal directly in select_parent() and call shrink_dentry_list() instead of calling __shrink_dcache_sb() to do that. This means that we avoid long holds on the lru lock walking the LRU moving dentries to the dispose list We also avoid the need to relock each dentry just to move it off the LRU, reducing the numebr of times we lock each dentry to dispose of them in shrink_dcache_parent() from 3 to 2 times. Further, we remove one of the two callers of __shrink_dcache_sb(). This also means that __shrink_dcache_sb can be moved into back into prune_dcache_sb() and we no longer have to handle referenced dentries conditionally, simplifying the code. Signed-off-by: Dave Chinner Signed-off-by: Linus Torvalds Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 053ae10f55886546a5974d9d75a041ff2cea0cbd Author: Haogang Chen Date: Tue Nov 29 18:32:25 2011 -0300 uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map() commit 806e23e95f94a27ee445022d724060b9b45cb64a upstream. There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a large xmap->menu_count is passed from the userspace, the subsequent call to kmalloc() will allocate a buffer smaller than expected. map->menu_count and map->menu_info would later be used in a loop (e.g. in uvc_query_v4l2_ctrl), which leads to out-of-bound access. The patch checks the ioctl argument and returns -EINVAL for zero or too large values in xmap->menu_count. Signed-off-by: Haogang Chen [laurent.pinchart@ideasonboard.com Prevent excessive memory consumption] Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 29ea3528d4b52b185aa86c13dea50dfb98ff6870 Author: David Daney Date: Mon Dec 19 17:42:42 2011 -0800 recordmcount: Fix handling of elf64 big-endian objects. commit 2e885057b7f75035f0b85e02f737891482815a81 upstream. In ELF64, the sh_flags field is 64-bits wide. recordmcount was erroneously treating it as a 32-bit wide field. For little endian objects this works because the flags of interest (SHF_EXECINSTR) reside in the lower 32 bits of the word, and you get the same result with either a 32-bit or 64-bit read. Big endian objects on the other hand do not work at all with this error. The fix: Correctly treat sh_flags as 64-bits wide in elf64 objects. The symptom I observed was that my __start_mcount_loc..__stop_mcount_loc was empty even though ftrace function tracing was enabled. Link: http://lkml.kernel.org/r/1324345362-12230-1-git-send-email-ddaney.cavm@gmail.com Signed-off-by: David Daney Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 4f62b2e5111695e3aae8970a5d467d2e34eb481b Author: Jack Steiner Date: Fri Jan 6 13:19:00 2012 -0600 x86, UV: Update Boot messages for SGI UV2 platform commit da517a08ac5913cd80ce3507cddd00f2a091b13c upstream. SGI UV systems print a message during boot: UV: Found blades Due to packaging changes, the blade count is not accurate for on the next generation of the platform. This patch corrects the count. Signed-off-by: Jack Steiner Link: http://lkml.kernel.org/r/20120106191900.GA19772@sgi.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a8b1c0addba3ec8316b915b7747c590da4fb6576 Author: Miklos Szeredi Date: Thu Jan 12 17:59:46 2012 +0100 fsnotify: don't BUG in fsnotify_destroy_mark() commit fed474857efbed79cd390d0aee224231ca718f63 upstream. Removing the parent of a watched file results in "kernel BUG at fs/notify/mark.c:139". To reproduce add "-w /tmp/audit/dir/watched_file" to audit.rules rm -rf /tmp/audit/dir This is caused by fsnotify_destroy_mark() being called without an extra reference taken by the caller. Reported by Francesco Cosoleto here: https://bugzilla.novell.com/show_bug.cgi?id=689860 Fix by removing the BUG_ON and adding a comment about not accessing mark after the iput. Signed-off-by: Miklos Szeredi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6437ff72d1f301649a35634b426492e597e5d094 Author: Sasha Levin Date: Fri Nov 18 12:14:49 2011 +0200 nfsd: Fix oops when parsing a 0 length export commit b2ea70afade7080360ac55c4e64ff7a5fafdb67b upstream. expkey_parse() oopses when handling a 0 length export. This is easily triggerable from usermode by writing 0 bytes into '/proc/[proc id]/net/rpc/nfsd.fh/channel'. Below is the log: [ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff [ 1402.287632] IP: [] expkey_parse+0x28/0x2e1 [ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160 [ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1402.287632] CPU 1 [ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6 [ 1402.287632] RIP: 0010:[] [] expkey_parse+0x28/0x2e1 [ 1402.287632] RSP: 0018:ffff880077f0fd68 EFLAGS: 00010292 [ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400 [ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0 [ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000 [ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000 [ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0 [ 1402.287632] FS: 00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000 [ 1402.287632] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0 [ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0) [ 1402.287632] Stack: [ 1402.287632] ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e [ 1402.287632] ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0 [ 1402.287632] 0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63 [ 1402.287632] Call Trace: [ 1402.287632] [] ? lock_release+0x1af/0x1bc [ 1402.287632] [] ? might_fault+0x97/0x9e [ 1402.287632] [] ? might_fault+0x4e/0x9e [ 1402.287632] [] cache_do_downcall+0x3e/0x4f [ 1402.287632] [] cache_write.clone.16+0xbb/0x130 [ 1402.287632] [] ? cache_write_pipefs+0x1a/0x1a [ 1402.287632] [] cache_write_procfs+0x19/0x1b [ 1402.287632] [] proc_reg_write+0x8e/0xad [ 1402.287632] [] vfs_write+0xaa/0xfd [ 1402.287632] [] ? fget_light+0x35/0x9e [ 1402.287632] [] sys_write+0x48/0x6f [ 1402.287632] [] system_call_fastpath+0x16/0x1b [ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff [ 1402.287632] 38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85 [ 1402.287632] RIP [] expkey_parse+0x28/0x2e1 [ 1402.287632] RSP [ 1402.287632] CR2: ffff880077c49fff [ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]--- Cc: "J. Bruce Fields" Cc: Neil Brown Cc: linux-nfs@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 4c5ecfd2e16701c2e99397e017212c3ef63243f4 Author: J. Bruce Fields Date: Mon Nov 7 16:37:57 2011 -0500 nfsd4: fix lockowner matching commit b93d87c19821ba7d3ee11557403d782e541071ad upstream. Lockowners are looked up by file as well as by owner, but we were forgetting to do a comparison on the file. This could cause an incorrect result from lockt. (Note looking up the inode from the lockowner is pretty awkward here. The data structures need fixing.) Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit dd96317396ccb415ff4d540d0e69fd1d455a889f Author: J. Bruce Fields Date: Tue Nov 29 17:00:26 2011 -0500 svcrpc: avoid memory-corruption on pool shutdown commit b4f36f88b3ee7cf26bf0be84e6c7fc15f84dcb71 upstream. Socket callbacks use svc_xprt_enqueue() to add an xprt to a pool->sp_sockets list. In normal operation a server thread will later come along and take the xprt off that list. On shutdown, after all the threads have exited, we instead manually walk the sv_tempsocks and sv_permsocks lists to find all the xprt's and delete them. So the sp_sockets lists don't really matter any more. As a result, we've mostly just ignored them and hoped they would go away. Which has gotten us into trouble; witness for example ebc63e531cc6 "svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben Greear noticing that a still-running svc_xprt_enqueue() could re-add an xprt to an sp_sockets list just before it was deleted. The fix was to remove it from the list at the end of svc_delete_xprt(). But that only made corruption less likely--I can see nothing that prevents a svc_xprt_enqueue() from adding another xprt to the list at the same moment that we're removing this xprt from the list. In fact, despite the earlier xpo_detach(), I don't even see what guarantees that svc_xprt_enqueue() couldn't still be running on this xprt. So, instead, note that svc_xprt_enqueue() essentially does: lock sp_lock if XPT_BUSY unset add to sp_sockets unlock sp_lock So, if we do: set XPT_BUSY on every xprt. Empty every sp_sockets list, under the sp_socks locks. Then we're left knowing that the sp_sockets lists are all empty and will stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under the sp_lock and see it set. And *then* we can continue deleting the xprt's. (Thanks to Jeff Layton for being correctly suspicious of this code....) Cc: Ben Greear Cc: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 0832fe15fcb1360f977681569c6493a59d19dd3c Author: J. Bruce Fields Date: Tue Nov 29 11:35:35 2011 -0500 svcrpc: destroy server sockets all at once commit 2fefb8a09e7ed251ae8996e0c69066e74c5aa560 upstream. There's no reason I can see that we need to call sv_shutdown between closing the two lists of sockets. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit bcf641763cf916797543f032714e0478e48c2ef7 Author: J. Bruce Fields Date: Thu Dec 22 18:22:49 2011 -0700 svcrpc: fix double-free on shutdown of nfsd after changing pool mode commit 61c8504c428edcebf23b97775a129c5b393a302b upstream. The pool_to and to_pool fields of the global svc_pool_map are freed on shutdown, but are initialized in nfsd startup only in the SVC_POOL_PERCPU and SVC_POOL_PERNODE cases. They *are* initialized to zero on kernel startup. So as long as you use only SVC_POOL_GLOBAL (the default), this will never be a problem. You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE. However, the following sequence events leads to a double-free: 1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE 2. start nfsd: both fields are initialized. 3. shutdown nfsd: both fields are freed. 4. set SVC_POOL_GLOBAL 5. start nfsd: the fields are left untouched. 6. shutdown nfsd: now we try to free them again. Step 4 is actually unnecessary, since (for some bizarre reason), nfsd automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit b20b30d4d382e151daaee5466ce2427f653170af Author: Steven Rostedt Date: Fri Jan 13 17:53:40 2012 -0500 kconfig/streamline-config.pl: Fix parsing Makefile with variables commit 364212fddaaa60c5a64f67a0f5624ad996ecc8a0 upstream. Thomas Lange reported that when he did a 'make localmodconfig', his config was missing the brcmsmac driver, even though he had the module loaded. Looking into this, I found the file: drivers/net/wireless/brcm80211/brcmsmac/Makefile had the following in the Makefile: MODULEPFX := brcmsmac obj-$(CONFIG_BRCMSMAC) += $(MODULEPFX).o The way streamline-config.pl works, is parsing all the obj-$(CONFIG_FOO) += foo.o lines to find that CONFIG_FOO belongs to the module foo.ko. But in this case, the brcmsmac.o was not used, but a variable in its place. By changing streamline-config.pl to remember defined variables in Makefiles and substituting them when they are used in the obj-X lines, allows Thomas (and others) to have their brcmsmac module stay configured when it is loaded and running "make localmodconfig". Reported-by: Thomas Lange Tested-by: Thomas Lange Cc: Arend van Spriel Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 336f4a0f5025257cf6d0787aab3a3da0043fda7b Author: Steven Rostedt Date: Fri Jan 13 17:50:39 2012 -0500 kconfig/streamline-config.pl: Simplify backslash line concatination commit d060d963e88f3e990cec2fe5214de49de9a49eca upstream. Simplify the way lines ending with backslashes (continuation) in Makefiles is parsed. This is needed to implement a necessary fix. Tested-by: Thomas Lange Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit afe62ad1ea1e3e6e9f36ad115ad435a587cb23e7 Author: Jiri Olsa Date: Mon Dec 5 18:22:48 2011 +0100 ftrace: Fix unregister ftrace_ops accounting commit 30fb6aa74011dcf595f306ca2727254d708b786e upstream. Multiple users of the function tracer can register their functions with the ftrace_ops structure. The accounting within ftrace will update the counter on each function record that is being traced. When the ftrace_ops filtering adds or removes functions, the function records will be updated accordingly if the ftrace_ops is still registered. When a ftrace_ops is removed, the counter of the function records, that the ftrace_ops traces, are decremented. When they reach zero the functions that they represent are modified to stop calling the mcount code. When changes are made, the code is updated via stop_machine() with a command passed to the function to tell it what to do. There is an ENABLE and DISABLE command that tells the called function to enable or disable the functions. But the ENABLE is really a misnomer as it should just update the records, as records that have been enabled and now have a count of zero should be disabled. The DISABLE command is used to disable all functions regardless of their counter values. This is the big off switch and is not the complement of the ENABLE command. To make matters worse, when a ftrace_ops is unregistered and there is another ftrace_ops registered, neither the DISABLE nor the ENABLE command are set when calling into the stop_machine() function and the records will not be updated to match their counter. A command is passed to that function that will update the mcount code to call the registered callback directly if it is the only one left. This means that the ftrace_ops that is still registered will have its callback called by all functions that have been set for it as well as the ftrace_ops that was just unregistered. Here's a way to trigger this bug. Compile the kernel with CONFIG_FUNCTION_PROFILER set and with CONFIG_FUNCTION_GRAPH not set: CONFIG_FUNCTION_PROFILER=y # CONFIG_FUNCTION_GRAPH is not set This will force the function profiler to use the function tracer instead of the function graph tracer. # cd /sys/kernel/debug/tracing # echo schedule > set_ftrace_filter # echo function > current_tracer # cat set_ftrace_filter schedule # cat trace # tracer: nop # # entries-in-buffer/entries-written: 692/68108025 #P:4 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | kworker/0:2-909 [000] .... 531.235574: schedule <-worker_thread -0 [001] .N.. 531.235575: schedule <-cpu_idle kworker/0:2-909 [000] .... 531.235597: schedule <-worker_thread sshd-2563 [001] .... 531.235647: schedule <-schedule_hrtimeout_range_clock # echo 1 > function_profile_enabled # echo 0 > function_porfile_enabled # cat set_ftrace_filter schedule # cat trace # tracer: function # # entries-in-buffer/entries-written: 159701/118821262 #P:4 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | -0 [002] ...1 604.870655: local_touch_nmi <-cpu_idle -0 [002] d..1 604.870655: enter_idle <-cpu_idle -0 [002] d..1 604.870656: atomic_notifier_call_chain <-enter_idle -0 [002] d..1 604.870656: __atomic_notifier_call_chain <-atomic_notifier_call_chain The same problem could have happened with the trace_probe_ops, but they are modified with the set_frace_filter file which does the update at closure of the file. The simple solution is to change ENABLE to UPDATE and call it every time an ftrace_ops is unregistered. Link: http://lkml.kernel.org/r/1323105776-26961-3-git-send-email-jolsa@redhat.com Signed-off-by: Jiri Olsa Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 802f43594d6e4d2ac61086d239153c17873a0428 Author: Gleb Natapov Date: Sun Jan 8 17:07:28 2012 +0200 Unused iocbs in a batch should not be accounted as active. commit 69e4747ee9727d660b88d7e1efe0f4afcb35db1b upstream. Since commit 080d676de095 ("aio: allocate kiocbs in batches") iocbs are allocated in a batch during processing of first iocbs. All iocbs in a batch are automatically added to ctx->active_reqs list and accounted in ctx->reqs_active. If one (not the last one) of iocbs submitted by an user fails, further iocbs are not processed, but they are still present in ctx->active_reqs and accounted in ctx->reqs_active. This causes process to stuck in a D state in wait_for_all_aios() on exit since ctx->reqs_active will never go down to zero. Furthermore since kiocb_batch_free() frees iocb without removing it from active_reqs list the list become corrupted which may cause oops. Fix this by removing iocb from ctx->active_reqs and updating ctx->reqs_active in kiocb_batch_free(). Signed-off-by: Gleb Natapov Reviewed-by: Jeff Moyer Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bb9b57cc544d4c6a88a370338783c1390815d7ed Author: Dan Carpenter Date: Thu Jan 5 02:27:57 2012 -0300 V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy() commit 6c06108be53ca5e94d8b0e93883d534dd9079646 upstream. If ctrls->count is too high the multiplication could overflow and array_size would be lower than expected. Mauro and Hans Verkuil suggested that we cap it at 1024. That comes from the maximum number of controls with lots of room for expantion. $ grep V4L2_CID include/linux/videodev2.h | wc -l 211 Signed-off-by: Dan Carpenter Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 37cd47c536d36a5bd5c7e9b83960aa5913758fec Author: Alexander Elbs Date: Tue Jan 3 23:26:53 2012 -0500 mmc: sd: Fix SDR12 timing regression commit dd8df17fe83483d7ea06ff229895e35a42071599 upstream. This patch fixes a failure to recognize SD cards reported on a Dell Vostro with O2 Micro SD card reader. Patch 49c468f ("mmc: sd: add support for uhs bus speed mode selection") caused the problem, by setting the SDHCI_CTRL_HISPD flag even for legacy timings. Signed-off-by: Alexander Elbs Acked-by: Philip Rakity Acked-by: Arindam Nath Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 5b39b6d126f7133b98e5655e5aedfb87b3e5366c Author: Aaron Lu Date: Wed Dec 28 11:11:12 2011 +0800 mmc: sdhci: Fix tuning timer incorrect setting when suspending host commit c6ced0db08010ed75df221a2946c5228454b38d5 upstream. When suspending host, the tuning timer shoule be deactivated. And the HOST_NEEDS_TUNING flag should be set after tuning timer is deactivated. Signed-off-by: Philip Rakity Signed-off-by: Aaron Lu Acked-by: Adrian Hunter Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 4ed074c646b78c81a5b1b939b8a35c5b7004be00 Author: Girish K S Date: Thu Dec 15 17:27:42 2011 +0530 mmc: core: Fix voltage select in DDR mode commit 913047e9e5787a90696533a9f109552b7694ecc9 upstream. This patch fixes the wrong comparison before setting the interface voltage in DDR mode. The assignment to the variable ddr before comaprison is either ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison is done with the extended csd value if ddr == EXT_CSD_CARD_TYPE_DDR_1_2V. Signed-off-by: Girish K S Acked-by: Subhash Jadavani Acked-by: Philip Rakity Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 69b97cf56b6b8fa15244322bc65eb6008793acaf Author: Jean Delvare Date: Thu Jan 12 20:32:03 2012 +0100 i2c: Fix error value returned by several bus drivers commit 7c1f59c9d5caf3a84f35549b5d58f3c055a68da5 upstream. When adding checks for ACPI resource conflicts to many bus drivers, not enough attention was paid to the error paths, and for several drivers this causes 0 to be returned on error in some cases. Fix this by properly returning a non-zero value on every error. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 172b291a15f4b6fceaba0dd68df118d7f7144198 Author: Artem Bityutskiy Date: Wed Jan 11 15:13:27 2012 +0200 UBIFS: make debugging messages light again commit 1f5d78dc4823a85f112aaa2d0f17624f8c2a6c52 upstream. We switch to dynamic debugging in commit 56e46742e846e4de167dde0e1e1071ace1c882a5 but did not take into account that now we do not control anymore whether a specific message is enabled or not. So now we lock the "dbg_lock" and release it in every debugging macro, which make them not so light-weight. This commit removes the "dbg_lock" protection from the debugging macros to fix the issue. The downside is that now our DBGKEY() stuff is broken, but this is not critical at all and will be fixed later. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 6aeb366d6a7e5cc3c2ab1666751c493c9c3e87e5 Author: Artem Bityutskiy Date: Tue Jan 10 19:32:30 2012 +0200 UBIFS: fix debugging messages commit d34315da9146253351146140ea4b277193ee5e5f upstream. Patch 56e46742e846e4de167dde0e1e1071ace1c882a5 broke UBIFS debugging messages: before that commit when UBIFS debugging was enabled, users saw few useful debugging messages after mount. However, that patch turned 'dbg_msg()' into 'pr_debug()', so to enable the debugging messages users have to enable them first via /sys/kernel/debug/dynamic_debug/control, which is very impractical. This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just as it was before the breakage. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit f15be6f6ce84f1e776abfe51bf52f3aaf4d4e5e9 Author: Richard Weinberger Date: Thu Dec 22 16:12:57 2011 +0100 UBI: make vid_hdr non-static commit 6bdccffe8c4268d02f71873102131fb6ed37ed9a upstream. Remove 'static' modifier from the 'vid_hdr' local variable. I do not know how it slipped in, but this is a bug and will break UBI if someone attaches 2 UBI volumes at the same time. Artem: amended teh commit message, added -stable. Signed-off-by: Richard Weinberger Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit a6027dbd01c08236f2182ddb6c22aa5712fed7c6 Author: Artem Bityutskiy Date: Tue Jan 10 19:32:30 2012 +0200 UBI: fix debugging messages commit 72f0d453d81d35087b1d3ad7c8285628c2be6e1d upstream. Patch ab50ff684707031ed4bad2fdd313208ae392e5bb broke UBI debugging messages: before that commit when UBI debugging was enabled, users saw few useful debugging messages after attaching an MTD device. However, that patch turned 'dbg_msg()' into 'pr_debug()', so to enable the debugging messages users have to enable them first via /sys/kernel/debug/dynamic_debug/control, which is very impractical. This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just as it was before the breakage. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 9a9cc2b976936fbe82f40f4b0c5a1606b3bc187d Author: Richard Weinberger Date: Fri Jan 13 15:07:40 2012 +0100 UBI: fix nameless volumes handling commit 4a59c797a18917a5cf3ff7ade296b46134d91e6a upstream. Currently it's possible to create a volume without a name. E.g: ubimkvol -n 32 -s 2MiB -t static /dev/ubi0 -N "" After that vtbl_check() will always fail because it does not permit empty strings. Signed-off-by: Richard Weinberger Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 5b781fb93a30489403b4237fb68492953aa170b0 Author: Ludwig Nussel Date: Tue Nov 15 14:46:46 2011 -0800 x86: Fix mmap random address range commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream. On x86_32 casting the unsigned int result of get_random_int() to long may result in a negative value. On x86_32 the range of mmap_rnd() therefore was -255 to 255. The 32bit mode on x86_64 used 0 to 255 as intended. The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c") in January 2008. Signed-off-by: Ludwig Nussel Cc: Linus Torvalds Cc: harvey.harrison@gmail.com Cc: "H. Peter Anvin" Cc: Harvey Harrison Signed-off-by: Andrew Morton Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e6e6e8cd34116b467c4201ef5c5d354f9919005c Author: KAMEZAWA Hiroyuki Date: Thu Jan 12 17:17:44 2012 -0800 memcg: add mem_cgroup_replace_page_cache() to fix LRU issue commit ab936cbcd02072a34b60d268f94440fd5cf1970b upstream. Commit ef6a3c6311 ("mm: add replace_page_cache_page() function") added a function replace_page_cache_page(). This function replaces a page in the radix-tree with a new page. WHen doing this, memory cgroup needs to fix up the accounting information. memcg need to check PCG_USED bit etc. In some(many?) cases, 'newpage' is on LRU before calling replace_page_cache(). So, memcg's LRU accounting information should be fixed, too. This patch adds mem_cgroup_replace_page_cache() and removes the old hooks. In that function, old pages will be unaccounted without touching res_counter and new page will be accounted to the memcg (of old page). WHen overwriting pc->mem_cgroup of newpage, take zone->lru_lock and avoid races with LRU handling. Background: replace_page_cache_page() is called by FUSE code in its splice() handling. Here, 'newpage' is replacing oldpage but this newpage is not a newly allocated page and may be on LRU. LRU mis-accounting will be critical for memory cgroup because rmdir() checks the whole LRU is empty and there is no account leak. If a page is on the other LRU than it should be, rmdir() will fail. This bug was added in March 2011, but no bug report yet. I guess there are not many people who use memcg and FUSE at the same time with upstream kernels. The result of this bug is that admin cannot destroy a memcg because of account leak. So, no panic, no deadlock. And, even if an active cgroup exist, umount can succseed. So no problem at shutdown. Signed-off-by: KAMEZAWA Hiroyuki Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: Miklos Szeredi Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c9bc8b31648585fa3c985f6ac52a07a1d85f0e4a Author: Rajkumar Manoharan Date: Mon Jan 9 15:37:53 2012 +0530 ath9k: Fix regression in channelwidth switch at the same channel commit 1a19f77f3642b8194ad9cf55548cc5d92e841766 upstream. The commit "ath9k: Fix invalid noisefloor reading due to channel update" preserves the current channel noisefloor readings before updating channel type at the same channel index. It is also updating the curchan pointer. As survey updation is also referring curchan pointer to fetch the appropriate index, which might leads to invalid memory access. This patch partially reverts the change and stores the noise floor history buffer before updating channel type w/o updating curchan. Cc: Gary Morain Cc: Paul Stewart Reported-by: Mohammed Shafi Shajakhan Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 62b2e1674ef4976f5a6535071dcd76071c571cb6 Author: Stanislaw Gruszka Date: Wed Jan 11 09:26:54 2012 +0100 mac80211: fix rx->key NULL pointer dereference in promiscuous mode commit 1140afa862842ac3e56678693050760edc4ecde9 upstream. Since: commit 816c04fe7ef01dd9649f5ccfe796474db8708be5 Author: Christian Lamparter Date: Sat Apr 30 15:24:30 2011 +0200 mac80211: consolidate MIC failure report handling is possible to that we dereference rx->key == NULL when driver set RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in promiscuous mode. This happen with rt73usb and rt61pci at least. Before the commit we always check rx->key against NULL, so I assume fix should be done in mac80211 (also mic_fail path has similar check). References: https://bugzilla.redhat.com/show_bug.cgi?id=769766 http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html Reported-by: Stuart D Gathman Reported-by: Kai Wohlfahrt Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 8bf3ae0e91c183f47b328a232c94a152de540182 Author: Larry Finger Date: Wed Jan 4 20:50:47 2012 -0600 rtl8192se: Fix BUG caused by failure to check skb allocation commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream. When downloading firmware into the device, the driver fails to check the return when allocating an skb. When the allocation fails, a BUG can be generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit c656fce141afb8db4e7dc5a3af1e82308202698a Author: Fabio Estevam Date: Thu Jan 12 17:20:20 2012 -0800 include/linux/crash_dump.h needs elf.h commit 1f536b9e9f85456df93614b3c2f6a1a2b7d7cb9b upstream. Building an ARM target we get the following warnings: CC arch/arm/kernel/setup.o In file included from arch/arm/kernel/setup.c:39: arch/arm/include/asm/elf.h:102:1: warning: "vmcore_elf64_check_arch" redefined In file included from arch/arm/kernel/setup.c:24: include/linux/crash_dump.h:30:1: warning: this is the location of the previous definition Quoting Russell King: "linux/crash_dump.h makes no attempt to include asm/elf.h, but it depends on stuff in asm/elf.h to determine how stuff inside this file is defined at parse time. So, if asm/elf.h is included after linux/crash_dump.h or not at all, you get a different result from the situation where asm/elf.h is included before." So add elf.h header to crash_dump.h to avoid this problem. The original discussion about this can be found at: http://www.spinics.net/lists/arm-kernel/msg154113.html Signed-off-by: Fabio Estevam Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 197d67f1225e31f8a3572aef93613c0702ee61a7 Author: Jussi Kivilinna Date: Tue Jan 10 06:40:17 2012 +0000 asix: fix setting custom MAC address on Asix 88772 devices commit 8ef66bdc4bda6aac2dae73b84d79dc8c2db33637 upstream. In kernel v3.2 initialization sequence for Asix 88772 devices was changed so that hardware is reseted on every time interface is brought up (ifconfig up), instead just at USB probe time. This causes problem with setting custom MAC address to device as ax88772_reset causes reload of MAC address from EEPROM. This patch fixes the issue by rewriting MAC address at end of ax88772_reset. Signed-off-by: Jussi Kivilinna Acked-by: Grant Grundler Cc: Allan Chou Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fcf99ac631b61e6937ed10cd1b53a5b3dab29052 Author: Jussi Kivilinna Date: Tue Jan 10 06:40:23 2012 +0000 asix: fix setting custom MAC address on Asix 88178 devices commit 71bc5d94061516c4e70303570128797bcf768b10 upstream. In kernel v3.2 initialization sequence for Asix 88178 devices was changed so that hardware is reseted on every time interface is brought up (ifconfig up), instead just at USB probe time. This causes problem with setting custom MAC address to device as ax88178_reset causes reload of MAC address from EEPROM. This patch fixes the issue by rewriting MAC address at end of ax88178_reset. Signed-off-by: Jussi Kivilinna Acked-by: Grant Grundler Cc: Allan Chou Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40cfe76cac73842dc10e26ca9909e37f1b6651e9 Author: Bjorn Helgaas Date: Thu Jan 5 14:27:24 2012 -0700 PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB commit eb31aae8cb5eb54e234ed2d857ddac868195d911 upstream. Some Dell BIOSes have MCFG tables that don't report the entire MMCONFIG area claimed by the chipset. If we move PCI devices into that claimed-but-unreported area, they don't work. This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as needed to cover the entire area. Example problem scenario: BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved) Fam 10h mmconf [d0000000, dfffffff] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000) pnp 00:0c: [mem 0xd0000000-0xd3ffffff] pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff] Reported-by: Lisa Salimbas Reported-by: Tested-by: dann frazier References: https://bugzilla.kernel.org/show_bug.cgi?id=31602 References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043 References: https://bugzilla.redhat.com/show_bug.cgi?id=770308 Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 65722fdd70758e2f1ac30f42f54c056631062fd5 Author: Eric Dumazet Date: Tue Dec 13 04:57:06 2011 +0100 slub: fix a possible memleak in __slab_alloc() commit 73736e0387ba0e6d2b703407b4d26168d31516a7 upstream. Zhihua Che reported a possible memleak in slub allocator on CONFIG_PREEMPT=y builds. It is possible current thread migrates right before disabling irqs in __slab_alloc(). We must check again c->freelist, and perform a normal allocation instead of scratching c->freelist. Many thanks to Zhihua Che for spotting this bug, introduced in 2.6.39 V2: Its also possible an IRQ freed one (or several) object(s) and populated c->freelist, so its not a CONFIG_PREEMPT only problem. Reported-by: Zhihua Che Signed-off-by: Eric Dumazet Acked-by: Christoph Lameter Signed-off-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman commit 858452ff4198a85874a7ee97da454d4a5d67938e Author: Roberto Sassu Date: Mon Dec 19 15:57:28 2011 +0100 ima: fix invalid memory reference commit 7b7e5916aa2f46e57f8bd8cb89c34620ebfda5da upstream. Don't free a valid measurement entry on TPM PCR extend failure. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 4483c1f05a5e7ac2b14b735e1db11950010e8f4c Author: Roberto Sassu Date: Mon Dec 19 15:57:27 2011 +0100 ima: free duplicate measurement memory commit 45fae7493970d7c45626ccd96d4a74f5f1eea5a9 upstream. Info about new measurements are cached in the iint for performance. When the inode is flushed from cache, the associated iint is flushed as well. Subsequent access to the inode will cause the inode to be re-measured and will attempt to add a duplicate entry to the measurement list. This patch frees the duplicate measurement memory, fixing a memory leak. Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 45c5b2b95f829018321325129d824a6154d5f955 Author: NeilBrown Date: Mon Jan 9 01:41:51 2012 +1100 md/raid1: perform bad-block tests for WriteMostly devices too. commit 307729c8bc5b5a41361af8af95906eee7552acb1 upstream. We normally try to avoid reading from write-mostly devices, but when we do we really have to check for bad blocks and be sure not to try reading them. With the current code, best_good_sectors might not get set and that causes zero-length read requests to be send down which is very confusing. This bug was introduced in commit d2eb35acfdccbe2 and so the patch is suitable for 3.1.x and 3.2.x Reported-and-tested-by: Michał Mirosław Reported-and-tested-by: Art -kwaak- van Breemen Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ee1f334f2f580ff09f7c1f83be46aa2bbb4d5f6a Author: Ian Campbell Date: Wed Jan 4 09:34:49 2012 +0000 xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX. commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream. Haogang Chen found out that: There is a potential integer overflow in process_msg() that could result in cross-domain attack. body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH); When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent call to xb_read() would write to a zero-length buffer. The other end of this connection is always the xenstore backend daemon so there is no guest (malicious or otherwise) which can do this. The xenstore daemon is a trusted component in the system. However this seem like a reasonable robustness improvement so we should have it. And Ian when read the API docs found that: The payload length (len field of the header) is limited to 4096 (XENSTORE_PAYLOAD_MAX) in both directions. If a client exceeds the limit, its xenstored connection will be immediately killed by xenstored, which is usually catastrophic from the client's point of view. Clients (particularly domains, which cannot just reconnect) should avoid this. so this patch checks against that instead. This also avoids a potential integer overflow pointed out by Haogang Chen. Signed-off-by: Ian Campbell Cc: Haogang Chen Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 312544d8eac340d3ada92dbd2c60c63d229fbcf6 Author: nagalakshmi.nandigama@lsi.com Date: Thu Dec 1 07:53:08 2011 +0530 SCSI: mpt2sas : Fix for memory allocation error for large host credits commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream. The amount of memory required for tracking chain buffers is rather large, and when the host credit count is big, memory allocation failure occurs inside __get_free_pages. The fix is to limit the number of chains to 100,000. In addition, the number of host credits is limited to 30,000 IOs. However this limitation can be overridden this using the command line option max_queue_depth. The algorithm for calculating the reply_post_queue_depth is changed so that it is equal to (reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2). Signed-off-by: Nagalakshmi Nandigama Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7af050182f68de53d4c323367c793c580e956041 Author: nagalakshmi.nandigama@lsi.com Date: Thu Dec 1 07:52:56 2011 +0530 SCSI: mpt2sas: Release spinlock for the raid device list before blocking it commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream. Added code to release the spinlock that is used to protect the raid device list before calling a function that can block. The blocking was causing a reschedule, and subsequently it is tried to acquire the same lock, resulting in a panic (NMI Watchdog detecting a CPU lockup). Signed-off-by: Nagalakshmi Nandigama Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8caedf258f365a5dd81af920fcef8be798305a74 Author: Bjorn Helgaas Date: Thu Jan 12 08:01:40 2012 -0700 x86/PCI: build amd_bus.o only when CONFIG_AMD_NB=y commit 5cf9a4e69c1ff0ccdd1d2b7404f95c0531355274 upstream. We only need amd_bus.o for AMD systems with PCI. arch/x86/pci/Makefile already depends on CONFIG_PCI=y, so this patch just adds the dependency on CONFIG_AMD_NB. Cc: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dc106336ae990903ef9c1ccc459b719166ec504e Author: Bjorn Helgaas Date: Thu Jan 5 14:27:19 2012 -0700 x86/PCI: amd: factor out MMCONFIG discovery commit 24d25dbfa63c376323096660bfa9ad45a08870ce upstream. This factors out the AMD native MMCONFIG discovery so we can use it outside amd_bus.c. amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the PCI resources. We may also need the MMCONFIG information to work around BIOS defects in the ACPI MCFG table. Cc: Borislav Petkov Cc: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 11d4681a71b98cf0b07521ea50168476b1194e7b Author: Gary Hade Date: Mon Nov 14 15:42:16 2011 -0800 x86/PCI: Ignore CPU non-addressable _CRS reserved memory resources commit ae5cd86455381282ece162966183d3f208c6fad7 upstream. This assures that a _CRS reserved host bridge window or window region is not used if it is not addressable by the CPU. The new code either trims the window to exclude the non-addressable portion or totally ignores the window if the entire window is non-addressable. The current code has been shown to be problematic with 32-bit non-PAE kernels on systems where _CRS reserves resources above 4GB. Signed-off-by: Gary Hade Reviewed-by: Bjorn Helgaas Cc: Thomas Renninger Cc: linux-kernel@vger.kernel.org Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 0a2a71a5947041a86ea6617a963ce2afad7f6352 Author: Eric W. Biederman Date: Mon Oct 17 11:46:06 2011 -0700 PCI: msi: Disable msi interrupts when we initialize a pci device commit a776c491ca5e38c26d9f66923ff574d041e747f4 upstream. I traced a nasty kexec on panic boot failure to the fact that we had screaming msi interrupts and we were not disabling the msi messages at kernel startup. The booting kernel had not enabled those interupts so was not prepared to handle them. I can see no reason why we would ever want to leave the msi interrupts enabled at boot if something else has enabled those interrupts. The pci spec specifies that msi interrupts should be off by default. Drivers are expected to enable the msi interrupts if they want to use them. Our interrupt handling code reprograms the interrupt handlers at boot and will not be be able to do anything useful with an unexpected interrupt. This patch applies cleanly all of the way back to 2.6.32 where I noticed the problem. Signed-off-by: Eric W. Biederman Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit c1c3cd99e1c1e3a4a816cab64599b27553864396 Author: Alex Williamson Date: Wed Nov 16 09:24:16 2011 -0700 PCI: Fix PCI_EXP_TYPE_RC_EC value commit 1830ea91c20b06608f7cdb2455ce05ba834b3214 upstream. Spec shows this as 1010b = 0xa Signed-off-by: Alex Williamson Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 50bc9144d4c0e15a6fcdc1b7a5accb7e2cd4aa11 Author: Artem Bityutskiy Date: Thu Jan 5 10:47:18 2012 +0200 UBI: fix use-after-free on error path commit e57e0d8e818512047fe379157c3f77f1b9fabffb upstream. When we fail to erase a PEB, we free the corresponding erase entry object, but then re-schedule this object if the error code was something like -EAGAIN. Obviously, it is a bug to use the object after we have freed it. Reported-by: Emese Revfy Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 73461014f2de68f1dbca13897af0feb77872b8f5 Author: Bhavesh Parekh Date: Wed Nov 30 17:43:42 2011 +0530 UBI: fix missing scrub when there is a bit-flip commit e801e128b2200c40a0ec236cf2330b2586b6e05a upstream. Under some cases, when scrubbing the PEB if we did not get the lock on the PEB it fails to scrub. Add that PEB again to the scrub list Artem: minor amendments. Signed-off-by: Bhavesh Parekh Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 51437e46e24caa74d45a30a0eb130d74bdf07db9 Author: David Herrmann Date: Wed Dec 7 21:33:59 2011 +0100 HID: wiimote: Select INPUT_FF_MEMLESS commit ef6f41157f3864d9bf42671b2ed66062dcafb72e upstream. We depend on memless force-feedback support, therefore correctly select the related config options. Reported-by: Randy Dunlap Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 44b39e3bed1fe38ccbcc35e71780e3d864f8607c Author: Chase Douglas Date: Mon Nov 7 11:08:05 2011 -0800 HID: bump maximum global item tag report size to 96 bytes commit e46e927b9b7e8d95526e69322855243882b7e1a3 upstream. This allows the latest N-Trig devices to function properly. BugLink: https://bugs.launchpad.net/bugs/724831 Signed-off-by: Chase Douglas Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7462f4ae1836661658d4ab2d1359b1f134613623 Author: Jeff Layton Date: Tue Dec 20 06:57:45 2011 -0500 nfs: fix regression in handling of context= option in NFSv4 commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8 upstream. Setting the security context of a NFSv4 mount via the context= mount option is currently broken. The NFSv4 codepath allocates a parsed options struct, and then parses the mount options to fill it. It eventually calls nfs4_remote_mount which calls security_init_mnt_opts. That clobbers the lsm_opts struct that was populated earlier. This bug also looks like it causes a small memory leak on each v4 mount where context= is used. Fix this by moving the initialization of the lsm_opts into nfs_alloc_parsed_mount_data. Also, add a destructor for nfs_parsed_mount_data to make it easier to free all of the allocations hanging off of it, and to ensure that the security_free_mnt_opts is called whenever security_init_mnt_opts is. I believe this regression was introduced quite some time ago, probably by commit c02d7adf. Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 628fc192adbaae0c6178b9015fb916ce61d72b36 Author: Andy Adamson Date: Wed Dec 7 11:55:27 2011 -0500 NFSv4: include bitmap in nfsv4 get acl data commit bf118a342f10dafe44b14451a1392c3254629a1f upstream. The NFSv4 bitmap size is unbounded: a server can return an arbitrary sized bitmap in an FATTR4_WORD0_ACL request. Replace using the nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data xdr length to the (cached) acl page data. This is a general solution to commit e5012d1f "NFSv4.1: update nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs. Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved. Signed-off-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 42a50a981577e43928cc23b048cf0a3833bb8da4 Author: NeilBrown Date: Wed Nov 16 11:46:31 2011 +1100 NFS - fix recent breakage to NFS error handling. commit 2edb6bc3852c681c0d948245bd55108dc6407604 upstream. From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Wed, 16 Nov 2011 09:39:05 +1100 Subject: NFS - fix recent breakage to NFS error handling. commit 02c24a82187d5a628c68edfe71ae60dc135cd178 made a small and presumably unintended change to write error handling in NFS. Previously an error from filemap_write_and_wait_range would only be of interest if nfs_file_fsync did not return an error. After this commit, an error from filemap_write_and_wait_range would mean that (the rest of) nfs_file_fsync would not even be called. This means that: 1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC. 2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are synchronous. This patch restores previous behaviour. Cc: Josef Bacik Cc: Jan Kara Cc: Al Viro Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit cf3781f0c3addd8d6419d487f204e94e4d0701a8 Author: Andy Adamson Date: Wed Nov 9 13:58:20 2011 -0500 NFSv4.1: fix backchannel slotid off-by-one bug commit 61f2e5106582d02f30b6807e3f9c07463c572ccb upstream. Signed-off-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 873829e045cc6ad99176d6c1326b3fe856e77312 Author: Chuck Lever Date: Mon Dec 5 15:40:30 2011 -0500 NFS: Retry mounting NFSROOT commit 43717c7daebf10b43f12e68512484b3095bb1ba5 upstream. Lukas Razik reports that on his SPARC system, booting with an NFS root file system stopped working after commit 56463e50 "NFS: Use super.c for NFSROOT mount option parsing." We found that the network switch to which Lukas' client was attached was delaying access to the LAN after the client's NIC driver reported that its link was up. The delay was longer than the timeouts used in the NFS client during mounting. NFSROOT worked for Lukas before commit 56463e50 because in those kernels, the client's first operation was an rpcbind request to determine which port the NFS server was listening on. When that request failed after a long timeout, the client simply selected the default NFS port (2049). By that time the switch was allowing access to the LAN, and the mount succeeded. Neither of these client behaviors is desirable, so reverting 56463e50 is really not a choice. Instead, introduce a mechanism that retries the NFSROOT mount request several times. This is the same tactic that normal user space NFS mounts employ to overcome server and network delays. Signed-off-by: Lukas Razik [ cel: match kernel coding style, add proper patch description ] [ cel: add exponential back-off ] Signed-off-by: Chuck Lever Tested-by: Lukas Razik Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8a272277cbb031727aa96829e033b258ec6b26ee Author: Boaz Harrosh Date: Fri Jan 6 09:31:20 2012 +0200 pnfs-obj: Must return layout on IO error commit fe0fe83585f88346557868a803a479dfaaa0688a upstream. As mandated by the standard. In case of an IO error, a pNFS objects layout driver must return it's layout. This is because all device errors are reported to the server as part of the layout return buffer. This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR is done, through a bit flag on the pnfs_layoutdriver_type->flags member. The flag is set by the layout driver that wants a layout_return preformed at pnfs_ld_{write,read}_done in case of an error. (Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr because this code is never called outside of pnfs.c and pnfs IO paths) Without this patch 3.[0-2] Kernels leak memory and have an annoying WARN_ON after every IO error utilizing the pnfs-obj driver. Signed-off-by: Boaz Harrosh Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 246a6b572458af000a216f1e00ba1dea9414c7d6 Author: Boaz Harrosh Date: Fri Jan 6 09:28:12 2012 +0200 pnfs-obj: pNFS errors are communicated on iodata->pnfs_error commit 5c0b4129c07b902b27d3f3ebc087757f534a3abd upstream. Some time along the way pNFS IO errors were switched to communicate with a special iodata->pnfs_error member instead of the regular RPC members. But objlayout was not switched over. Fix that! Without this fix any IO error is hanged, because IO is not switched to MDS and pages are never cleared or read. [Applies to 3.2.0. Same bug different patch for 3.1/0 Kernels] Signed-off-by: Boaz Harrosh Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 27bdee9ac306dbc12036706cbf767a27cb34ca7d Author: Michel Dänzer Date: Thu Jan 5 18:42:17 2012 +0100 radeon: Fix disabling PCI bus mastering on big endian hosts. commit 3df96909b75835d487a9178761622b0cbd7310d4 upstream. It would previously write basically random bits to PCI configuration space... Not very surprising that the GPU tended to stop responding completely. The resulting MCE even froze the whole machine sometimes. Now resetting the GPU after a lockup has at least a fighting chance of succeeding. Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 7ca755c00ad8f97fea8b06dac6d69e2aaa6c7a3d Author: Alex Deucher Date: Tue Jan 3 09:48:38 2012 -0500 drm/radeon/kms: disable writeback on pre-R300 asics commit 28eebb703e28bc455ba704adb1026f76649b768c upstream. We often end up missing fences on older asics with writeback enabled which leads to delays in the userspace accel code, so just disable it by default on those asics. Reported-by: Helge Deller Reported-by: Dave Airlie Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit d21e9677f82d619967c6c918038343fe12bb0f4a Author: Rafał Miłecki Date: Fri Dec 23 20:32:18 2011 +0100 drm/radeon/kms: workaround invalid AVI infoframe checksum issue commit 92db7f6c860b8190571a9dc1fcbc16d003422fe8 upstream. This change was verified to fix both issues with no video I've investigated. I've also checked checksum calculation with fglrx on: RV620, HD54xx, HD5450, HD6310, HD6320. Signed-off-by: Rafał Miłecki Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c2a3399e462a3ba07fffbe641536a71cacd0bea7 Author: Takashi Iwai Date: Wed Jan 11 12:34:11 2012 +0100 ALSA: hda - Fix the lost power-setup of seconary pins after PM resume commit f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33 upstream. When multiple headphone or other detectable output pins are present, the power-map has to be updated after resume appropriately, but the current driver doesn't check all pins but only the first pin (since it's enough to check it for the mute-behavior). This resulted in the silent output from the secondary outputs after PM resume. This patch fixes the problem by checking all pins at (re-)init time. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740347 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0c7fe97698c04555a492c3fddc3d64efb7bad674 Author: Takashi Iwai Date: Tue Jan 10 15:16:02 2012 +0100 ALSA: hda - Fix the detection of "Loopback Mixing" control for VIA codecs commit 4808d12d1dddb046ec86425e5f6766f02e950292 upstream. Currently the driver checks only the out_mix_path[] for the primary output route for judging whether to create the loopback-mixing control or not. But, there are cases where aamix-routing is available only on headphone or speaker paths but not on the primary output path. So, the driver ignores such cases inappropriately. This patch fixes the check of the loopback-mixing control by testing all mix-routing paths. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6dcb7c2f7d7253ad5a7aec91f6aafdaaa221a2b4 Author: Takashi Iwai Date: Tue Jan 10 12:41:22 2012 +0100 ALSA: hda - Return the error from get_wcaps_type() for invalid NIDs commit 3a90274de3548ebb2aabfbf488cea8e275a73dc6 upstream. When an invalid NID is given, get_wcaps() returns zero as the error, but get_wcaps_type() takes it as the normal value and returns a bogus AC_WID_AUD_OUT value. This confuses the parser. With this patch, get_wcaps_type() returns -1 when value 0 is given, i.e. an invalid NID is passed to get_wcaps(). Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ecb40a3adadfabb13c7a1548944ff6a0442f1c01 Author: Takashi Iwai Date: Tue Jan 10 08:59:56 2012 +0100 ALSA: hda - Use auto-parser for HP laptops with cx20459 codec commit de4da59e480cdf1075b33dbaf8078fc87bc52241 upstream. These laptops can work well with the auto-parser and their BIOS setups, and in addition, the auto-parser fixes the problem with S3/S4 where the unsol event handling is killed after resume due to fallback to the single-cmd mode. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740115 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b4133832cf270a39c961edf9777d2187eb2b7977 Author: Takashi Iwai Date: Mon Jan 9 11:37:20 2012 +0100 ALSA: usb-audio - Avoid flood of frame-active debug messages commit 80c8a2a372599e604b04a9c568952fe39cd1851d upstream. With some buggy devices, the usb-audio driver may give "frame xxx active" kernel messages too often. Better to keep it as debug-only using snd_printdd(), and also add the rate-limit for avoiding floods. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=738681 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 662a1ccf42d1a08b9fb8d5709c19748bb40e88e1 Author: Pavel Hofman Date: Thu Jan 5 23:05:18 2012 +0100 ALSA: ice1724 - Check for ac97 to avoid kernel oops commit e7848163aa2a649d9065f230fadff80dc3519775 upstream. Cards with identical PCI ids but no AC97 config in EEPROM do not have the ac97 field initialized. We must check for this case to avoid kernel oops. Signed-off-by: Pavel Hofman Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c3353b061da651f3c20bd2e795f00939f04c77c7 Author: David Henningsson Date: Mon Jan 2 12:40:16 2012 +0100 ALSA: HDA: Fix automute for Cirrus Logic 421x commit 78e2a928e377d5124932d4399c6c581908b027a0 upstream. There was a bug in the automute logic causing speakers not to mute when headphones were plugged in. Tested-by: Hsin-Yi Chen Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 54e9649c2747cc22848a7c42f75b22e8b4f5880d Author: David Henningsson Date: Mon Jan 2 12:40:15 2012 +0100 ALSA: HDA: Fix master control for Cirrus Logic 421X commit 40d03e63e91af8ddccdfd5a536cc2a6e51433e1d upstream. The control name "HP/Speakers" is non-standard, and since there is only one DAC on this chip there is no need for a virtual master anyway. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 634cc98dded075e80202f28fc1424bb503d4509e Author: Karsten Wiese Date: Fri Dec 30 01:42:01 2011 +0100 ALSA: snd-usb-us122l: Delete calls to preempt_disable commit d0f3a2eb9062560bebca8b923424f3ca02a331ba upstream. They are not needed here. Signed-off-by: Karsten Wiese Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e2860111eaf589699ff399191dd13b5d3409ef2b Author: Xi Wang Date: Tue Jan 10 11:51:10 2012 -0500 ext4: fix undefined behavior in ext4_fill_flex_info() commit d50f2ab6f050311dbf7b8f5501b25f0bf64a439b upstream. Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by zero when trying to mount a corrupted file system") fixes CVE-2009-4307 by performing a sanity check on s_log_groups_per_flex, since it can be set to a bogus value by an attacker. sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex; groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex < 2) { ... } This patch fixes two potential issues in the previous commit. 1) The sanity check might only work on architectures like PowerPC. On x86, 5 bits are used for the shifting amount. That means, given a large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36 is essentially 1 << 4 = 16, rather than 0. This will bypass the check, leaving s_log_groups_per_flex and groups_per_flex inconsistent. 2) The sanity check relies on undefined behavior, i.e., oversized shift. A standard-confirming C compiler could rewrite the check in unexpected ways. Consider the following equivalent form, assuming groups_per_flex is unsigned for simplicity. groups_per_flex = 1 << sbi->s_log_groups_per_flex; if (groups_per_flex == 0 || groups_per_flex == 1) { We compile the code snippet using Clang 3.0 and GCC 4.6. Clang will completely optimize away the check groups_per_flex == 0, leaving the patched code as vulnerable as the original. GCC keeps the check, but there is no guarantee that future versions will do the same. Signed-off-by: Xi Wang Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 19800ba5243e10668bbed7eef85ddd16452e5d26 Author: Djalal Harouni Date: Wed Jan 4 17:09:52 2012 -0500 ext4: add missing ext4_resize_end on error paths commit 014a1770371a028d22f364718c805f4216911ecd upstream. Online resize ioctls 'EXT4_IOC_GROUP_EXTEND' and 'EXT4_IOC_GROUP_ADD' call ext4_resize_begin() to check permissions and to set the EXT4_RESIZING bit lock, they do their work and they must finish with ext4_resize_end() which calls clear_bit_unlock() to unlock and to avoid -EBUSY errors for the next resize operations. This patch adds the missing ext4_resize_end() calls on error paths. Patch tested. Signed-off-by: Djalal Harouni Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 36a8176166397d103352670327e1b20d334b5c7d Author: Ben Hutchings Date: Tue Jan 10 15:11:02 2012 -0800 drivers/rtc/interface.c: fix alarm rollover when day or month is out-of-range commit e74a8f2edb92cb690b467cea0ab652c509e9f624 upstream. Commit f44f7f96a20a ("RTC: Initialize kernel state from RTC") introduced a potential infinite loop. If an alarm time contains a wildcard month and an invalid day (> 31), or a wildcard year and an invalid month (>= 12), the loop searching for the next matching date will never terminate. Treat the invalid values as wildcards. Fixes , Reported-by: leo weppelman Reported-by: "P. van Gaans" Signed-off-by: Ben Hutchings Signed-off-by: Jonathan Nieder Cc: Mark Brown Cc: Marcelo Roberto Jimenez Cc: Thomas Gleixner Cc: John Stultz Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0fbc846f71dd621275acbca25a7996a8dae37fca Author: Wolfram Sang Date: Tue Nov 29 15:34:08 2011 +0100 mtd: tests: stresstest: bail out if device has not enough eraseblocks commit 2f4478ccff7df845dc9c0f8996a96373122c4417 upstream. stresstest needs at least two eraseblocks. Bail out gracefully if that condition is not met. Fixes the following 'division by zero' OOPS: [ 619.100000] mtd_stresstest: MTD device size 131072, eraseblock size 131072, page size 2048, count of eraseblocks 1, pages per eraseblock 64, OOB size 64 [ 619.120000] mtd_stresstest: scanning for bad eraseblocks [ 619.120000] mtd_stresstest: scanned 1 eraseblocks, 0 are bad [ 619.130000] mtd_stresstest: doing operations [ 619.130000] mtd_stresstest: 0 operations done [ 619.140000] Division by zero in kernel. ... caused by /* Read or write up 2 eraseblocks at a time - hence 'ebcnt - 1' */ eb %= (ebcnt - 1); Signed-off-by: Wolfram Sang Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 4eb4226e5e0ae2607b0020299a4452760c4f24db Author: Brian Norris Date: Mon Nov 7 15:51:05 2011 -0800 mtd: mtd_blkdevs: don't increase 'open' count on error path commit 342ff28f5a2e5aa3236617bd2bddf6c749677ef2 upstream. Some error paths in mtd_blkdevs were fixed in the following commit: commit 94735ec4044a6d318b83ad3c5794e931ed168d10 mtd: mtd_blkdevs: fix error path in blktrans_open But on these error paths, the block device's `dev->open' count is already incremented before we check for errors. This meant that, while the error path was handled correctly on the first time through blktrans_open(), the device is erroneously considered already open on the second time through. This problem can be seen, for instance, when a UBI volume is simultaneously mounted as a UBIFS partition and read through its corresponding gluebi mtdblockX device. This results in blktrans_open() passing its error checks (with `dev->open > 0') without actually having a handle on the device. Here's a summarized log of the actions and results with nandsim: # modprobe nandsim # modprobe mtdblock # modprobe gluebi # modprobe ubifs # ubiattach /dev/ubi_ctrl -m 0 ... # ubimkvol /dev/ubi0 -N test -s 16MiB ... # mount -t ubifs ubi0:test /mnt # ls /dev/mtdblock* /dev/mtdblock0 /dev/mtdblock1 # cat /dev/mtdblock1 > /dev/null cat: can't open '/dev/mtdblock4': Device or resource busy # cat /dev/mtdblock1 > /dev/null CPU 0 Unable to handle kernel paging request at virtual address fffffff0, epc == 8031536c, ra == 8031f280 Oops[#1]: ... Call Trace: [<8031536c>] ubi_leb_read+0x14/0x164 [<8031f280>] gluebi_read+0xf0/0x148 [<802edba8>] mtdblock_readsect+0x64/0x198 [<802ecfe4>] mtd_blktrans_thread+0x330/0x3f4 [<8005be98>] kthread+0x88/0x90 [<8000bc04>] kernel_thread_helper+0x10/0x18 Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit fc3bd1ff1d248c3ab9a2c57c285b86bd17dd2176 Author: Roman Tereshonkov Date: Fri Dec 2 15:07:17 2011 +0200 mtd: mtdoops: skip reading initially bad blocks commit 3538c56329936c78f7d356889908790006d0124c upstream. Use block_isbad to check and skip the bad blocks reading. This will allow to get rid of the read errors if bad blocks are present initially. Signed-off-by: Roman Tereshonkov Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit bf77ff6f9796c5664cf63f191da99358198a8e67 Author: Roman Tereshonkov Date: Tue Nov 29 12:49:18 2011 +0200 mtdoops: fix the oops_page_used array size commit 556f063580db2953a7e53cd46b47724246320f60 upstream. The array of unsigned long pointed by oops_page_used is allocated by vmalloc which requires the size to be in bytes. BITS_PER_LONG is equal to 32. If we want to allocate memory for 32 pages with one bit per page then 32 / BITS_PER_LONG is equal to 1 byte that is 8 bits. To fix it we need to multiply the result by sizeof(unsigned long) equal to 4. Signed-off-by: Roman Tereshonkov Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman