commit d61ed4631511b08d2e14924eab16a9ddaed44df6 Author: Greg Kroah-Hartman Date: Fri Sep 14 15:28:08 2012 -0700 Linux 3.5.4 commit 93215341fec52a050b0ccd192e3dbe6eea3c4fd2 Author: Luca Tettamanti Date: Tue Aug 21 17:36:28 2012 +0200 hwmon: (asus_atk0110) Add quirk for Asus M5A78L commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream. The old interface is bugged and reads the wrong sensor when retrieving the reading for the chassis fan (it reads the CPU sensor); the new interface works fine. Reported-by: Göran Uddeborg Tested-by: Göran Uddeborg Signed-off-by: Luca Tettamanti Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 05c85df9bfefd3e1da30a2f44e82618e6e880ef0 Author: Mathias Krause Date: Wed Aug 15 11:31:54 2012 +0000 dccp: check ccid before dereferencing commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream. ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with a NULL ccid pointer leading to a NULL pointer dereference. This could lead to a privilege escalation if the attacker is able to map page 0 and prepare it with a fake ccid_ops pointer. Signed-off-by: Mathias Krause Cc: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3a392aa579df87e3be160947758428681fbe2611 Author: Andreas Herrmann Date: Tue Jul 31 15:41:45 2012 +0200 x86, microcode, AMD: Fix broken ucode patch size check commit 36bf50d7697be18c6bfd0401e037df10bff1e573 upstream. This issue was recently observed on an AMD C-50 CPU where a patch of maximum size was applied. Commit be62adb49294 ("x86, microcode, AMD: Simplify ucode verification") added current_size in get_matching_microcode(). This is calculated as size of the ucode patch + 8 (ie. size of the header). Later this is compared against the maximum possible ucode patch size for a CPU family. And of course this fails if the patch has already maximum size. Signed-off-by: Andreas Herrmann Signed-off-by: Borislav Petkov Link: http://lkml.kernel.org/r/1344361461-10076-1-git-send-email-bp@amd64.org Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit a1ee34a43130fd31d7d0990695115a8e099b5ae6 Author: Oleg Nesterov Date: Sun Aug 19 19:10:42 2012 +0200 uprobes: Fix mmap_region()'s mm->mm_rb corruption if uprobe_mmap() fails commit c7a3a88c938fbe3d70c2278e082b80eb830d1c58 upstream. This patch fixes: https://bugzilla.redhat.com/show_bug.cgi?id=843640 If mmap_region()->uprobe_mmap() fails, unmap_and_free_vma path does unmap_region() but does not remove the soon-to-be-freed vma from rb tree. Actually there are more problems but this is how William noticed this bug. Perhaps we could do do_munmap() + return in this case, but in fact it is simply wrong to abort if uprobe_mmap() fails. Until at least we move the !UPROBE_COPY_INSN code from install_breakpoint() to uprobe_register(). For example, uprobe_mmap()->install_breakpoint() can fail if the probed insn is not supported (remember, uprobe_register() succeeds if nobody mmaps inode/offset), mmap() should not fail in this case. dup_mmap()->uprobe_mmap() is wrong too by the same reason, fork() can race with uprobe_register() and fail for no reason if it wins the race and does install_breakpoint() first. And, if nothing else, both mmap_region() and dup_mmap() return success if uprobe_mmap() fails. Change them to ignore the error code from uprobe_mmap(). Reported-and-tested-by: William Cohen Signed-off-by: Oleg Nesterov Acked-by: Srikar Dronamraju Cc: Anton Arapov Cc: William Cohen Cc: Linus Torvalds Link: http://lkml.kernel.org/r/20120819171042.GB26957@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2c43fd7058e779eeef7e3dad3a5a8066162cabac Author: Konrad Rzeszutek Wilk Date: Wed Sep 5 16:35:20 2012 -0400 xen/pciback: Fix proper FLR steps. commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a upstream. When we do FLR and save PCI config we did it in the wrong order. The end result was that if a PCI device was unbind from its driver, then binded to xen-pciback, and then back to its driver we would get: > lspci -s 04:00.0 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 13:42:12 # 4 :~/ > echo "0000:04:00.0" > /sys/bus/pci/drivers/pciback/unbind > modprobe e1000e e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k e1000e: Copyright(c) 1999 - 2012 Intel Corporation. e1000e 0000:04:00.0: Disabling ASPM L0s L1 e1000e 0000:04:00.0: enabling device (0000 -> 0002) xen: registering gsi 48 triggering 0 polarity 1 Already setup the GSI :48 e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode e1000e: probe of 0000:04:00.0 failed with error -2 This fixes it by first saving the PCI configuration space, then doing the FLR. Reported-by: Ren, Yongjie Reported-and-Tested-by: Tobias Geiger Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 5f975bbb5b5c134b0bc75c51b6931368b2c4dbbb Author: Konrad Rzeszutek Wilk Date: Tue Sep 4 15:45:17 2012 -0400 xen/p2m: Fix one-off error in checking the P2M tree directory. commit 50e900417b8096939d12a46848f965e27a905e36 upstream. We would traverse the full P2M top directory (from 0->MAX_DOMAIN_PAGES inclusive) when trying to figure out whether we can re-use some of the P2M middle leafs. Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512 we would try to use the 512th entry. Fortunately for us the p2m_top_index has a check for this: BUG_ON(pfn >= MAX_P2M_PFN); which we hit and saw this: (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-4.1.2-OVM x86_64 debug=n Tainted: C ]---- (XEN) CPU: 0 (XEN) RIP: e033:[] (XEN) RFLAGS: 0000000000000212 EM: 1 CONTEXT: pv guest (XEN) rax: ffffffff81db5000 rbx: ffffffff81db4000 rcx: 0000000000000000 (XEN) rdx: 0000000000480211 rsi: 0000000000000000 rdi: ffffffff81db4000 (XEN) rbp: ffffffff81793db8 rsp: ffffffff81793d38 r8: 0000000008000000 (XEN) r9: 4000000000000000 r10: 0000000000000000 r11: ffffffff81db7000 (XEN) r12: 0000000000000ff8 r13: ffffffff81df1ff8 r14: ffffffff81db6000 (XEN) r15: 0000000000000ff8 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 0000000661795000 cr2: 0000000000000000 Fixes-Oracle-Bug: 14570662 Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit e47ba09bac3c8f08dbf4fba89bf73c808aff13e2 Author: Ronny Hegewald Date: Fri Aug 31 09:57:52 2012 +0000 xen: Use correct masking in xen_swiotlb_alloc_coherent. commit b5031ed1be0aa419250557123633453753181643 upstream. When running 32-bit pvops-dom0 and a driver tries to allocate a coherent DMA-memory the xen swiotlb-implementation returned memory beyond 4GB. The underlaying reason is that if the supplied driver passes in a DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff) our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits. By using the dma_alloc_coherent_mask function - it does the proper casting and we get 0xfffffffff. This caused not working sound on a system with 4 GB and a 64-bit compatible sound-card with sets the DMA-mask to 64bit. On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent DMA-memory is always allocated inside the 32-bit address-range by calling dma_alloc_coherent_mask. This patch adds the same functionality to xen swiotlb and is a rebase of the original patch from Ronny Hegewald which never got upstream b/c the underlaying reason was not understood until now. The original email with the original patch is in: http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html the original thread from where the discussion started is in: http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html Signed-off-by: Ronny Hegewald Signed-off-by: Stefano Panella Acked-By: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit be66687a2e6eeb6d2b369eb2fb7406ca00610829 Author: Mel Gorman Date: Mon Jul 23 12:16:19 2012 +0100 PARISC: Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream. The following build error occured during a parisc build with swap-over-NFS patches applied. net/core/sock.c:274:36: error: initializer element is not constant net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks') net/core/sock.c:274:36: error: initializer element is not constant Dave Anglin says: > Here is the line in sock.i: > > struct static_key memalloc_socks = ((struct static_key) { .enabled = > ((atomic_t) { (0) }) }); The above line contains two compound literals. It also uses a designated initializer to initialize the field enabled. A compound literal is not a constant expression. The location of the above statement isn't fully clear, but if a compound literal occurs outside the body of a function, the initializer list must consist of constant expressions. Reported-by: Fengguang Wu Signed-off-by: Mel Gorman Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit d59b54490e65baaa251021f1956cd43280a956ef Author: Bruce Allan Date: Fri Aug 24 20:38:11 2012 +0000 e1000e: DoS while TSO enabled caused by link partner with small MSS commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream. With a low enough MSS on the link partner and TSO enabled locally, the networking stack can periodically send a very large (e.g. 64KB) TCP message for which the driver will attempt to use more Tx descriptors than are available by default in the Tx ring. This is due to a workaround in the code that imposes a limit of only 4 MSS-sized segments per descriptor which appears to be a carry-over from the older e1000 driver and may be applicable only to some older PCI or PCIx parts which are not supported in e1000e. When the driver gets a message that is too large to fit across the configured number of Tx descriptors, it stops the upper stack from queueing any more and gets stuck in this state. After a timeout, the upper stack assumes the adapter is hung and calls the driver to reset it. Remove the unnecessary limitation of using up to only 4 MSS-sized segments per Tx descriptor, and put in a hard failure test to catch when attempting to check for message sizes larger than would fit in the whole Tx ring. Refactor the remaining logic that limits the size of data per Tx descriptor from a seemingly arbitrary 8KB to a limit based on the dynamic size of the Tx packet buffer as described in the hardware specification. Also, fix the logic in the check for space in the Tx ring for the next largest possible packet after the current one has been successfully queued for transmit, and use the appropriate defines for default ring sizes in e1000_probe instead of magic values. This issue goes back to the introduction of e1000e in 2.6.24 when it was split off from e1000. Reported-by: Ben Hutchings Signed-off-by: Bruce Allan Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 819b337cd90c18a07b2897c7b9747acd42bab839 Author: Grazvydas Ignotas Date: Tue Aug 21 09:09:48 2012 +0300 OMAPFB: fix framebuffer console colors commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream. omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. Signed-off-by: Grazvydas Ignotas Signed-off-by: Tomi Valkeinen Signed-off-by: Florian Tobias Schandinat Signed-off-by: Greg Kroah-Hartman commit 28abd527db92eeac90637c6255567ba2ec34f33b Author: Dave Airlie Date: Tue Aug 28 21:40:51 2012 -0400 drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream. This will cause udev to load vmwgfx instead of waiting for X to do it. Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 94ff8b10c8047e49318eb4ed3beeffbbff869285 Author: Artem Bityutskiy Date: Mon Sep 3 17:12:29 2012 +0300 UBI: fix a horrible memory deallocation bug commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream. UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened only when we were doing auto-format, so many systems were unaffected. However, there are still many users affected. It is strange, but the system did not crash and nothing bad happened when the SLUB memory allocator was used. However, in case of SLOB we observed an crash right away. This problem was introduced in 2.6.39 by commit "6c1e875 UBI: add slab cache for ubi_scan_leb objects" A note for stable trees: Because variable were renamed, this won't cleanly apply to older kernels. Changing names like this should help: 1. ai -> si 2. aeb_slab_cache -> seb_slab_cache 3. new_aeb -> new_seb Reported-by: Richard Genoud Tested-by: Richard Genoud Tested-by: Artem Bityutskiy Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 996ab492443658e15b0a6b912ed703411e005475 Author: Dmitry Torokhov Date: Tue Aug 21 21:57:15 2012 -0700 Input: i8042 - add Gigabyte T1005 series netbooks to noloop table commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream. They all define their chassis type as "Other" and therefore are not categorized as "laptops" by the driver, which tries to perform AUX IRQ delivery test which fails and causes touchpad not working. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620 Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 219cf47cec80faa3b1dd3513adde6f70a58e34db Author: Alan Stern Date: Thu Aug 23 10:51:55 2012 -0400 HID: add NOGET quirk for Eaton Ellipse MAX UPS commit 67ddbb3e6568fb1820b2cc45b00c50702b114801 upstream. This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS device. (The USB IDs were already present in hid-ids.h, apparently under a different name.) Signed-off-by: Alan Stern Reported-by: Laurent Bigonville Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit cdc854ed9062170e7ff485aafc4f1b0cfe1fd127 Author: James Ralston Date: Mon Sep 10 10:14:02 2012 +0200 i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH commit 4a8f1ddde942e232387e6129ce4f4c412e43802f upstream. Add the SMBus Device IDs for the Intel Lynx Point-LP PCH. Signed-off-by: James Ralston Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 7ee545c7e373c4fc9e60b2a74b70a2e70c9f114d Author: Axel Lin Date: Mon Sep 10 10:14:02 2012 +0200 i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y commit e68bb91baa0bb9817567bd45d560919e8e26373b upstream. This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE. Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as built-in or module, we also need to export the functions in i2c-designware-core. This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y: LD drivers/i2c/busses/built-in.o drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int': i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init': i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl': i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr': i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer': i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled': i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel': i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg': i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable': i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param': i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable': i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func': i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int': i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here make[3]: *** [drivers/i2c/busses/built-in.o] Error 1 make[2]: *** [drivers/i2c/busses] Error 2 make[1]: *** [drivers/i2c] Error 2 make: *** [drivers] Error 2 Signed-off-by: Axel Lin Signed-off-by: Jean Delvare Tested-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit fff3ab0c3b3f04fdb2f97dcb97372de1d589f341 Author: Miklos Szeredi Date: Tue Sep 4 18:45:54 2012 +0200 fuse: fix retrieve length commit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream. In some cases fuse_retrieve() would return a short byte count if offset was non-zero. The data returned was correct, though. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 0847e6cbb0b902f1247f35f4b87090546508d14a Author: Jan Kara Date: Mon Sep 3 16:50:42 2012 +0200 ext3: Fix fdatasync() for files with only i_size changes commit 156bddd8e505b295540f3ca0e27dda68cb0d49aa upstream. Code tracking when transaction needs to be committed on fdatasync(2) forgets to handle a situation when only inode's i_size is changed. Thus in such situations fdatasync(2) doesn't force transaction with new i_size to disk and that can result in wrong i_size after a crash. Fix the issue by updating inode's i_datasync_tid whenever its size is updated. Reported-by: Kristian Nielsen Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 7eaba93134d4e222e31aa179ed437a6e4938ea6f Author: Jan Kara Date: Wed Sep 5 15:48:23 2012 +0200 udf: Fix data corruption for files in ICB commit 9c2fc0de1a6e638fe58c354a463f544f42a90a09 upstream. When a file is stored in ICB (inode), we overwrite part of the file, and the page containing file's data is not in page cache, we end up corrupting file's data by overwriting them with zeros. The problem is we use simple_write_begin() which simply zeroes parts of the page which are not written to. The problem has been introduced by be021ee4 (udf: convert to new aops). Fix the problem by providing a ->write_begin function which makes the page properly uptodate. Reported-by: Ian Abbott Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ee6928d63e37e1b1e7eca898c5b2bac19f194ebd Author: James Bottomley Date: Wed Jul 25 23:55:55 2012 +0400 SCSI: Fix 'Device not ready' issue on mpt2sas commit 14216561e164671ce147458653b1fea06a4ada1e upstream. This is a particularly nasty SCSI ATA Translation Layer (SATL) problem. SAT-2 says (section 8.12.2) if the device is in the stopped state as the result of processing a START STOP UNIT command (see 9.11), then the SATL shall terminate the TEST UNIT READY command with CHECK CONDITION status with the sense key set to NOT READY and the additional sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND REQUIRED; mpt2sas internal SATL seems to implement this. The result is very confusing standby behaviour (using hdparm -y). If you suspend a drive and then send another command, usually it wakes up. However, if the next command is a TEST UNIT READY, the SATL sees that the drive is suspended and proceeds to follow the SATL rules for this, returning NOT READY to all subsequent commands. This means that the ordering of TEST UNIT READY is crucial: if you send TUR and then a command, you get a NOT READY to both back. If you send a command and then a TUR, you get GOOD status because the preceeding command woke the drive. This bit us badly because commit 85ef06d1d252f6a2e73b678591ab71caad4667bb Author: Tejun Heo Date: Fri Jul 1 16:17:47 2011 +0200 block: flush MEDIA_CHANGE from drivers on close(2) Changed our ordering on TEST UNIT READY commands meaning that SATA drives connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas SATL sees the suspend *before* the drives get awoken by the next ATA command) resulting in lots of failed commands. The standard is completely nuts forcing this inconsistent behaviour, but we have to work around it. The fix for this is twofold: 1. Set the allow_restart flag so we wake the drive when we see it has been suspended 2. Return all TEST UNIT READY status directly to the mid layer without any further error handling which prevents us causing error handling which may offline the device just because of a media check TUR. Reported-by: Matthias Prager Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b18244bc241bb733ec53f98ffd9b3aa099997717 Author: sreekanth.reddy@lsi.com Date: Tue Jul 17 15:57:05 2012 +0530 SCSI: mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line option to a very small value commit 338b131a3269881c7431234855c93c219b0979b6 upstream. If the specified max_queue_depth setting is less than the expected number of internal commands, then driver will calculate the queue depth size to a negitive number. This negitive number is actually a very large number because variable is unsigned 16bit integer. So, the driver will ask for a very large amount of memory for message frames and resulting into oops as memory allocation routines will not able to handle such a large request. So, in order to limit this kind of oops, The driver need to set the max_queue_depth to a scsi mid layer's can_queue value. Then the overall message frames required for IO is minimum of either (max_queue_depth plus internal commands) or the IOC global credits. Signed-off-by: Sreekanth Reddy Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a0643ec768bbe63e0004228b550a96f5ef932867 Author: Mike Snitzer Date: Thu May 31 15:05:33 2012 -0400 SCSI: scsi_lib: fix scsi_io_completion's SG_IO error propagation commit 27c419739b67decced4650440829b8d51bef954b upstream. The following v3.4-rc1 commit unmasked an existing bug in scsi_io_completion's SG_IO error handling: 47ac56d [SCSI] scsi_error: classify some ILLEGAL_REQUEST sense as a permanent TARGET_ERROR Given that certain ILLEGAL_REQUEST are now properly categorized as TARGET_ERROR the host_byte is being set (before host_byte wasn't ever set for these ILLEGAL_REQUEST). In scsi_io_completion, initialize req->errors with cmd->result _after_ the SG_IO block that calls __scsi_error_from_host_byte (which may modify the host_byte). Before this fix: cdb to send: 12 01 01 00 00 00 ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[12, 01, 01, 00, 00, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=20000, flags=0, status=02, masked_status=01, sb[19]=[70, 00, 05, 00, 00, 00, 00, 0b, 00, 00, 00, 00, 24, 00, 00, 00, 00, 00, 00], host_status=0x10, driver_status=0x8, resid=0, duration=0, info=0x1}) = 0 SCSI Status: Check Condition Sense Information: sense buffer empty After: cdb to send: 12 01 01 00 00 00 ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[12, 01, 01, 00, 00, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=20000, flags=0, status=02, masked_status=01, sb[19]=[70, 00, 05, 00, 00, 00, 00, 0b, 00, 00, 00, 00, 24, 00, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, resid=0, duration=0, info=0x1}) = 0 SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Invalid field in cdb Raw sense data (in hex): 70 00 05 00 00 00 00 0b 00 00 00 00 24 00 00 00 00 00 00 Reported-by: Paolo Bonzini Tested-by: Paolo Bonzini Signed-off-by: Mike Snitzer Reviewed-by: Babu Moger Signed-off-by: Greg Kroah-Hartman Signed-off-by: James Bottomley commit 63cca8246b437f58d19413b760558fe6f0544e18 Author: Kashyap Desai Date: Tue Jul 17 18:20:44 2012 -0700 SCSI: megaraid_sas: Move poll_aen_lock initializer commit bd8d6dd43a77bfd2b8fef5b094b9d6095e169dee upstream. The following patch moves the poll_aen_lock initializer from megasas_probe_one() to megasas_init(). This prevents a crash when a user loads the driver and tries to issue a poll() system call on the ioctl interface with no adapters present. Signed-off-by: Kashyap Desai Signed-off-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 1db3396a544814978c561fa28268eded9cb41542 Author: Oliver Neukum Date: Sun Aug 26 20:41:38 2012 +0000 usbnet: fix deadlock in resume commit ab6f148de28261682d300662e87b9477f7efc95b upstream. A usbnet device can share a multifunction device with a storage device. If the storage device is autoresumed the usbnet devices also needs to be autoresumed. Allocating memory with GFP_KERNEL can deadlock in this case. This should go back into all kernels that have commit 65841fd5132c3941cdf5df09e70df3ed28323212 That is 3.5 Signed-off-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d6534b3afbbb228c0eed4fa4a6d00a3490a5da52 Author: Mikulas Patocka Date: Sat Sep 1 12:34:07 2012 -0400 Fix order of arguments to compat_put_time[spec|val] commit ed6fe9d614fc1bca95eb8c0ccd0e92db00ef9d5d upstream. Commit 644595f89620 ("compat: Handle COMPAT_USE_64BIT_TIME in net/socket.c") introduced a bug where the helper functions to take either a 64-bit or compat time[spec|val] got the arguments in the wrong order, passing the kernel stack pointer off as a user pointer (and vice versa). Because of the user address range check, that in turn then causes an EFAULT due to the user pointer range checking failing for the kernel address. Incorrectly resuling in a failed system call for 32-bit processes with a 64-bit kernel. On odder architectures like HP-PA (with separate user/kernel address spaces), it can be used read kernel memory. Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e127c5bc34de722b0f7671cdf874365d66e5735e Author: Dave Jones Date: Thu Sep 6 12:01:00 2012 -0400 Remove user-triggerable BUG from mpol_to_str commit 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a upstream. Trivially triggerable, found by trinity: kernel BUG at mm/mempolicy.c:2546! Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670) Call Trace: show_numa_map+0xd5/0x450 show_pid_numa_map+0x13/0x20 traverse+0xf2/0x230 seq_read+0x34b/0x3e0 vfs_read+0xac/0x180 sys_pread64+0xa2/0xc0 system_call_fastpath+0x1a/0x1f RIP: mpol_to_str+0x156/0x360 Signed-off-by: Dave Jones Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f8e61a1b13a0bbe1aca40b3e4d5352d1cc9f8963 Author: Paul Mackerras Date: Tue Sep 4 18:33:08 2012 +0000 powerpc: Make sure IPI handlers see data written by IPI senders commit 9fb1b36ca1234e64a5d1cc573175303395e3354d upstream. We have been observing hangs, both of KVM guest vcpu tasks and more generally, where a process that is woken doesn't properly wake up and continue to run, but instead sticks in TASK_WAKING state. This happens because the update of rq->wake_list in ttwu_queue_remote() is not ordered with the update of ipi_message in smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in scheduler_ipi() is not ordered with the reading of ipi_message in smp_ipi_demux(). Thus it is possible for the IPI receiver not to see the updated rq->wake_list and therefore conclude that there is nothing for it to do. In order to make sure that anything done before smp_send_reschedule() is ordered before anything done in the resulting call to scheduler_ipi(), this adds barriers in smp_muxed_message_pass() and smp_ipi_demux(). The barrier in smp_muxed_message_pass() is a full barrier to ensure that there is a full ordering between the smp_send_reschedule() caller and scheduler_ipi(). In smp_ipi_demux(), we use xchg() rather than xchg_local() because xchg() includes release and acquire barriers. Using xchg() rather than xchg_local() makes sense given that ipi_message is not just accessed locally. This moves the barrier between setting the message and calling the cause_ipi() function into the individual cause_ipi implementations. Most of them -- those that used outb, out_8 or similar -- already had a full barrier because out_8 etc. include a sync before the MMIO store. This adds an explicit barrier in the two remaining cases. These changes made no measurable difference to the speed of IPIs as measured using a simple ping-pong latency test across two CPUs on different cores of a POWER7 machine. The analysis of the reason why processes were not waking up properly is due to Milton Miller. Reported-by: Milton Miller Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 6f8f10d863f24baa5b5920c24d54d99ae4cc68ee Author: Anton Blanchard Date: Mon Sep 3 16:51:10 2012 +0000 powerpc: Restore correct DSCR in context switch commit 714332858bfd40dcf8f741498336d93875c23aa7 upstream. During a context switch we always restore the per thread DSCR value. If we aren't doing explicit DSCR management (ie thread.dscr_inherit == 0) and the default DSCR changed while the process has been sleeping we end up with the wrong value. Check thread.dscr_inherit and select the default DSCR or per thread DSCR as required. This was found with the following test case, when running with more threads than CPUs (ie forcing context switching): http://ozlabs.org/~anton/junkcode/dscr_default_test.c With the four patches applied I can run a combination of all test cases successfully at the same time: http://ozlabs.org/~anton/junkcode/dscr_default_test.c http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b5bcfe7b31771a620dfb4b939ae36ae06bf8d7b7 Author: Anton Blanchard Date: Mon Sep 3 16:49:47 2012 +0000 powerpc: Fix DSCR inheritance in copy_thread() commit 1021cb268b3025573c4811f1dee4a11260c4507b upstream. If the default DSCR is non zero we set thread.dscr_inherit in copy_thread() meaning the new thread and all its children will ignore future updates to the default DSCR. This is not intended and is a change in behaviour that a number of our users have hit. We just need to inherit thread.dscr and thread.dscr_inherit from the parent which ends up being much simpler. This was found with the following test case: http://ozlabs.org/~anton/junkcode/dscr_default_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 29f88ecaa2fea17a93e61a576d75ce51a5f03a92 Author: Anton Blanchard Date: Mon Sep 3 16:48:46 2012 +0000 powerpc: Keep thread.dscr and thread.dscr_inherit in sync commit 00ca0de02f80924dfff6b4f630e1dff3db005e35 upstream. When we update the DSCR either via emulation of mtspr(DSCR) or via a change to dscr_default in sysfs we don't update thread.dscr. We will eventually update it at context switch time but there is a period where thread.dscr is incorrect. If we fork at this point we will copy the old value of thread.dscr into the child. To avoid this, always keep thread.dscr in sync with reality. This issue was found with the following testcase: http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d3247578b5ac98900774b9658eea3f2833af93b0 Author: Anton Blanchard Date: Mon Sep 3 16:47:56 2012 +0000 powerpc: Update DSCR on all CPUs when writing sysfs dscr_default commit 1b6ca2a6fe56e7697d57348646e07df08f43b1bb upstream. Writing to dscr_default in sysfs doesn't actually change the DSCR - we rely on a context switch on each CPU to do the work. There is no guarantee we will get a context switch in a reasonable amount of time so fire off an IPI to force an immediate change. This issue was found with the following test case: http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 632b4daff0c87e2a36be7b3c925e90dfc255b648 Author: Daniel Mack Date: Thu Aug 30 18:52:31 2012 +0200 ALSA: snd-usb: fix cross-interface streaming devices commit 2e4a263ca80a203ac6109f5932722a716c265395 upstream. Commit 68e67f40b ("ALSA: snd-usb: move calls to usb_set_interface") saved us some unnecessary calls to snd_usb_set_interface() but ignored the fact that there is at least one device out there which operates on two endpoint in different interfaces simultaniously. Take care for this by catching the case where data and sync endpoints are located on different interfaces and calling snd_usb_set_interface() between the start of the two endpoints. Signed-off-by: Daniel Mack Reported-by: Robert M. Albrecht Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ca150f7ade5973c3bce19261bca6174d5c3cc342 Author: Daniel Mack Date: Thu Aug 30 18:52:30 2012 +0200 ALSA: snd-usb: fix calls to next_packet_size commit 245baf983cc39524cce39c24d01b276e6e653c9e upstream. In order to support devices with implicit feedback streaming models, packet sizes are now stored with each individual urb, and the PCM handling code which fills the buffers purely relies on the size fields now. However, calling snd_usb_audio_next_packet_size() for all possible packets in an URB at once, prior to letting the PCM code do its job does in fact not lead to the same behaviour than what the old code did: The PCM code will break its loop once a period boundary is reached, consequently using up less packets that it really could. As snd_usb_audio_next_packet_size() implements a feedback mechanism to the endpoints phase accumulator, the number of calls to that function matters, and when called too often, the data rate runs out of bounds. Fix this by making the next_packet function public, and call it from the PCM code as before if the packet data sizes are not defined. Signed-off-by: Daniel Mack Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b28af07e805bd1fc994628a78866c4ff18f7bc97 Author: Daniel Mack Date: Thu Aug 30 18:52:29 2012 +0200 ALSA: snd-usb: restore delay information commit fbcfbf5f673847657ccd98afb4d8e13af7fdc372 upstream. Parts of commit 294c4fb8 ("ALSA: usb: refine delay information with USB frame counter") were unfortunately lost during the refactoring of the snd-usb driver in 3.5. This patch adds them back, restoring the correct delay information behaviour. Signed-off-by: Daniel Mack Cc: Pierre-Louis Bossart Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cf43b1131768b8e9bf1466e569d6a16864c3ccf0 Author: Pavel Roskin Date: Thu Aug 30 17:11:17 2012 -0400 ALSA: snd-usb: use list_for_each_safe for endpoint resources commit 03d2f44e967b3c2cf79a6dfb904c8880616c7f83 upstream. snd_usb_endpoint_free() frees the structure that contains its argument. Signed-off-by: Pavel Roskin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 943a54f28e20d7938ecef3545299745ef7cbb9a6 Author: Daniel Mack Date: Wed Aug 29 13:17:05 2012 +0200 ALSA: snd-usb: Fix URB cancellation at stream start commit 015618b902ae8e28705b7af9b4668615fea48ddd upstream. Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream") fixed a scheduling-while-atomic bug that happened when snd_usb_endpoint_start was called from the trigger callback, which is an atmic context. However, the patch breaks the idea of the endpoints reference counting, which is the reason why the driver has been refactored lately. Revert that commit and let snd_usb_endpoint_start() take care of the URB cancellation again. As this function is called from both atomic and non-atomic context, add a flag to denote whether the function may sleep. Signed-off-by: Daniel Mack Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 36c59fb1d579f7cc4103d881ecbf7acc2440c7be Author: Sven Schnelle Date: Fri Aug 17 21:43:43 2012 +0200 USB: CDC ACM: Fix NULL pointer dereference commit 99f347caa4568cb803862730b3b1f1942639523f upstream. If a device specifies zero endpoints in its interface descriptor, the kernel oopses in acm_probe(). Even though that's clearly an invalid descriptor, we should test wether we have all endpoints. This is especially bad as this oops can be triggered by just plugging a USB device in. Signed-off-by: Sven Schnelle Signed-off-by: Greg Kroah-Hartman commit e1f063c63824617319d4c707cd0cc3d72b7895ee Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:26 2012 -0700 USB: smsusb: remove __devinit* from the struct usb_device_id table commit d04dbd1c0ec17a13326c8f2279399c225836a79f upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Mauro Carvalho Chehab CC: Michael Krufky CC: Paul Gortmaker CC: Doron Cohen Signed-off-by: Greg Kroah-Hartman commit 190ef2854b370f706de846e780ec9a2212cab009 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:29 2012 -0700 USB: rtl8187: remove __devinit* from the struct usb_device_id table commit a3433179d0822ccfa8e80aa4d1d52843bd2dcc63 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Herton Ronaldo Krzesinski CC: Hin-Tak Leung CC: Larry Finger CC: "John W. Linville" Signed-off-by: Greg Kroah-Hartman commit af1c23c337af61cf6aa3627ae16346edfebd218b Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:28 2012 -0700 USB: p54usb: remove __devinit* from the struct usb_device_id table commit b9c4167cbbafddac3462134013bc15e63e4c53ef upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Christian Lamparter CC: "John W. Linville" Signed-off-by: Greg Kroah-Hartman commit 20eedb4a2b900cc7591c39dda5d2d9a64d923778 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:27 2012 -0700 USB: jl2005bcd: remove __devinit* from the struct usb_device_id table commit ec063351684298e295dc9444d143ddfd6ab02df8 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Hans de Goede CC: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5373de19951149ba38ce32fdf33f0532ba2f27d5 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:27 2012 -0700 USB: spca506: remove __devinit* from the struct usb_device_id table commit e694d518886c7afedcdd1732477832b2e32744e4 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Hans de Goede CC: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b93aa0304cef694f00821102b3424973583a1a4d Author: Mike Frysinger Date: Sat Aug 18 16:11:37 2012 -0400 x32: Use compat shims for {g,s}etsockopt commit 515c7af85ed92696c311c53d53cb4898ff32d784 upstream. Some of the arguments to {g,s}etsockopt are passed in userland pointers. If we try to use the 64bit entry point, we end up sometimes failing. For example, dhcpcd doesn't run in x32: # dhcpcd eth0 dhcpcd[1979]: version 5.5.6 starting dhcpcd[1979]: eth0: broadcasting for a lease dhcpcd[1979]: eth0: open_socket: Invalid argument dhcpcd[1979]: eth0: send_raw_packet: Bad file descriptor The code in particular is getting back EINVAL when doing: struct sock_fprog pf; setsockopt(s, SOL_SOCKET, SO_ATTACH_FILTER, &pf, sizeof(pf)); Diving into the kernel code, we can see: include/linux/filter.h: struct sock_fprog { unsigned short len; struct sock_filter __user *filter; }; net/core/sock.c: case SO_ATTACH_FILTER: ret = -EINVAL; if (optlen == sizeof(struct sock_fprog)) { struct sock_fprog fprog; ret = -EFAULT; if (copy_from_user(&fprog, optval, sizeof(fprog))) break; ret = sk_attach_filter(&fprog, sk); } break; arch/x86/syscalls/syscall_64.tbl: 54 common setsockopt sys_setsockopt 55 common getsockopt sys_getsockopt So for x64, sizeof(sock_fprog) is 16 bytes. For x86/x32, it's 8 bytes. This comes down to the pointer being 32bit for x32, which means we need to do structure size translation. But since x32 comes in directly to sys_setsockopt, it doesn't get translated like x86. After changing the syscall table and rebuilding glibc with the new kernel headers, dhcp runs fine in an x32 userland. Oddly, it seems like Linus noted the same thing during the initial port, but I guess that was missed/lost along the way: https://lkml.org/lkml/2011/8/26/452 [ hpa: tagging for -stable since this is an ABI fix. ] Bugzilla: https://bugs.gentoo.org/423649 Reported-by: Mads Signed-off-by: Mike Frysinger Link: http://lkml.kernel.org/r/1345320697-15713-1-git-send-email-vapier@gentoo.org Cc: H. J. Lu Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit cc1b17501bdcc11786dc6a2ef98bba86069f9ffe Author: Aaro Koskinen Date: Wed Aug 15 01:10:04 2012 +0300 regulator: twl-regulator: fix up VINTANA1/VINTANA2 commit 908d6d52928a7f2a4b317aac47542c5fbef43d88 upstream. It seems commit 2098e95ce9bb039ff2e7bf836df358d18a176139 (regulator: twl: adapt twl-regulator driver to dt) accidentally deleted VINTANA1. Also the same commit defines VINTANA2 twice with TWL4030_ADJUSTABLE_LDO and TWL4030_FIXED_LDO. This patch changes the fixed one to be VINTANA1. I noticed this when auditing my N900 boot logs. I could not notice any change in device behaviour, though, except that the boot logs are now like before: ... [ 0.282928] VDAC: 1800 mV normal standby [ 0.284027] VCSI: 1800 mV normal standby [ 0.285400] VINTANA1: 1500 mV normal standby [ 0.286865] VINTANA2: 2750 mV normal standby [ 0.288208] VINTDIG: 1500 mV normal standby [ 0.289978] VSDI_CSI: 1800 mV normal standby ... Signed-off-by: Aaro Koskinen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b69d73f4adbe6451bb73a3799d4d75079e14d6b1 Author: Alexandre Bounine Date: Tue Aug 21 16:16:12 2012 -0700 rapidio/tsi721: fix unused variable compiler warning commit 9a9a9a7adafe62a34de8b4fb48936c1c5f9bafa5 upstream. Fix unused variable compiler warning when built with CONFIG_RAPIDIO_DEBUG option off. This patch is applicable to kernel versions starting from v3.2 Signed-off-by: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ef7aecdaa74c121d2eba154e834a5a238269b3f0 Author: Alexandre Bounine Date: Tue Aug 21 16:16:11 2012 -0700 rapidio/tsi721: fix inbound doorbell interrupt handling commit 3670e7e12e582c6d67761275d148171feb7a9004 upstream. Make sure that there is no doorbell messages left behind due to disabled interrupts during inbound doorbell processing. The most common case for this bug is loss of rionet JOIN messages in systems with three or more rionet participants and MSI or MSI-X enabled. As result, requests for packet transfers may finish with "destination unreachable" error message. This patch is applicable to kernel versions starting from v3.2. Signed-off-by: Alexandre Bounine Cc: Matt Porter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0c45345d5b34a4c1daa75ca31aa2975820cdf856 Author: Jayakrishnan Memana Date: Sun Jul 15 10:54:03 2012 -0300 uvcvideo: Reset the bytesused field when recycling an erroneous buffer commit 8a3f0ede2b3f5477122060af1a816c6bbf09fcd2 upstream. Buffers marked as erroneous are recycled immediately by the driver if the nodrop module parameter isn't set. The buffer payload size is reset to 0, but the buffer bytesused field isn't. This results in the buffer being immediately considered as complete, leading to an infinite loop in interrupt context. Fix the problem by resetting the bytesused field when recycling the buffer. Signed-off-by: Jayakrishnan Memana Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b768c3cb600363139c57dd4448c8c1f45b6b0a95 Author: Stanislaw Gruszka Date: Wed Aug 8 11:27:15 2012 +0200 sched: fix divide by zero at {thread_group,task}_times commit bea6832cc8c4a0a9a65dd17da6aaa657fe27bc3e upstream. On architectures where cputime_t is 64 bit type, is possible to trigger divide by zero on do_div(temp, (__force u32) total) line, if total is a non zero number but has lower 32 bit's zeroed. Removing casting is not a good solution since some do_div() implementations do cast to u32 internally. This problem can be triggered in practice on very long lived processes: PID: 2331 TASK: ffff880472814b00 CPU: 2 COMMAND: "oraagent.bin" #0 [ffff880472a51b70] machine_kexec at ffffffff8103214b #1 [ffff880472a51bd0] crash_kexec at ffffffff810b91c2 #2 [ffff880472a51ca0] oops_end at ffffffff814f0b00 #3 [ffff880472a51cd0] die at ffffffff8100f26b #4 [ffff880472a51d00] do_trap at ffffffff814f03f4 #5 [ffff880472a51d60] do_divide_error at ffffffff8100cfff #6 [ffff880472a51e00] divide_error at ffffffff8100be7b [exception RIP: thread_group_times+0x56] RIP: ffffffff81056a16 RSP: ffff880472a51eb8 RFLAGS: 00010046 RAX: bc3572c9fe12d194 RBX: ffff880874150800 RCX: 0000000110266fad RDX: 0000000000000000 RSI: ffff880472a51eb8 RDI: 001038ae7d9633dc RBP: ffff880472a51ef8 R8: 00000000b10a3a64 R9: ffff880874150800 R10: 00007fcba27ab680 R11: 0000000000000202 R12: ffff880472a51f08 R13: ffff880472a51f10 R14: 0000000000000000 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff880472a51f00] do_sys_times at ffffffff8108845d #8 [ffff880472a51f40] sys_times at ffffffff81088524 #9 [ffff880472a51f80] system_call_fastpath at ffffffff8100b0f2 RIP: 0000003808caac3a RSP: 00007fcba27ab6d8 RFLAGS: 00000202 RAX: 0000000000000064 RBX: ffffffff8100b0f2 RCX: 0000000000000000 RDX: 00007fcba27ab6e0 RSI: 000000000076d58e RDI: 00007fcba27ab6e0 RBP: 00007fcba27ab700 R8: 0000000000000020 R9: 000000000000091b R10: 00007fcba27ab680 R11: 0000000000000202 R12: 00007fff9ca41940 R13: 0000000000000000 R14: 00007fcba27ac9c0 R15: 00007fff9ca41940 ORIG_RAX: 0000000000000064 CS: 0033 SS: 002b Signed-off-by: Stanislaw Gruszka Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20120808092714.GA3580@redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d20d374e02237853ac94a497e0a4e1cf7c373222 Author: Mike Galbraith Date: Tue Aug 7 05:00:13 2012 +0200 sched,cgroup: Fix up task_groups list commit 35cf4e50b16331def6cfcbee11e49270b6db07f5 upstream. With multiple instances of task_groups, for_each_rt_rq() is a noop, no task groups having been added to the rt.c list instance. This renders __enable/disable_runtime() and print_rt_stats() noop, the user (non) visible effect being that rt task groups are missing in /proc/sched_debug. Signed-off-by: Mike Galbraith Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1344308413.6846.7.camel@marge.simpson.net Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit caecd86a5109f3417e349f42886dfb48d067c3c0 Author: Takashi Iwai Date: Wed Aug 15 12:32:00 2012 +0200 ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream commit e9ba389c5ffc4dd29dfe17e00e48877302111135 upstream. A PCM capture stream on usb-audio causes a scheduling-while-atomic BUG, as reported in the bugzilla entry below. It's because snd_usb_endpoint_start() is called at first at trigger START for a capture stream, and this function contains the left-over EP deactivation codes. The problem doesn't happen for a playback stream because the function is called at PCM prepare time, which can sleep. This patch fixes the BUG by moving the EP deactivation code into the PCM prepare callback. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46011 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 96f7b21cab02436e0757de03a9633cc85cc8f1cf Author: Jan Kara Date: Wed Aug 15 13:50:27 2012 +0200 jbd: don't write superblock when unmounting an ro filesystem commit 2e84f2641ea91a730642ead558a4ee3bd52310c9 upstream. This sequence: results in an IO error when unmounting the RO filesystem. The bug was introduced by: commit 9754e39c7bc51328f145e933bfb0df47cd67b6e9 Author: Jan Kara Date: Sat Apr 7 12:33:03 2012 +0200 jbd: Split updating of journal superblock and marking journal empty which lost some of the magic in journal_update_superblock() which used to test for a journal with no outstanding transactions. This is a port of a jbd2 fix by Eric Sandeen. Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 4bb79d98a512db2416c9c50b07ae592e2d1d7e30 Author: Hugh Dickins Date: Thu Aug 23 12:17:36 2012 +0200 block: replace __getblk_slow misfix by grow_dev_page fix commit 676ce6d5ca3098339c028d44fe0427d1566a4d2d upstream. Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow") is not good: a successful call to grow_buffers() cannot guarantee that the page won't be reclaimed before the immediate next call to __find_get_block(), which is why there was always a loop there. Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595: inode #19278: block 664: comm cc1: unable to read itable block" on console, which pointed to this commit. I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs sometimes fails from a missing header file, under memory pressure on ppc G5. I've never seen this on x86, and I've never seen it on 3.5-rc7 itself, despite that commit being in there: bisection pointed to an irrelevant pinctrl merge, but hard to tell when failure takes between 18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2). (I've since found such __ext4_get_inode_loc errors in /var/log/messages from previous weeks: why the message never appeared on console until yesterday morning is a mystery for another day.) Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus a checkpatch nitfix). Simplify the interface between grow_buffers() and grow_dev_page(), and avoid the infinite loop beyond end of device by instead checking init_page_buffers()'s end_block there (I presume that's more efficient than a repeated call to blkdev_max_block()), returning -ENXIO to __getblk_slow() in that case. And remove akpm's ten-year-old "__getblk() cannot fail ... weird" comment, but that is worrying: are all users of __getblk() really now prepared for a NULL bh beyond end of device, or will some oops?? Signed-off-by: Hugh Dickins Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 90c64968feedd02f6ee1445ed45d6bb9ed132246 Author: Forest Bond Date: Mon Aug 13 16:31:24 2012 +0000 gma500: Consider CRTC initially active. commit 4a68a74ba04e7ccf798d45988f4f2d2131fb5063 upstream. [this one ideally should make 3.6 - it fixes the very annoying mode setting bug] This causes the pipe to be forced off prior to initial mode set, which roughly mirrors the behavior of the i915 driver. It fixes initial mode setting on my Intel DN2800MT (Cedarview) board. Without it, mode setting triggers an out-of-range error from the monitor for most modes, but only on initial configuration (i.e. they can be configured successfully from userspace after that). Signed-off-by: Forest Bond Signed-off-by: Alan Cox Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 21d520720530be46f46a47fc1401549764fe914b Author: Rafael J. Wysocki Date: Sun Aug 12 23:26:07 2012 +0200 PCI: EHCI: Fix crash during hibernation on ASUS computers commit 0b68c8e2c3afaf9807eb1ebe0ccfb3b809570aa4 upstream. Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS computers) added a workaround for an ASUS suspend issue related to USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut down the EHCI controller during system suspend if its PCI command register doesn't contain 0 at that time. It turns out that the same workaround is necessary in the analogous hibernation code path, so add it. References: https://bugzilla.kernel.org/show_bug.cgi?id=45811 Reported-and-tested-by: Oleksij Rempel Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit d680da0053bc1d055bdfb253b85a9738a73ff638 Author: Lorenzo Bianconi Date: Fri Aug 10 11:00:24 2012 +0200 ath9k: fix decrypt_error initialization in ath_rx_tasklet() commit e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 upstream. ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess() in a loop over the received frames. The decrypt_error flag is initialized to false just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by ath9k_rx_skb_preprocess(), only sets decrypt_error to true and never to false. Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes decrypt_error to it. So, after a decryption error, in ath9k_rx_skb_postprocess(), we can have a leftover value from another processed frame. In that case, the frame will not be marked with RX_FLAG_DECRYPTED even if it is decrypted correctly. When using CCMP encryption this issue can lead to connection stuck because of CCMP PN corruption and a waste of CPU time since mac80211 tries to decrypt an already deciphered frame with ieee80211_aes_ccm_decrypt. Fix the issue initializing decrypt_error flag at the begging of the ath_rx_tasklet() loop. Signed-off-by: Lorenzo Bianconi Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b493ba3fafdd46c7a4394ea265c20c38b0b081f7 Author: Rajkumar Manoharan Date: Thu Aug 9 12:37:26 2012 +0530 ath9k: stop btcoex on device suspend commit e19f15ac6437624b6214b2f0ec0d69fb7eb205fa upstream. During suspend, the device will be moved to FULLSLEEP state. As btcoex is never been stopped, the btcoex timer is running and tries to access hw on fullsleep state. Fix that. Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b33d4a8ad7b3ddc9a0c771db44eb1c38da5cb08f Author: Alex Deucher Date: Mon Aug 20 10:57:22 2012 -0400 ACPI: export symbol acpi_get_table_with_size commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream. We need it in the radeon drm module to fetch and verify the vbios image on UEFI systems. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9a132964d51bede2b6ac9df786ba92fb80fc9b97 Author: Stephen M. Cameron Date: Tue Aug 21 16:15:49 2012 -0700 cciss: fix incorrect scsi status reporting commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream. Delete code which sets SCSI status incorrectly as it's already been set correctly above this incorrect code. The bug was introduced in 2009 by commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be lost.") Signed-off-by: Stephen M. Cameron Reported-by: Roel van Meer Tested-by: Roel van Meer Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 999a00b6080f6ca6c9646988f120cc664c03a5ea Author: J. Bruce Fields Date: Mon Aug 20 16:04:40 2012 -0400 svcrpc: sends on closed socket should stop immediately commit f06f00a24d76e168ecb38d352126fd203937b601 upstream. svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply. However, the XPT_CLOSE won't be acted on immediately. Meanwhile other threads could send further replies before the socket is really shut down. This can manifest as data corruption: for example, if a truncated read reply is followed by another rpc reply, that second reply will look to the client like further read data. Symptoms were data corruption preceded by svc_tcp_sendto logging something like kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket Reported-by: Malahal Naineni Tested-by: Malahal Naineni Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 355771fd899705f4253738ed36ab370c52d172d6 Author: J. Bruce Fields Date: Fri Aug 17 17:31:53 2012 -0400 svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream. The rpc server tries to ensure that there will be room to send a reply before it receives a request. It does this by tracking, in xpt_reserved, an upper bound on the total size of the replies that is has already committed to for the socket. Currently it is adding in the estimate for a new reply *before* it checks whether there is space available. If it finds that there is not space, it then subtracts the estimate back out. This may lead the subsequent svc_xprt_enqueue to decide that there is space after all. The results is a svc_recv() that will repeatedly return -EAGAIN, causing server threads to loop without doing any actual work. Reported-by: Michael Tokarev Tested-by: Michael Tokarev Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f5babb0b4ed1988a740d1e103c3ecc4d0dc8deec Author: J. Bruce Fields Date: Thu Aug 9 18:12:28 2012 -0400 svcrpc: fix BUG() in svc_tcp_clear_pages commit be1e44441a560c43c136a562d49a1c9623c91197 upstream. Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if sk_tcplen would lead us to expect n pages of data). svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen. This is OK, since both functions are serialized by XPT_BUSY. However, that means the inconsistency must be repaired before dropping XPT_BUSY. Therefore we should be ensuring that svc_tcp_save_pages repairs the problem before exiting svc_tcp_recv_record on error. Symptoms were a BUG() in svc_tcp_clear_pages. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 4d46966ed3e2917bbfcbdb644fb278dca23cc783 Author: Stefan Behrens Date: Mon Aug 27 08:30:03 2012 -0600 Btrfs: revert checksum error statistic which can cause a BUG() commit 5ee0844d6427e7338e0aba748f62b62d07ea2ed0 upstream. Commit 442a4f6308e694e0fa6025708bd5e4e424bbf51c added btrfs device statistic counters for detected IO and checksum errors to Linux 3.5. The statistic part that counts checksum errors in end_bio_extent_readpage() can cause a BUG() in a subfunction: "kernel BUG at fs/btrfs/volumes.c:3762!" That part is reverted with the current patch. However, the counting of checksum errors in the scrub context remains active, and the counting of detected IO errors (read, write or flush errors) in all contexts remains active. Signed-off-by: Stefan Behrens Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 929b707162f994145a5bd4f8490aab17c0205153 Author: Alex Deucher Date: Tue Aug 21 09:55:01 2012 -0400 Revert "drm/radeon: fix bo creation retry path" commit 676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7 upstream. This reverts commit d1c7871ddb1f588b8eb35affd9ee1a3d5e11cd0c. ttm_bo_init() destroys the BO on failure. So this patch makes the retry path work with freed memory. This ends up causing kernel panics when this path is hit. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit cedb1ad1ad0c585ec4f048639392a6f2db764ba3 Author: Alan Cox Date: Mon Aug 20 14:44:52 2012 +0000 drm: stop vmgfx driver explosion commit f5869a8308f77e3dfdc2e3640842b285aa788ff8 upstream. If you do a page flip with no flags set then event is NULL. If event is NULL then the vmw_gfx driver likes to go digging into NULL and extracts NULL->base.file_priv. On a modern kernel with NULL mapping protection it's just another oops, without it there are some "intriguing" possibilities. What it should do is an open question but that for the driver owners to sort out. Signed-off-by: Alan Cox Reviewed-by: Jakob Bornecrantz Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 0c0b1673a5b1b258d4f1064043557afdffd333f4 Author: Miklos Szeredi Date: Wed Aug 15 12:55:22 2012 +0200 audit: fix refcounting in audit-tree commit a2140fc0cb0325bb6384e788edd27b9a568714e2 upstream. Refcounting of fsnotify_mark in audit tree is broken. E.g: refcount create_chunk alloc_chunk 1 fsnotify_add_mark 2 untag_chunk fsnotify_get_mark 3 fsnotify_destroy_mark audit_tree_freeing_mark 2 fsnotify_put_mark 1 fsnotify_put_mark 0 via destroy_list fsnotify_mark_destroy -1 This was reported by various people as triggering Oops when stopping auditd. We could just remove the put_mark from audit_tree_freeing_mark() but that would break freeing via inode destruction. So this patch simply omits a put_mark after calling destroy_mark or adds a get_mark before. The additional get_mark is necessary where there's no other put_mark after fsnotify_destroy_mark() since it assumes that the caller is holding a reference (or the inode is keeping the mark pinned, not the case here AFAICS). Signed-off-by: Miklos Szeredi Reported-by: Valentin Avram Reported-by: Peter Moody Acked-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 003d4acd2d6a15d1f5eada1873a412622c517b8d Author: Miklos Szeredi Date: Wed Aug 15 12:55:22 2012 +0200 audit: don't free_chunk() after fsnotify_add_mark() commit 0fe33aae0e94b4097dd433c9399e16e17d638cd8 upstream. Don't do free_chunk() after fsnotify_add_mark(). That one does a delayed unref via the destroy list and this results in use-after-free. Signed-off-by: Miklos Szeredi Acked-by: Eric Paris Signed-off-by: Greg Kroah-Hartman commit 7ebfd9ae46f26252dc15d6e961a960f91ff5501b Author: bjschuma@gmail.com Date: Wed Aug 8 13:57:10 2012 -0400 NFS: Alias the nfs module to nfs4 commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream. This allows distros to remove the line from their modprobe configuration. Signed-off-by: Bryan Schumaker Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 78f47208c3d7022ec632764406161504386e8266 Author: Szymon Janc Date: Thu Jul 19 14:46:08 2012 +0200 Bluetooth: Fix legacy pairing with some devices commit a9ea3ed9b71cc3271dd59e76f65748adcaa76422 upstream. Some devices e.g. some Android based phones don't do SDP search before pairing and cancel legacy pairing when ACL is disconnected. PIN Code Request event which changes ACL timeout to HCI_PAIRING_TIMEOUT is only received after remote user entered PIN. In that case no L2CAP is connected so default HCI_DISCONN_TIMEOUT (2 seconds) is being used to timeout ACL connection. This results in problems with legacy pairing as remote user has only few seconds to enter PIN before ACL is disconnected. Increase disconnect timeout for incomming connection to HCI_PAIRING_TIMEOUT if SSP is disabled and no linkey exists. To avoid keeping ACL alive for too long after SDP search set ACL timeout back to HCI_DISCONN_TIMEOUT when L2CAP is connected. 2012-07-19 13:24:43.413521 < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:02:72:D6:6A:3F ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2012-07-19 13:24:43.425224 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 2012-07-19 13:24:43.885222 > HCI Event: Role Change (0x12) plen 8 status 0x00 bdaddr 00:02:72:D6:6A:3F role 0x01 Role: Slave 2012-07-19 13:24:44.054221 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 42 bdaddr 00:02:72:D6:6A:3F type ACL encrypt 0x00 2012-07-19 13:24:44.054313 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 handle 42 2012-07-19 13:24:44.055176 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 bdaddr 00:02:72:D6:6A:3F mode 0 2012-07-19 13:24:44.056217 > HCI Event: Max Slots Change (0x1b) plen 3 handle 42 slots 5 2012-07-19 13:24:44.059218 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0 2012-07-19 13:24:44.062192 > HCI Event: Command Status (0x0f) plen 4 Unknown (0x00|0x0000) status 0x00 ncmd 1 2012-07-19 13:24:44.067219 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 42 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 2012-07-19 13:24:44.067248 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 handle 42 page 1 2012-07-19 13:24:44.071217 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 2012-07-19 13:24:44.076218 > HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 42 page 1 max 1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2012-07-19 13:24:44.076249 < HCI Command: Remote Name Request (0x01|0x0019) plen 10 bdaddr 00:02:72:D6:6A:3F mode 2 clkoffset 0x0000 2012-07-19 13:24:44.081218 > HCI Event: Command Status (0x0f) plen 4 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1 2012-07-19 13:24:44.105214 > HCI Event: Remote Name Req Complete (0x07) plen 255 status 0x00 bdaddr 00:02:72:D6:6A:3F name 'uw000951-0' 2012-07-19 13:24:44.105284 < HCI Command: Authentication Requested (0x01|0x0011) plen 2 handle 42 2012-07-19 13:24:44.111207 > HCI Event: Command Status (0x0f) plen 4 Authentication Requested (0x01|0x0011) status 0x00 ncmd 1 2012-07-19 13:24:44.112220 > HCI Event: Link Key Request (0x17) plen 6 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:44.112249 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:44.115215 > HCI Event: Command Complete (0x0e) plen 10 Link Key Request Negative Reply (0x01|0x000c) ncmd 1 status 0x00 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:44.116215 > HCI Event: PIN Code Request (0x16) plen 6 bdaddr 00:02:72:D6:6A:3F 2012-07-19 13:24:48.099184 > HCI Event: Auth Complete (0x06) plen 3 status 0x13 handle 42 Error: Remote User Terminated Connection 2012-07-19 13:24:48.179182 > HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 42 reason 0x13 Reason: Remote User Terminated Connection Signed-off-by: Szymon Janc Acked-by: Johan Hedberg Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit c9e7000a6cd8fad9a5803c1bbceeb3a0203d7b8f Author: Ram Malovany Date: Thu Jul 19 10:26:11 2012 +0300 Bluetooth: Set name_state to unknown when entry name is empty commit c3e7c0d90b14a3e7ac091d24cef09efb516d587b upstream. When the name of the given entry is empty , the state needs to be updated accordingly. Signed-off-by: Ram Malovany Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 3081d97a11571d26b6f68c85d1d1d84eefd9b088 Author: Ram Malovany Date: Thu Jul 19 10:26:10 2012 +0300 Bluetooth: Fix using a NULL inquiry cache entry commit 7cc8380eb10347016d95bf6f9d842c2ae6d12932 upstream. If the device was not found in a list of found devices names of which are pending.This may happen in a case when HCI Remote Name Request was sent as a part of incoming connection establishment procedure. Hence there is no need to continue resolving a next name as it will be done upon receiving another Remote Name Request Complete Event. This will fix a kernel crash when trying to use this entry to resolve the next name. Signed-off-by: Ram Malovany Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 27c3ea1ee98c3e25642b12ecf0b4ca5dc7a60f51 Author: Ram Malovany Date: Thu Jul 19 10:26:09 2012 +0300 Bluetooth: Fix using NULL inquiry entry commit c810089c27e48b816181b454fcc493d19fdbc2ba upstream. If entry wasn't found in the hci_inquiry_cache_lookup_resolve do not resolve the name.This will fix a kernel crash when trying to use NULL pointer. Signed-off-by: Ram Malovany Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 7c3b873743b682dc1c66cac3eb4fdcba3f567a3a Author: Artem Bityutskiy Date: Tue Aug 21 21:50:58 2012 +0300 UBIFS: fix complaints about too small debug buffer size commit 65b455b123c7e2b835a0b7148f9bae584f95000e upstream. When debugging is enabled, we use a temporary on-stack buffer for formatting the key strings like "(11368871, direntry, 0xcd0750)". The buffer size is 32 bytes and sometimes it is not enough to fit the key string - e.g., when inode numbers are high. This is not fatal, but the key strings are incomplete and UBIFS complains like this: UBIFS assert failed in dbg_snprintf_key at 137 (pid 1) This is a regression caused by "515315a UBIFS: fix key printing". Fix the issue by increasing the buffer to 48 bytes. Reported-by: Michael Hench Signed-off-by: Artem Bityutskiy Tested-by: Michael Hench Signed-off-by: Greg Kroah-Hartman commit 75a8ac4c5552f71f5a1db27a3232e6e389a1274c Author: Artem Bityutskiy Date: Mon Aug 20 15:16:24 2012 +0300 UBIFS: fix crash on error path commit 11e3be0be2a1314e0861304857e7efcaed5d3e54 upstream. This patch fixes a regression introduced by "4994297 UBIFS: make ubifs_lpt_init clean-up in case of failure" which I've hit while running the 'integck -p' test. When remount the file-system from R/O mode to R/W mode and 'lpt_init_wr()' fails, we free _all_ LPT resources by calling 'ubifs_lpt_free(c, 0)', even those needed for R/O mode. This leads to subsequent crashes, e.g., if we try to unmount the file-system. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 9abbc5a9d54be7dbcc920d079ae790db3520f337 Author: J. Bruce Fields Date: Thu Aug 16 17:01:21 2012 -0400 nfsd4: fix security flavor of NFSv4.0 callback commit 39307655a1effa8d913bba054c0e985bfaca808c upstream. Commit d5497fc693a446ce9100fcf4117c3f795ddfd0d2 "nfsd4: move rq_flavor into svc_cred" forgot to remove cl_flavor from the client, leaving two places (cl_flavor and cl_cred.cr_flavor) for the flavor to be stored. After that patch, the latter was the one that was updated, but the former was the one that the callback used. Symptoms were a long delay on utime(). This is because the utime() generated a setattr which recalled a delegation, but the cb_recall was ignored by the client because it had the wrong security flavor. Tested-by: Jamie Heilman Reported-by: Jamie Heilman Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit bdd78615ccef0cb43ab4214c9f315efdefedcd6e Author: Bryan Schumaker Date: Thu Aug 9 14:05:50 2012 -0400 NFS: return -ENOKEY when the upcall fails to map the name commit 12dfd080556124088ed61a292184947711b46cbe upstream. This allows the normal error-paths to handle the error, rather than making a special call to complete_request_key() just for this instance. Signed-off-by: Bryan Schumaker Tested-by: William Dauchy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 28a59a3a607da7fccc376d378ed7d9937af6ae08 Author: Bryan Schumaker Date: Thu Aug 9 14:05:49 2012 -0400 NFS: Clear key construction data if the idmap upcall fails commit c5066945b7ea346a11424dbeb7830b7d7d00c206 upstream. idmap_pipe_downcall already clears this field if the upcall succeeds, but if it fails (rpc.idmapd isn't running) the field will still be set on the next call triggering a BUG_ON(). This patch tries to handle all possible ways that the upcall could fail and clear the idmap key data for each one. Signed-off-by: Bryan Schumaker Tested-by: William Dauchy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 86755a41f4d5e2b3f5e9a8740820eb05654c0c4d Author: Trond Myklebust Date: Wed Aug 8 16:03:13 2012 -0400 NFSv4.1: Remove a bogus BUG_ON() in nfs4_layoutreturn_done commit 47fbf7976e0b7d9dcdd799e2a1baba19064d9631 upstream. Ever since commit 0a57cdac3f (NFSv4.1 send layoutreturn to fence disconnected data server) we've been sending layoutreturn calls while there is potentially still outstanding I/O to the data servers. The reason we do this is to avoid races between replayed writes to the MDS and the original writes to the DS. When this happens, the BUG_ON() in nfs4_layoutreturn_done can be triggered because it assumes that we would never call layoutreturn without knowing that all I/O to the DS is finished. The fix is to remove the BUG_ON() now that the assumptions behind the test are obsolete. Reported-by: Boaz Harrosh Reported-by: Tigran Mkrtchyan Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit b760afea799e18076fb08c39ac6ebbbcd1d2020e Author: Jeff Layton Date: Thu Aug 2 14:30:56 2012 -0400 nfs: tear down caches in nfs_init_writepagecache when allocation fails commit 3dd4765fce04c0b4af1e0bc4c0b10f906f95fabc upstream. ...and ensure that we tear down the nfs_commit_data cache too when unloading the module. Cc: Bryan Schumaker Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit be6977c8d7adf2e338941ed7c8edc26eef7e6782 Author: Idan Kedar Date: Thu Aug 2 11:47:10 2012 +0300 pnfs: defer release of pages in layoutget commit 8554116e17eef055d9dd58a94b3427cb2ad1c317 upstream. we have encountered a bug whereby reading a lot of files (copying fedora's /bin) from a pNFS mount and hitting Ctrl+C in the middle caused a general protection fault in xdr_shrink_bufhead. this function is called when decoding the response from LAYOUTGET. the decoding is done by a worker thread, and the caller of LAYOUTGET waits for the worker thread to complete. hitting Ctrl+C caused the synchronous wait to end and the next thing the caller does is to free the pages, so when the worker thread calls xdr_shrink_bufhead, the pages are gone. therefore, the cleanup of these pages has been moved to nfs4_layoutget_release. Signed-off-by: Idan Kedar Signed-off-by: Benny Halevy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 9e4fe63cc868d001894f957c7e1164824b2e4ca3 Author: Trond Myklebust Date: Mon Aug 20 12:42:15 2012 -0400 NFSv3: Ensure that do_proc_get_root() reports errors correctly commit 086600430493e04b802bee6e5b3ce0458e4eb77f upstream. If the rpc call to NFS3PROC_FSINFO fails, then we need to report that error so that the mount fails. Otherwise we can end up with a superblock with completely unusable values for block sizes, maxfilesize, etc. Reported-by: Yuanming Chen Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit df7ee7fd51727af73a9f611a4604a1bc4133b0fb Author: Yi Zou Date: Tue Aug 14 16:06:43 2012 -0700 target: fix NULL pointer dereference bug alloc_page() fails to get memory commit d0e27c88d795fb9647153063ec48051fd84e1731 upstream. I am hitting this bug when the target is low in memory that fails the alloc_page() for the newly submitted command. This is a sort of off-by-one bug causing NULL pointer dereference in __free_page() since 'i' here is really the counter of total pages that have been successfully allocated here. Signed-off-by: Yi Zou Cc: Andy Grover Cc: Nicholas Bellinger Cc: Open-FCoE.org Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit b74c2ca5e058c96cd7792e9ec07fb96e7c3a9a1d Author: Takashi Iwai Date: Mon Aug 20 21:25:22 2012 +0200 ALSA: hda - Fix leftover codec->power_transition commit 535b6c51fe8293c88ce919cdfc4390c67a1cb6d1 upstream. When the codec turn-on operation is canceled by the immediate power-on, the driver left the power_transition flag as is. This caused the persistent avoidance of power-save behavior. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 183544678fab5e5d0a0d63c7d2d15bc15f98934f Author: David Henningsson Date: Mon Aug 20 11:17:00 2012 +0200 ALSA: hda - don't create dysfunctional mixer controls for ca0132 commit c41999a23929f30808bae6009d8065052d4d73fd upstream. It's possible that these amps are settable somehow, e g through secret codec verbs, but for now, don't create the controls (as they won't be working anyway, and cause errors in amixer). BugLink: https://bugs.launchpad.net/bugs/1038651 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ac92c8b7d4afc6fd1a3a8d53fcd98d2e92cf3ce0 Author: Michal Hocko Date: Tue Aug 21 16:15:52 2012 -0700 mm: hugetlbfs: correctly populate shared pmd commit eb48c071464757414538c68a6033c8f8c15196f8 upstream. Each page mapped in a process's address space must be correctly accounted for in _mapcount. Normally the rules for this are straightforward but hugetlbfs page table sharing is different. The page table pages at the PMD level are reference counted while the mapcount remains the same. If this accounting is wrong, it causes bugs like this one reported by Larry Woodman: kernel BUG at mm/filemap.c:135! invalid opcode: 0000 [#1] SMP CPU 22 Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi] Pid: 18001, comm: mpitest Tainted: G W 3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2 RIP: 0010:[] [] __delete_from_page_cache+0x15d/0x170 Process mpitest (pid: 18001, threadinfo ffff880428972000, task ffff880428b5cc20) Call Trace: delete_from_page_cache+0x40/0x80 truncate_hugepages+0x115/0x1f0 hugetlbfs_evict_inode+0x18/0x30 evict+0x9f/0x1b0 iput_final+0xe3/0x1e0 iput+0x3e/0x50 d_kill+0xf8/0x110 dput+0xe2/0x1b0 __fput+0x162/0x240 During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc() shared page tables with the check dst_pte == src_pte. The logic is if the PMD page is the same, they must be shared. This assumes that the sharing is between the parent and child. However, if the sharing is with a different process entirely then this check fails as in this diagram: parent | ------------>pmd src_pte----------> data page ^ other--------->pmd--------------------| ^ child-----------| dst_pte For this situation to occur, it must be possible for Parent and Other to have faulted and failed to share page tables with each other. This is possible due to the following style of race. PROC A PROC B copy_hugetlb_page_range copy_hugetlb_page_range src_pte == huge_pte_offset src_pte == huge_pte_offset !src_pte so no sharing !src_pte so no sharing (time passes) hugetlb_fault hugetlb_fault huge_pte_alloc huge_pte_alloc huge_pmd_share huge_pmd_share LOCK(i_mmap_mutex) find nothing, no sharing UNLOCK(i_mmap_mutex) LOCK(i_mmap_mutex) find nothing, no sharing UNLOCK(i_mmap_mutex) pmd_alloc pmd_alloc LOCK(instantiation_mutex) fault UNLOCK(instantiation_mutex) LOCK(instantiation_mutex) fault UNLOCK(instantiation_mutex) These two processes are not poing to the same data page but are not sharing page tables because the opportunity was missed. When either process later forks, the src_pte == dst pte is potentially insufficient. As the check falls through, the wrong PTE information is copied in (harmless but wrong) and the mapcount is bumped for a page mapped by a shared page table leading to the BUG_ON. This patch addresses the issue by moving pmd_alloc into huge_pmd_share which guarantees that the shared pud is populated in the same critical section as pmd. This also means that huge_pte_offset test in huge_pmd_share is serialized correctly now which in turn means that the success of the sharing will be higher as the racing tasks see the pud and pmd populated together. Race identified and changelog written mostly by Mel Gorman. {akpm@linux-foundation.org: attempt to make the huge_pmd_share() comment comprehensible, clean up coding style] Reported-by: Larry Woodman Tested-by: Larry Woodman Reviewed-by: Mel Gorman Signed-off-by: Michal Hocko Reviewed-by: Rik van Riel Cc: David Gibson Cc: Ken Chen Cc: Cong Wang Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3c808058188427121e520b9f769710188fa6a4f7 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:37 2012 -0700 USB: winbond: remove __devinit* from the struct usb_device_id table commit 43a34695d9cd79c6659f09da6d3b0624f3dd169f upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Pavel Machek CC: Paul Gortmaker CC: "John W. Linville" CC: Eliad Peller CC: Devendra Naga Signed-off-by: Greg Kroah-Hartman commit 6a09f9b5bf2061f23350625c42e9ad4792e1d483 Author: Michael Cree Date: Sun Aug 19 14:40:56 2012 +1200 alpha: Don't export SOCK_NONBLOCK to user space. commit a2fa3ccd7b43665fe14cb562761a6c3d26a1d13f upstream. Currently we export SOCK_NONBLOCK to user space but that conflicts with the definition from glibc leading to compilation errors in user programs (e.g. see Debian bug #658460). The generic socket.h restricts the definition of SOCK_NONBLOCK to the kernel, as does the MIPS specific socket.h, so let's do the same on Alpha. Signed-off-by: Michael Cree Acked-by: Matt Turner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 20b223443ed020f873f05d68342e3acec70f8100 Author: Mike Frysinger Date: Sun Aug 19 14:41:02 2012 +1200 alpha: fix fpu.h usage in userspace commit 0be421862b857e61964435ffcaa7499cf77a5e5a upstream. After commit ec2212088c42 ("Disintegrate asm/system.h for Alpha"), the fpu.h header which we install for userland started depending on special_insns.h which is not installed. However, fpu.h only uses that for __KERNEL__ code, so protect the inclusion the same way to avoid build breakage in glibc: /usr/include/asm/fpu.h:4:31: fatal error: asm/special_insns.h: No such file or directory Reported-by: Matt Turner Signed-off-by: Mike Frysinger Signed-off-by: Michael Cree Acked-by: Matt Turner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8b5496986969373e103b9c8a63d6f7fa082d370f Author: Miklos Szeredi Date: Wed Aug 15 13:01:24 2012 +0200 vfs: canonicalize create mode in build_open_flags() commit e68726ff72cf7ba5e7d789857fcd9a75ca573f03 upstream. Userspace can pass weird create mode in open(2) that we canonicalize to "(mode & S_IALLUGO) | S_IFREG" in vfs_create(). The problem is that we use the uncanonicalized mode before calling vfs_create() with unforseen consequences. So do the canonicalization early in build_open_flags(). Signed-off-by: Miklos Szeredi Tested-by: Richard W.M. Jones Signed-off-by: Greg Kroah-Hartman commit 9ef98b1ee6a8c418bd26a3bd5edbbf719d30296b Author: Al Viro Date: Mon Aug 20 15:28:00 2012 +0100 vfs: missed source of ->f_pos races commit 0e665d5d1125f9f4ccff56a75e814f10f88861a2 upstream. compat_sys_{read,write}v() need the same "pass a copy of file->f_pos" thing as sys_{read,write}{,v}(). Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 71d7e5b0dec5025cb9826cda458c8ad52537e910 Author: Peter Ujfalusi Date: Tue Aug 7 15:37:47 2012 +0300 ASoC: omap-mcbsp: Fix 6pin mux configuration commit d0db84e713eaaccea2a435e1625fb3150b335f4a upstream. The check for the mux_signal callback was wrong which prevents us to configure the 6pin port's FSR/CLKR signal mux. Reported-by: CF Adad Signed-off-by: Peter Ujfalusi Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c1281938088283ea813f9692b0fc692ab8decd83 Author: Mark Brown Date: Thu Aug 16 22:36:04 2012 +0100 ASoC: wm9712: Fix microphone source selection commit ccf795847a38235ee4a56a24129ce75147d6ba8f upstream. Currently the microphone input source is not selectable as while there is a DAPM widget it's not connected to anything so it won't be properly instantiated. Add something more correct for the input structure to get things going, even though it's not hooked into the rest of the routing map and so won't actually achieve anything except allowing the relevant register bits to be written. Reported-by: Christop Fritz Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aa680a4f0ac6f08f0a26dd84d5217b0468648ac9 Author: Gabor Juhos Date: Thu Aug 23 15:35:26 2012 +0200 MIPS: pci-ar724x: avoid data bus error due to a missing PCIe module commit a1dca315ce3f78347bca8ce8befe3cc71ae63b7e upstream. If the controller has no PCIe module attached, accessing of the device configuration space causes a data bus error. Avoid this by checking the status of the PCIe link in advance, and indicate an error if the link is down. Signed-off-by: Gabor Juhos Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/4293/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit f3f4e41c825b5444ee14b37385f162edc4aefdd2 Author: Arnd Bergmann Date: Fri Aug 17 00:16:08 2012 +0000 ARM: imx: build i.MX6 functions only when needed commit 1fc593feaf8e440511f381f4cdff483b55bbf546 upstream. The head-v7.S contains a call to the generic cpu_suspend function, which is only available when selected by the i.MX6 code. As pointed out by Shawn Guo, i.MX5 does not actually use any functions defined in head-v7.S. It is also needed only for the i.MX6 power management code and for the SMP code, so we can restrict building this file to situations in which at least one of those two is present. Finally, other platforms with a similar file call it headsmp.S, so we can rename it to the same for consistency. Without this patch, building imx5 standalone results in: arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume': arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume' Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Eric Miao Signed-off-by: Greg Kroah-Hartman commit e08c30c92571c1bd0e47ac58c53633cf2b7eb6c1 Author: Arnd Bergmann Date: Thu Aug 16 10:40:40 2012 +0000 ARM: imx: select CPU_FREQ_TABLE when needed commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream. The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers, so it needs to select that code to be built. This problem has apparently existed since the i.MX cpufreq code was first merged in v2.6.37. Building IMX without CPU_FREQ_TABLE results in: arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit': arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr' arch/arm/plat-mxc/built-in.o: In function `mxc_set_target': arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target' arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed': arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify' arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init': arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo' arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr' Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Cc: Yong Shen Signed-off-by: Greg Kroah-Hartman commit c9a8543355c1d39254723d3276e32c80d349c622 Author: Arnd Bergmann Date: Wed Aug 15 21:56:39 2012 +0000 ARM: imx: build pm-imx5 code only when PM is enabled commit a28eecef8ac2671dce7d892165bf374eeaa04e15 upstream. This moves the imx5 pm code out of the list of unconditionally compiled files for imx5, mirroring what we already do for imx6 and how it was done before the code was move from mach-mx5 to mach-imx in v3.3. Without this patch, building with CONFIG_PM disabled results in: arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init' arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init' arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Signed-off-by: Greg Kroah-Hartman commit 79742799664dd4ded2450740e979b2f03baa2387 Author: Shawn Guo Date: Sat Aug 18 14:27:32 2012 +0800 ARM: imx6: spin the cpu until hardware takes it down commit c944b0b9354ea06ffb0c8a7178949f1185f9f499 upstream. Though commit 602bf40 (ARM: imx6: exit coherency when shutting down a cpu) improves the stability of imx6q cpu hotplug a lot, there are still hangs seen with a more stressful hotplug testing. It's expected that once imx_enable_cpu(cpu, false) is called, the cpu will be taken down by hardware immediately, and the code after that will not get any chance to execute. However, this is not always the case from the testing. The cpu could possibly be alive for a few cycles before hardware actually takes it down. So rather than letting cpu execute some code that could cause a hang in these cycles, let's make the cpu spin there and wait for hardware to take it down. Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 5f2b8db0f5992cd4e9ca4d08cfd1a662e5bfc60c Author: Konrad Rzeszutek Wilk Date: Fri Aug 17 16:43:28 2012 -0400 xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M. commit c96aae1f7f393387d160211f60398d58463a7e65 upstream. When we are finished with return PFNs to the hypervisor, then populate it back, and also mark the E820 MMIO and E820 gaps as IDENTITY_FRAMEs, we then call P2M to set areas that can be used for ballooning. We were off by one, and ended up over-writting a P2M entry that most likely was an IDENTITY_FRAME. For example: 1-1 mapping on 40000->40200 1-1 mapping on bc558->bc5ac 1-1 mapping on bc5b4->bc8c5 1-1 mapping on bc8c6->bcb7c 1-1 mapping on bcd00->100000 Released 614 pages of unused memory Set 277889 page(s) to 1-1 mapping Populating 40200-40466 pfn range: 614 pages added => here we set from 40466 up to bc559 P2M tree to be INVALID_P2M_ENTRY. We should have done it up to bc558. The end result is that if anybody is trying to construct a PTE for PFN bc558 they end up with ~PAGE_PRESENT. Reported-by-and-Tested-by: Andre Przywara Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit af917936c3b23135a36f756f4d18f597db9278be Author: Konrad Rzeszutek Wilk Date: Fri Aug 17 09:27:35 2012 -0400 xen/p2m: Reuse existing P2M leafs if they are filled with 1:1 PFNs or INVALID. commit 250a41e0ecc433cdd553a364d0fc74c766425209 upstream. If P2M leaf is completly packed with INVALID_P2M_ENTRY or with 1:1 PFNs (so IDENTITY_FRAME type PFNs), we can swap the P2M leaf with either a p2m_missing or p2m_identity respectively. The old page (which was created via extend_brk or was grafted on from the mfn_list) can be re-used for setting new PFNs. This also means we can remove git commit: 5bc6f9888db5739abfa0cae279b4b442e4db8049 xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back which tried to fix this. and make the amount that is required to be reserved much smaller. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit e12f4dfa58909518d4e741de4195f0e2cc136dd5 Author: Heiko Stuebner Date: Tue Aug 7 19:12:05 2012 +0900 ARM: S3C24XX: Fix s3c2410_dma_enqueue parameters commit b01858c7806e7e6f6121da2e51c9222fc4d21dc6 upstream. Commit d670ac019f60 (ARM: SAMSUNG: DMA Cleanup as per sparse) changed the prototype of the s3c2410_dma_* functions to use the enum dma_ch instead of an generic unsigned int. In the s3c24xx dma.c s3c2410_dma_enqueue seems to have been forgotten, the other functions there were changed correctly. Signed-off-by: Heiko Stuebner Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit c88732dcda67bbcb7f8dd0bceb1060f4bb8e43bb Author: Heiko Stuebner Date: Tue Aug 7 19:11:33 2012 +0900 ARM: S3C24XX: Add missing DMACH_DT_PROP commit e1267371eacf2cbcf580e41f9e64a986cdaf5c1d upstream. Commit 2b90807549 (spi: s3c64xx: add device tree support) requires the DMACH_DT_PROP element in the dma_ch enum. It's not used on non-DT platforms but has to be present nevertheless. So mimic the dummy-add of DMACH_DT_PROP on s3c64xx for s3c24xx machines, to correct the build breakage for the s3c24xx variants using the s3c64xx-spi-driver. Signed-off-by: Heiko Stuebner Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman commit 79f15fb694f66c61c302947dc1ba2c4c46889450 Author: Jon Hunter Date: Fri Jul 13 15:12:03 2012 -0500 ARM: OMAP2+: Fix dmtimer set source clock failure commit 54f32a35f4d3a653a18a2c8c239f19ae060bd803 upstream. Calling the dmtimer function omap_dm_timer_set_source() fails if following a call to pm_runtime_put() to disable the timer. For example the following sequence would fail to set the parent clock ... omap_dm_timer_stop(gptimer); omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ); The following error message would be seen ... omap_dm_timer_set_source: failed to set timer_32k_ck as parent The problem is that, by design, pm_runtime_put() simply decrements the usage count and returns before the timer has actually been disabled. Therefore, setting the parent clock failed because the timer was still active when the trying to set the parent clock. Setting a parent clock will fail if the clock you are setting the parent of has a non-zero usage count. To ensure that this does not fail use pm_runtime_put_sync() when disabling the timer. Note that this will not be seen on OMAP1 devices, because these devices do not use the clock framework for dmtimers. Signed-off-by: Jon Hunter Acked-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 3de9b7a96fae683f30c12b9cb4d77f7000fd71ed Author: Will Deacon Date: Fri Aug 10 19:13:36 2012 +0100 ARM: 7489/1: errata: fix workaround for erratum #720789 on UP systems commit 730a8128cd8978467eb1cf546b11014acb57d433 upstream. Commit 5a783cbc4836 ("ARM: 7478/1: errata: extend workaround for erratum #720789") added workarounds for erratum #720789 to the range TLB invalidation functions with the observation that the erratum only affects SMP platforms. However, when running an SMP_ON_UP kernel on a uniprocessor platform we must take care to preserve the ASID as the workaround is not required. This patch ensures that we don't set the ASID to 0 when flushing the TLB on such a system, preserving the original behaviour with the workaround disabled. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 0b80803ce3abad2533fc03133d1ca1759c8335fd Author: Will Deacon Date: Fri Aug 10 17:51:19 2012 +0100 ARM: 7488/1: mm: use 5 bits for swapfile type encoding commit f5f2025ef3e2cdb593707cbf87378761f17befbe upstream. Page migration encodes the pfn in the offset field of a swp_entry_t. For LPAE, we support physical addresses of up to 36 bits (due to sparsemem limitations with the size of page flags), requiring 24 bits to represent a pfn. A further 3 bits are used to encode a swp_entry into a pte, leaving 5 bits for the type field. Furthermore, the core code defines MAX_SWAPFILES_SHIFT as 5, so the additional type bit does not get used. This patch reduces the width of the type field to 5 bits, allowing us to create up to 31 swapfiles of 64GB each. Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 0d478458e95d8b3e312b96c55d8dc594a2fb90fa Author: Will Deacon Date: Fri Aug 10 17:51:18 2012 +0100 ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present commit 47f1204329237a0f8655f5a9f14a38ac81946ca1 upstream. Swap entries are encoding in ptes such that !pte_present(pte) and pte_file(pte). The remaining bits of the descriptor are used to identify the swapfile and offset within it to the swap entry. When writing such a pte for a user virtual address, set_pte_at unconditionally sets the nG bit, which (in the case of LPAE) will corrupt the swapfile offset and lead to a BUG: [ 140.494067] swap_free: Unused swap offset entry 000763b4 [ 140.509989] BUG: Bad page map in process rs:main Q:Reg pte:0ec76800 pmd:8f92e003 This patch fixes the problem by only setting the nG bit for user mappings that are actually present. Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 6d7a1cdbfab0005e52f02d414eb8f20695bbb668 Author: Will Deacon Date: Fri Aug 3 17:24:14 2012 +0100 ARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled commit 3d9fb0038a9b02febb01efc79a4a5d97f1822a90 upstream. VFPv4 support depends on the VFPv3 context save/restore code, so only advertise support in the hwcaps if the kernel can actually handle it. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 58c40d2e74d252d9db03bae61d820059c35124e2 Author: Wang Xingchao Date: Mon Aug 13 14:11:10 2012 +0800 ALSA: hda - fix Copyright debug message commit 088c820b732dbfd515fc66d459d5f5777f79b406 upstream. As spec said, 1 indicates no copyright is asserted. Signed-off-by: Wang Xingchao Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fe6481e7397566b7a22f6d25aeace1db2ba051f9 Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:41 2012 -0700 USB: emi62: remove __devinit* from the struct usb_device_id table commit 83957df21dd94655d2b026e0944a69ff37b83988 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Paul Gortmaker CC: Andrew Morton CC: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d7c5eb442eec26b1742acbead48b0363b3d3eefa Author: Greg Kroah-Hartman Date: Fri Aug 17 17:48:33 2012 -0700 USB: vt6656: remove __devinit* from the struct usb_device_id table commit 4d088876f24887cd15a29db923f5f37db6a99f21 upstream. This structure needs to always stick around, even if CONFIG_HOTPLUG is disabled, otherwise we can oops when trying to probe a device that was added after the structure is thrown away. Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down. Reported-by: Fengguang Wu Reported-by: Bjørn Mork CC: Forest Bond CC: Marcos Paulo de Souza CC: "David S. Miller" CC: Jesper Juhl CC: Jiri Pirko Signed-off-by: Greg Kroah-Hartman