commit f95b978981a7d154ba40d14c18e8ed5c694e6124 Author: Greg Kroah-Hartman Date: Sun Aug 26 15:02:10 2012 -0700 Linux 3.4.10 commit e19001248f898e24b4ec08f9f853b49e661328fe Author: Jeongdo Son Date: Fri Jun 15 02:28:01 2012 +0900 rt2x00: Add support for BUFFALO WLI-UC-GNM2 to rt2800usb. commit a769f9577232afe2c754606a83aad85127e7052a upstream. This is a RT3070 based device. Signed-off-by: Jeongdo Son Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4cfb77e8eeddabbca1173a0a704c4065c62c4d05 Author: Michael Grzeschik Date: Wed Aug 8 11:48:10 2012 +0200 usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop commit b1b552a69b8805e7e338074a9e8b670b4a795218 upstream. This patch fixes an issue introduced by patch: 72c973d usb: gadget: add usb_endpoint_descriptor to struct usb_ep Without this patch we see a kworker taking 100% CPU, after this sequence: - Connect gadget to a windows host - load g_ether - ifconfig up ; ifconfig down; ifconfig up - ping The "ifconfig down" results in calling eth_stop(), which will call usb_ep_disable() and, if the carrier is still ok, usb_ep_enable(): usb_ep_disable(link->in_ep); usb_ep_disable(link->out_ep); if (netif_carrier_ok(net)) { usb_ep_enable(link->in_ep); usb_ep_enable(link->out_ep); } The ep should stay enabled, but will not, as ep_disable set the desc pointer to NULL, therefore the subsequent ep_enable will fail. This leads to permanent rescheduling of the eth_work() worker as usb_ep_queue() (called by the worker) will fail due to the unconfigured endpoint. We fix this issue by saving the ep descriptors and re-assign them before usb_ep_enable(). Cc: Tatyana Brokhman Signed-off-by: Michael Grzeschik Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 4893ce51af5c2ccdfabf8f7d34dd28cf84a8a06e Author: Mark Ferrell Date: Tue Jul 24 14:15:13 2012 -0500 usb: serial: mos7840: Fixup mos7840_chars_in_buffer() commit 5c263b92f828af6a8cf54041db45ceae5af8f2ab upstream. * Use the buffer content length as opposed to the total buffer size. This can be a real problem when using the mos7840 as a usb serial-console as all kernel output is truncated during boot. Signed-off-by: Mark Ferrell Signed-off-by: Greg Kroah-Hartman commit d3d31e57513f7f66fe66accd88837e021a1b96b2 Author: Ozan Çağlayan Date: Fri Aug 10 17:25:10 2012 +0300 USB: ftdi_sio: Add VID/PID for Kondo Serial USB commit 7724a1edbe463b06d4e7831a41149ba095b16c53 upstream. This adds VID/PID for Kondo Kagaku Co. Ltd. Serial USB Adapter interface: http://www.kondo-robot.com/EN/wp/?cat=28 Tested by controlling an RCB3 board using libRCB3. Signed-off-by: Ozan Çağlayan Signed-off-by: Greg Kroah-Hartman commit 7c65b87f22d8a7819879363ef9fc3e6d838925d4 Author: Bjørn Mork Date: Wed Aug 15 15:43:33 2012 +0200 USB: option: add ZTE K5006-Z commit f1b5c997e68533df1f96dcd3068a231bca495603 upstream. The ZTE (Vodafone) K5006-Z use the following interface layout: 00 DIAG 01 secondary 02 modem 03 networkcard 04 storage Ignoring interface #3 which is handled by the qmi_wwan driver. Signed-off-by: Bjørn Mork Cc: Thomas Schäfer Signed-off-by: Greg Kroah-Hartman commit c638628c4aafdd2c6bb555331e5dcb099df7f59c Author: fangxiaozhi Date: Wed Aug 8 09:24:45 2012 +0000 USB: support the new interfaces of Huawei Data Card devices in option driver commit ee6f827df9107139e8960326e49e1376352ced4d upstream. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi Signed-off-by: Greg Kroah-Hartman commit ddffad3427e2e80fff78d2fc77f21afbba3d11b0 Author: Bart Van Assche Date: Tue Aug 14 13:18:53 2012 +0000 IB/srp: Fix a race condition commit 220329916c72ee3d54ae7262b215a050f04a18fc upstream. Avoid a crash caused by the scmnd->scsi_done(scmnd) call in srp_process_rsp() being invoked with scsi_done == NULL. This can happen if a reply is received during or after a command abort. Reported-by: Joseph Glanville Reference: http://marc.info/?l=linux-rdma&m=134314367801595 Acked-by: David Dillow Signed-off-by: Bart Van Assche Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit a8e480349f91581d93eff8728fc41cbcd1c3eca1 Author: Jason Wessel Date: Sun Aug 12 07:16:43 2012 -0500 pmac_zilog,kdb: Fix console poll hook to return instead of loop commit 38f8eefccf3a23c4058a570fa2938a4f553cf8e0 upstream. kdb <-> kgdb transitioning does not work properly with this UART driver because the get character routine loops indefinitely as opposed to returning NO_POLL_CHAR per the expectation of the KDB I/O driver API. The symptom is a kernel hang when trying to switch debug modes. Signed-off-by: Jason Wessel Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 952227d5c4d522502b7b815b16be6e991bbaeaed Author: Gustavo Padovan Date: Tue Jul 10 19:10:06 2012 -0300 USB: add USB_VENDOR_AND_INTERFACE_INFO() macro commit d81a5d1956731c453b85c141458d4ff5d6cc5366 upstream. A lot of Broadcom Bluetooth devices provides vendor specific interface class and we are getting flooded by patches adding new device support. This change will help us enable support for any other Broadcom with vendor specific device that arrives in the future. Only the product id changes for those devices, so this macro would be perfect for us: { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) } Signed-off-by: Marcel Holtmann Signed-off-by: Gustavo Padovan Acked-by: Henrik Rydberg Signed-off-by: Greg Kroah-Hartman commit 1aac2e73a8af6ce1cd6e938967dd17e2c8d38994 Author: Sarah Sharp Date: Thu Jul 26 12:03:59 2012 -0700 xhci: Fix bug after deq ptr set to link TRB. commit 50d0206fcaea3e736f912fd5b00ec6233fb4ce44 upstream. This patch fixes a particularly nasty bug that was revealed by the ring expansion patches. The bug has been present since the very beginning of the xHCI driver history, and could have caused general protection faults from bad memory accesses. The first thing to note is that a Set TR Dequeue Pointer command can move the dequeue pointer to a link TRB, if the canceled or stalled transfer TD ended just before a link TRB. The function to increment the dequeue pointer, inc_deq, was written before cancellation and stall support was added. It assumed that the dequeue pointer could never point to a link TRB. It would unconditionally increment the dequeue pointer at the start of the function, check if the pointer was now on a link TRB, and move it to the top of the next segment if so. This means that if a Set TR Dequeue Point command moved the dequeue pointer to a link TRB, a subsequent call to inc_deq() would move the pointer off the segment and into la-la-land. It would then read from that memory to determine if it was a link TRB. Other functions would often call inc_deq() until the dequeue pointer matched some other pointer, which means this function would quite happily read all of system memory before wrapping around to the right pointer value. Often, there would be another endpoint segment from a different ring allocated from the same DMA pool, which would be contiguous to the segment inc_deq just stepped off of. inc_deq would eventually find the link TRB in that segment, and blindly move the dequeue pointer back to the top of the correct ring segment. The only reason the original code worked at all is because there was only one ring segment. With the ring expansion patches, the dequeue pointer would eventually wrap into place, but the dequeue segment would be out-of-sync. On the second TD after the dequeue pointer was moved to a link TRB, trb_in_td() would fail (because the dequeue pointer and dequeue segment were out-of-sync), and this message would appear: ERROR Transfer event TRB DMA ptr not part of current TD This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0 port: "Transfer event TRB DMA ptr not part of current TD", "rejecting I/O to offline device"), https://bugzilla.kernel.org/show_bug.cgi?id=43333 and possibly other general protection fault bugs as well. This patch should be backported to kernels as old as 2.6.31. A separate patch will be created for kernels older than 3.4, since inc_deq was modified in 3.4 and this patch will not apply. Signed-off-by: Sarah Sharp Tested-by: James Ettle Tested-by: Matthew Hall Signed-off-by: Greg Kroah-Hartman commit 0adf7a085fae52b18202a95722fc05d644fa7a42 Author: Sarah Sharp Date: Mon Jul 23 18:59:30 2012 +0300 xhci: Switch PPT ports to EHCI on shutdown. commit e95829f474f0db3a4d940cae1423783edd966027 upstream. The Intel desktop boards DH77EB and DH77DF have a hardware issue that can be worked around by BIOS. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS will work around this, but not all. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. The Intel Windows driver switches the ports back to EHCI, so change the Linux xHCI driver to do the same. Unfortunately, we can't tell the two effected boards apart from other working motherboards, because the vendors will change the DMI strings for the DH77EB and DH77DF boards to their own custom names. One example is Compulab's mini-desktop, the Intense-PC. Instead, key off the Panther Point xHCI host PCI vendor and device ID, and switch the ports over for all PPT xHCI hosts. The only impact this will have on non-effected boards is to add a couple hundred milliseconds delay on boot when the BIOS has to switch the ports over from EHCI to xHCI. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp Reported-by: Denis Turischev Tested-by: Denis Turischev Signed-off-by: Greg Kroah-Hartman commit ebd311e08218713c46f6894648084c84c48e220d Author: Sarah Sharp Date: Mon Jul 23 16:06:08 2012 -0700 xhci: Increase reset timeout for Renesas 720201 host. commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b upstream. The NEC/Renesas 720201 xHCI host controller does not complete its reset within 250 milliseconds. In fact, it takes about 9 seconds to reset the host controller, and 1 second for the host to be ready for doorbell rings. Extend the reset and CNR polling timeout to 10 seconds each. This patch should be backported to kernels as old as 2.6.31, that contain the commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff and HW initialization." Signed-off-by: Sarah Sharp Reported-by: Edwin Klein Mentink Signed-off-by: Greg Kroah-Hartman commit 40c293d87cc9a6e4b0b8e54cd8faabf9fa4bbb95 Author: Sarah Sharp Date: Mon Jul 2 13:36:23 2012 -0700 xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk. commit 5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9 upstream. Gary reports that with recent kernels, he notices more xHCI driver warnings: xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? We think his Etron xHCI host controller may have the same buggy behavior as the Fresco Logic xHCI host. When a short transfer is received, the host will mark the transfer as successfully completed when it should be marking it with a short completion. Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron host is discovered. Note that Gary has revision 1, but if Etron fixes this bug in future revisions, the quirk will have no effect. This patch should be backported to kernels as old as 2.6.36, that contain a backported version of commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk for Fresco Logic host." Signed-off-by: Sarah Sharp Reported-by: Gary E. Miller Signed-off-by: Greg Kroah-Hartman commit d8b868fd75825114c23bc28d63ee2b87033df609 Author: Theodore Ts'o Date: Fri Aug 17 08:54:52 2012 -0400 ext4: fix kernel BUG on large-scale rm -rf commands commit 89a4e48f8479f8145eca9698f39fe188c982212f upstream. Commit 968dee7722: "ext4: fix hole punch failure when depth is greater than 0" introduced a regression in v3.5.1/v3.6-rc1 which caused kernel crashes when users ran run "rm -rf" on large directory hierarchy on ext4 filesystems on RAID devices: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 Process rm (pid: 18229, threadinfo ffff8801276bc000, task ffff880123631710) Call Trace: [] ? __ext4_handle_dirty_metadata+0x83/0x110 [] ext4_ext_truncate+0x193/0x1d0 [] ? ext4_mark_inode_dirty+0x7f/0x1f0 [] ext4_truncate+0xf5/0x100 [] ext4_evict_inode+0x461/0x490 [] evict+0xa2/0x1a0 [] iput+0x103/0x1f0 [] do_unlinkat+0x154/0x1c0 [] ? sys_newfstatat+0x2a/0x40 [] sys_unlinkat+0x1b/0x50 [] system_call_fastpath+0x16/0x1b Code: 8b 4d 20 0f b7 41 02 48 8d 04 40 48 8d 04 81 49 89 45 18 0f b7 49 02 48 83 c1 01 49 89 4d 00 e9 ae f8 ff ff 0f 1f 00 49 8b 45 28 <48> 8b 40 28 49 89 45 20 e9 85 f8 ff ff 0f 1f 80 00 00 00 RIP [] ext4_ext_remove_space+0xa34/0xdf0 This could be reproduced as follows: The problem in commit 968dee7722 was that caused the variable 'i' to be left uninitialized if the truncate required more space than was available in the journal. This resulted in the function ext4_ext_truncate_extend_restart() returning -EAGAIN, which caused ext4_ext_remove_space() to restart the truncate operation after starting a new jbd2 handle. Reported-by: Maciej Żenczykowski Reported-by: Marti Raudsepp Tested-by: Fengguang Wu Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit e1b5abaa966c9baaaf90c975c4ca377dd7ab4483 Author: Theodore Ts'o Date: Thu Aug 16 11:59:04 2012 -0400 ext4: fix long mount times on very big file systems commit 0548bbb85337e532ca2ed697c3e9b227ff2ed4b4 upstream. Commit 8aeb00ff85a: "ext4: fix overhead calculation used by ext4_statfs()" introduced a O(n**2) calculation which makes very large file systems take forever to mount. Fix this with an optimization for non-bigalloc file systems. (For bigalloc file systems the overhead needs to be set in the the superblock.) Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 9a321bec4fb122cb2bd60febfd9dc71eed7ee5b2 Author: Theodore Ts'o Date: Sun Aug 5 23:28:16 2012 -0400 ext4: avoid kmemcheck complaint from reading uninitialized memory commit 7e731bc9a12339f344cddf82166b82633d99dd86 upstream. Commit 03179fe923 introduced a kmemcheck complaint in ext4_da_get_block_prep() because we save and restore ei->i_da_metadata_calc_last_lblock even though it is left uninitialized in the case where i_da_metadata_calc_len is zero. This doesn't hurt anything, but silencing the kmemcheck complaint makes it easier for people to find real bugs. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45631 (which is marked as a regression). Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 8b9f3861678e35b18cef66728d0fa896bbda65b6 Author: Theodore Ts'o Date: Sun Aug 5 19:04:57 2012 -0400 ext4: make sure the journal sb is written in ext4_clear_journal_err() commit d796c52ef0b71a988364f6109aeb63d79c5b116b upstream. After we transfer set the EXT4_ERROR_FS bit in the file system superblock, it's not enough to call jbd2_journal_clear_err() to clear the error indication from journal superblock --- we need to call jbd2_journal_update_sb_errno() as well. Otherwise, when the root file system is mounted read-only, the journal is replayed, and the error indicator is transferred to the superblock --- but the s_errno field in the jbd2 superblock is left set (since although we cleared it in memory, we never flushed it out to disk). This can end up confusing e2fsck. We should make e2fsck more robust in this case, but the kernel shouldn't be leaving things in this confused state, either. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 75a757189880a31759ed25c23229f085890cddb1 Author: Alex Deucher Date: Tue Jul 31 11:01:10 2012 -0400 drm/radeon: fix bank tiling parameters on evergreen commit c8d15edc17d836686d1f071e564800e1a2724fa6 upstream. Handle the 16 bank case. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e3d7a0f49568353837c51d0dbcd86cca8b7bc622 Author: Alex Deucher Date: Tue Jul 31 11:05:11 2012 -0400 drm/radeon: fix bank tiling parameters on cayman commit 5b23c9045a8b61352986270b2d109edf5085e113 upstream. Handle the 16 bank case. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 844bebfd9d09f92cdf4fac108e5f0d38cd389fff Author: Alex Deucher Date: Mon Aug 6 10:03:59 2012 -0400 drm/radeon: add some new SI pci ids commit 2f292004dd1fb005788dc0a9cdd5559812ed866e upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3407b51859d0e65ed66ccb0080c495a1f03cda6a Author: Jerome Glisse Date: Fri Jul 27 16:32:24 2012 -0400 drm/radeon: do not reenable crtc after moving vram start address commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream. It seems we can not update the crtc scanout address. After disabling crtc, update to base address do not take effect after crtc being reenable leading to at least frame being scanout from the old crtc base address. Disabling crtc display request lead to same behavior. So after changing the vram address if we don't keep crtc disabled we will have the GPU trying to read some random system memory address with some iommu this will broke the crtc engine and will lead to broken display and iommu error message. So to avoid this, disable crtc. For flicker less boot we will need to avoid moving the vram start address. This patch should also fix : https://bugs.freedesktop.org/show_bug.cgi?id=42373 Signed-off-by: Jerome Glisse Signed-off-by: Greg Kroah-Hartman commit b248464f145eee69818dff9945096745988aa3ce Author: Alex Deucher Date: Thu Jul 26 13:38:52 2012 -0400 drm/radeon: properly handle crtc powergating commit 6c0ae2ab85fc4a95cae82047a7db1f688a7737ab upstream. Need to make sure the crtc is gated on before modesetting. Explicitly gate the crtc on in prepare() and set a flag so that the dpms functions don't gate it off during mode set. Noticed by sylware on IRC. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit acafb0231aeeb8648e1f2789e6dd88ea5878f61c Author: Daniel Vetter Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 upstream. eDP is tons of fun. It turns out that at least the new MacBook Air 5,1 model absolutely doesn't like the new force vdd dance we've introduced in commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel But that patch also tried to fix some neat edp sequence issue with the force_vdd timings. Closer inspection reveals that we've raised force_vdd only to do the aux channel communication dp_sink_dpms. If we move the edp_panel_off below that, we don't need any force_vdd for the disable sequence, which makes the Air happy. Unfortunately the reporter of the original bug that the above commit fixed is travelling, so we can't test whether this regresses things. But my theory is that since we don't check for any power-off -> force_vdd-on delays in edp_panel_vdd_on, this was the actual root-cause of this failure. With that force_vdd dance completely eliminated, I'm hopeful the original bug stays fixed, too. For reference the old bug, which hopefully doesn't get broken by this: https://bugzilla.kernel.org/show_bug.cgi?id=43163 In any case, regression fixers win over plain bugfixes, so this needs to go in asap. v2: The crucial pieces seems to be to clear the force_vdd flag uncoditionally, too, in edp_panel_off. Looks like this is left behind by the firmware somehow. v3: The Apple firmware seems to switch off the panel on it's own, hence we still need to keep force_vdd on, but properly clear it when switching the panel off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671 Tested-by: Roberto Romer Tested-by: Daniel Wagner Tested-by: Keith Packard Cc: Keith Packard Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit c02a29650148f353b0fc86b7eba3f99ecafd23dd Author: Daniel Vetter Date: Fri Aug 10 11:10:20 2012 +0200 drm/i915: ignore eDP bpc settings from vbt commit 4344b813f105a19f793f1fd93ad775b784648b95 upstream. This has originally been introduced to not oversubscribe the dp links in commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18 Author: Zhenyu Wang Date: Tue Jan 12 05:38:31 2010 +0800 drm/i915: fix pixel color depth setting on eDP Since then we've fixed up the dp link bandwidth calculation code and should now automatically fall back to 6bpc dithering. So this is unnecessary. Furthermore it seems to break the new MacbookPro with retina display, hence let's just rip this out. Reported-by: Benoit Gschwind Cc: Benoit Gschwind Cc: Francois Rigaut Tested-by: Benoit Gschwind Tested-by: Bernhard Froemel Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman -- Testing feedback highgly welcome, and thanks for Benoit for finding out that the bpc computations are busted. -Daniel commit 57ecc93ce680b1ace1f9e79d588dabe32353202c Author: Daniel Vetter Date: Tue Aug 7 09:54:14 2012 +0200 drm/i915: correctly order the ring init sequence commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. We may only start to set up the new register values after having confirmed that the ring is truely off. Otherwise the hw might lose the newly written register values. This is caught later on in the init sequence, when we check whether the register writes have stuck. Reviewed-by: Jani Nikula Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Tested-by: Yang Guang Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1a475b7af63febbef784d0d2ccb6bdbb119d0245 Author: Christoph Bumiller Date: Thu Jul 26 20:53:19 2012 +0200 drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate commit af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 upstream. Signed-off-by: Christoph Bumiller Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 6700eb4d0af877ed46ae2e5d93d6801db7f3b58d Author: Jesse Barnes Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs commit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream. High frequency link configurations have the potential to cause trouble with long and/or cheap cables, so prefer slow and wide configurations instead. This patch has the potential to cause trouble for eDP configurations that lie about available lanes, so if we run into that we can make it conditional on eDP. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801 Tested-by: peter@colberg.org Signed-off-by: Jesse Barnes Signed-off-by: Daniel Vetter Cc: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman commit b9247be526627cda981a6901c8db66f03ecb3ea8 Author: Stefano Stabellini Date: Wed May 23 18:57:20 2012 +0100 xen: mark local pages as FOREIGN in the m2p_override commit b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f upstream. When the frontend and the backend reside on the same domain, even if we add pages to the m2p_override, these pages will never be returned by mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will always fail, so the pfn of the frontend will be returned instead (resulting in a deadlock because the frontend pages are already locked). INFO: task qemu-system-i38:1085 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. qemu-system-i38 D ffff8800cfc137c0 0 1085 1 0x00000000 ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0 ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0 ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0 Call Trace: [] ? __lock_page+0x70/0x70 [] schedule+0x29/0x70 [] io_schedule+0x60/0x80 [] sleep_on_page+0xe/0x20 [] __wait_on_bit_lock+0x5a/0xc0 [] __lock_page+0x67/0x70 [] ? autoremove_wake_function+0x40/0x40 [] ? bio_add_page+0x36/0x40 [] set_page_dirty_lock+0x52/0x60 [] bio_set_pages_dirty+0x51/0x70 [] do_blockdev_direct_IO+0xb24/0xeb0 [] ? ext3_get_blocks_handle+0xe00/0xe00 [] __blockdev_direct_IO+0x55/0x60 [] ? ext3_get_blocks_handle+0xe00/0xe00 [] ext3_direct_IO+0xf8/0x390 [] ? ext3_get_blocks_handle+0xe00/0xe00 [] ? xen_mc_flush+0xb0/0x1b0 [] generic_file_aio_read+0x737/0x780 [] ? gnttab_map_refs+0x15b/0x1e0 [] ? find_get_pages+0x150/0x150 [] aio_rw_vect_retry+0x7c/0x1d0 [] ? lookup_ioctx+0x90/0x90 [] aio_run_iocb+0x66/0x1a0 [] do_io_submit+0x708/0xb90 [] sys_io_submit+0x10/0x20 [] system_call_fastpath+0x16/0x1b The explanation is in the comment within the code: We need to do this because the pages shared by the frontend (xen-blkfront) can be already locked (lock_page, called by do_read_cache_page); when the userspace backend tries to use them with direct_IO, mfn_to_pfn returns the pfn of the frontend, so do_blockdev_direct_IO is going to try to lock the same pages again resulting in a deadlock. A simplified call graph looks like this: pygrub QEMU ----------------------------------------------- do_read_cache_page io_submit | | lock_page ext3_direct_IO | bio_add_page | lock_page Internally the xen-blkback uses m2p_add_override to swizzle (temporarily) a 'struct page' to have a different MFN (so that it can point to another guest). It also can easily find out whether another pfn corresponding to the mfn exists in the m2p, and can set the FOREIGN bit in the p2m, making sure that mfn_to_pfn returns the pfn of the backend. This allows the backend to perform direct_IO on these pages, but as a side effect prevents the frontend from using get_user_pages_fast on them while they are being shared with the backend. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 90f9cb724d38bf4ac4e355d19b1ee697dceea021 Author: Zach Brown Date: Tue Jul 24 12:10:11 2012 -0700 fuse: verify all ioctl retry iov elements commit fb6ccff667712c46b4501b920ea73a326e49626a upstream. Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that the total iovec from the client doesn't overflow iov_length() but it only checked the first element. The iovec could still overflow by starting with a small element. The obvious fix is to check all the elements. The overflow case doesn't look dangerous to the kernel as the copy is limited by the length after the overflow. This fix restores the intention of returning an error instead of successfully copying less than the iovec represented. I found this by code inspection. I built it but don't have a test case. I'm cc:ing stable because the initial commit did as well. Signed-off-by: Zach Brown Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 9ea2c02bafe276e97b592a046ac733610a6d57fd Author: Fabio Estevam Date: Tue Jul 3 15:33:29 2012 -0300 dma: imx-dma: Fix kernel crash due to missing clock conversion commit a2367db2ec5e7fc6fe93e221e0fcdee81b053daf upstream. With the new i.MX clock infrastructure we need to request the dma clocks seperately: ahb and ipg clocks. This fixes the following kernel crash and make audio to be functional again: root@freescale /home$ aplay audio48k16S.wav Playing WAVE 'audio48k16S.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c7b74000 [00000000] *pgd=a7bb5831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: CPU: 0 Not tainted (3.5.0-rc5-next-20120702-00007-g3028b64 #1128) PC is at snd_dmaengine_pcm_get_chan+0x8/0x10 LR is at snd_imx_pcm_hw_params+0x18/0xdc pc : [] lr : [] psr: a0000013 sp : c7b45e30 ip : ffffffff fp : c7ae58e0 r10: 00000000 r9 : c7ae981c r8 : c7b88800 r7 : c7ae5a60 r6 : c7ae5b20 r5 : c7ae9810 r4 : c7afa060 r3 : 00000000 r2 : 00000001 r1 : c7b88800 r0 : c7afa060 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: a7b74000 DAC: 00000015 Process aplay (pid: 701, stack limit = 0xc7b44270) Stack: (0xc7b45e30 to 0xc7b46000) 5e20: 00100000 00000029 c7b88800 c02db870 5e40: c7ae5a60 c02d4594 00000010 01ae5a60 c7ae5a60 c7ae9810 c7ae9810 c7afa060 5e60: c7ae5b20 c7ae5a60 c7b88800 c02e3ef0 c02e3e08 c7b1e400 c7afa060 c7b88800 5e80: 00000000 c0014da8 c7b44000 00000000 bec566ac c02cd400 c7afa060 c7afa060 5ea0: bec56800 c7b88800 c0014da8 c02cdd7c c04ee710 c04ee7b8 00000003 c005fc74 5ec0: 00000000 7fffffff c7b45f00 c7afa060 c7b67420 c7ba3070 00000004 c0014da8 5ee0: c7b44000 00000000 bec566ac c02ced88 c04e95f8 b6f5ab04 c7b45fb0 0145a468 5f00: 0145a600 bec566bc bec56800 c7b67420 c7ba3070 c00d499c c7b45f18 c7b45f18 5f20: 0000001a 00000004 00000001 c7b44000 c0527f40 00000009 00000008 00000000 5f40: c7b44000 c002c9ec 00000001 c04f0ab0 c04ebec0 00000101 00000000 0000000a 5f60: 60000093 c7b67420 bec56800 c25c4111 00000004 c0014da8 c7b44000 00000000 5f80: bec566ac c00d4f38 b6ffb658 00000000 c0522d80 0145a468 b6fd5000 0145a418 5fa0: 00000036 c0014c00 0145a468 b6fd5000 00000004 c25c4111 bec56800 00020001 5fc0: 0145a468 b6fd5000 0145a418 00000036 0145a468 0145a600 bec566bc bec566ac 5fe0: 0145a468 bec56388 b6f65ce4 b6dcebec 20000010 00000004 00000000 00000000 [] (snd_dmaengine_pcm_get_chan+0x8/0x10) from [] (snd_imx_pcm_hw_params+0x18/0xdc) [] (snd_imx_pcm_hw_params+0x18/0xdc) from [] (soc_pcm_hw_params+0xe8/0x1f0) [] (soc_pcm_hw_params+0xe8/0x1f0) from [] (snd_pcm_hw_params+0x124/0x474) [] (snd_pcm_hw_params+0x124/0x474) from [] (snd_pcm_common_ioctl1+0x4b4/0xf74) [] (snd_pcm_common_ioctl1+0x4b4/0xf74) from [] (snd_pcm_playback_ioctl1+0x30/0x510) [] (snd_pcm_playback_ioctl1+0x30/0x510) from [] (do_vfs_ioctl+0x80/0x5e4) [] (do_vfs_ioctl+0x80/0x5e4) from [] (sys_ioctl+0x38/0x60) [] (sys_ioctl+0x38/0x60) from [] (ret_fast_syscall+0x0/0x2c) Code: e593000c e12fff1e e59030a0 e59330bc (e5930000) ---[ end trace fa518c8ba3a74e97 ]-- Reported-by: Javier Martin Signed-off-by: Fabio Estevam Acked-by: Sascha Hauer Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit a87531935d7afc5429944c89511c8acbdf467111 Author: Heiko Carstens Date: Wed Aug 8 09:32:20 2012 +0200 s390/compat: fix mmap compat system calls commit e85871218513c54f7dfdb6009043cb638f2fecbe upstream. The native 31 bit and the compat behaviour for the mmap system calls differ: In native 31 bit mode the passed in address for the mmap system call will be unmodified passed to sys_mmap_pgoff(). In compat mode however the passed in address will be modified with compat_ptr() which masks out the most significant bit. The result is that in native 31 bit mode each mmap request (with MAP_FIXED) will fail where the most significat bit is set, while in compat mode it may succeed. This odd behaviour was introduced with d3815898 "[S390] mmap: add missing compat_ptr conversion to both mmap compat syscalls". To restore a consistent behaviour accross native and compat mode this patch functionally reverts the above mentioned commit. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit bdac2ea27e0237b3c76b1d8a9d7f73a3d6b3ad81 Author: Heiko Carstens Date: Tue Aug 7 09:48:13 2012 +0200 s390/compat: fix compat wrappers for process_vm system calls commit 82aabdb6f1eb61e0034ec23901480f5dd23db7c4 upstream. The compat wrappers incorrectly called the non compat versions of the system process_vm system calls. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman