commit 048b6fe6dccb105512147eb47accbb1431b4e54b Author: Greg Kroah-Hartman Date: Thu Feb 28 07:01:22 2013 -0800 Linux 3.4.34 commit 616dd23b2e475e61a2974eb112cc88d3cb94d47f Author: Josh Boyer Date: Thu Feb 14 09:39:09 2013 -0500 USB: usb-storage: unusual_devs update for Super TOP SATA bridge commit 18e03310b5caa6d11c1a8c61b982c37047693fba upstream. The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011 Reported-by: Carsten S. Tested-by: Carsten S. Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman commit 12b64a247ef45dcd865a98d63bbae7355e51633b Author: fangxiaozhi Date: Thu Feb 7 15:32:07 2013 +0800 USB: storage: properly handle the endian issues of idProduct commit cd060956c5e97931c3909e4a808508469c0bb9f6 upstream. 1. The idProduct is little endian, so make sure its value to be compatible with the current CPU. Make no break on big endian processors. Signed-off-by: fangxiaozhi Signed-off-by: Greg Kroah-Hartman commit 30361160bc12da86b9ce4c7c60bd68ff930eda76 Author: Roger Quadros Date: Thu Feb 14 17:08:09 2013 +0200 USB: ehci-omap: Fix autoloading of module commit 04753523266629b1cd0518091da1658755787198 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by: Roger Quadros Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 9c5879c55ecc7c5b0e54809e011561bde4926d14 Author: Bjørn Mork Date: Wed Feb 13 23:41:34 2013 +0100 USB: option: add Huawei "ACM" devices using protocol = vendor commit 1f3f687722fd9b29a0c2a85b4844e3b2a3585c63 upstream. The USB device descriptor of one identity presented by a few Huawei morphing devices have serial functions with class codes 02/02/ff, indicating CDC ACM with a vendor specific protocol. This combination is often used for MSFT RNDIS functions, and the CDC ACM class driver will therefore ignore such functions. The CDC ACM class driver cannot support functions with only 2 endpoints. The underlying serial functions of these modems are also believed to be the same as for alternate device identities already supported by the option driver. Letting the same driver handle these functions independently of the current identity ensures consistent handling and user experience. There is no need to blacklist these devices in the rndis_host driver. Huawei serial functions will either have only 2 endpoints or a CDC ACM functional descriptor with bmCapabilities != 0, making them correctly ignored as "non RNDIS" by that driver. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 0457c05d7f770e5b1581ecc1357b4c2b7b336808 Author: Bjørn Mork Date: Tue Feb 12 13:42:24 2013 +0100 USB: option: add Yota / Megafon M100-1 4g modem commit cd565279e51bedee1b2988e84f9b3bef485adeb6 upstream. Interface layout: 00 CD-ROM 01 debug COM port 02 AP control port 03 modem 04 usb-ethernet Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0408 ProdID=ea42 Rev= 0.00 S: Manufacturer=Qualcomm, Incorporated S: Product=Qualcomm CDMA Technologies MSM S: SerialNumber=353568051xxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 78b42978accff2b4ccc45f399c47841d697e166f Author: Bjørn Mork Date: Wed Jan 23 10:44:36 2013 +0100 USB: option: add and update Alcatel modems commit f8f0302bbcbd1b14655bef29f6996a2152be559d upstream. Adding three currently unsupported modems based on information from .inf driver files: Diag VID_1BBB&PID_0052&MI_00 AGPS VID_1BBB&PID_0052&MI_01 VOICE VID_1BBB&PID_0052&MI_02 AT VID_1BBB&PID_0052&MI_03 Modem VID_1BBB&PID_0052&MI_05 wwan VID_1BBB&PID_0052&MI_06 Diag VID_1BBB&PID_00B6&MI_00 AT VID_1BBB&PID_00B6&MI_01 Modem VID_1BBB&PID_00B6&MI_02 wwan VID_1BBB&PID_00B6&MI_03 Diag VID_1BBB&PID_00B7&MI_00 AGPS VID_1BBB&PID_00B7&MI_01 VOICE VID_1BBB&PID_00B7&MI_02 AT VID_1BBB&PID_00B7&MI_03 Modem VID_1BBB&PID_00B7&MI_04 wwan VID_1BBB&PID_00B7&MI_05 Updating the blacklist info for the X060S_X200 and X220_X500D, reserving interfaces for a wwan driver, based on wwan VID_1BBB&PID_0000&MI_04 wwan VID_1BBB&PID_0017&MI_06 Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 62fb8fe993f3a9060d75bc3d8b6eb9d153d8238c Author: Maciej Sosnowski Date: Wed May 23 17:27:07 2012 +0200 dca: check against empty dca_domains list before unregister provider commit c419fcfd071cf34ba00f9f65282583772d2655e7 upstream. When providers get blocked unregister_dca_providers() is called ending up with dca_providers and dca_domain lists emptied. Dca should be prevented from trying to unregister any provider if dca_domain list is found empty. Reported-by: Jiang Liu Tested-by: Gaohuai Han Signed-off-by: Maciej Sosnowski Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit b9bf60ac3e3779d4ffa03daceebf59df7b46c224 Author: Cong Wang Date: Thu Feb 21 23:32:27 2013 +0000 vlan: adjust vlan_set_encap_proto() for its callers [ Upstream commit da8c87241c26aac81a64c7e4d21d438a33018f4e ] There are two places to call vlan_set_encap_proto(): vlan_untag() and __pop_vlan_tci(). vlan_untag() assumes skb->data points after mac addr, otherwise the following code vhdr = (struct vlan_hdr *) skb->data; vlan_tci = ntohs(vhdr->h_vlan_TCI); __vlan_hwaccel_put_tag(skb, vlan_tci); skb_pull_rcsum(skb, VLAN_HLEN); won't be correct. But __pop_vlan_tci() assumes points _before_ mac addr. In vlan_set_encap_proto(), it looks for some magic L2 value after mac addr: rawp = skb->data; if (*(unsigned short *) rawp == 0xFFFF) ... Therefore __pop_vlan_tci() is obviously wrong. A quick fix is avoiding using skb->data in vlan_set_encap_proto(), use 'vhdr+1' is always correct in both cases. Signed-off-by: Cong Wang Cc: David S. Miller Cc: Jesse Gross Acked-by: Jesse Gross Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8c2223fc19032e7b8761e46c15e1ed167a252285 Author: Mathias Krause Date: Sat Feb 23 01:13:47 2013 +0000 sock_diag: Fix out-of-bounds access to sock_diag_handlers[] [ Upstream commit 6e601a53566d84e1ffd25e7b6fe0b6894ffd79c0 ] Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY with a family greater or equal then AF_MAX -- the array size of sock_diag_handlers[]. The current code does not test for this condition therefore is vulnerable to an out-of-bound access opening doors for a privilege escalation. Signed-off-by: Mathias Krause Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e5a096aa0aeb1fc8ad8b3d6bd70d322a0d65edc4 Author: Eric Dumazet Date: Thu Feb 21 12:18:52 2013 +0000 ipv6: use a stronger hash for tcp [ Upstream commit 08dcdbf6a7b9d14c2302c5bd0c5390ddf122f664 ] It looks like its possible to open thousands of TCP IPv6 sessions on a server, all landing in a single slot of TCP hash table. Incoming packets have to lookup sockets in a very long list. We should hash all bits from foreign IPv6 addresses, using a salt and hash mix, not a simple XOR. inet6_ehashfn() can also separately use the ports, instead of xoring them. Reported-by: Neal Cardwell Signed-off-by: Eric Dumazet Cc: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 785e5dce256ea5bdf4871af13f9908b74264b515 Author: Li Wei Date: Thu Feb 21 00:09:54 2013 +0000 ipv4: fix a bug in ping_err(). [ Upstream commit b531ed61a2a2a77eeb2f7c88b49aa5ec7d9880d8 ] We should get 'type' and 'code' from the outer ICMP header. Signed-off-by: Li Wei Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1e6b5fb5ce92028f6c87864712ed7290446a4c11 Author: Ying Xue Date: Fri Feb 15 22:28:25 2013 +0000 net: fix a compile error when SOCK_REFCNT_DEBUG is enabled [ Upstream commit dec34fb0f5b7873de45132a84a3af29e61084a6b ] When SOCK_REFCNT_DEBUG is enabled, below build error is met: kernel/sysctl_binary.o: In function `sk_refcnt_debug_release': include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release' kernel/sysctl.o:include/net/sock.h:1025: first defined here kernel/audit.o: In function `sk_refcnt_debug_release': include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release' kernel/sysctl.o:include/net/sock.h:1025: first defined here make[1]: *** [kernel/built-in.o] Error 1 make: *** [kernel] Error 2 So we decide to make sk_refcnt_debug_release static to eliminate the error. Signed-off-by: Ying Xue Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 29b3bb0be43fea0a49e5235894e1dcbc0ac299dc Author: David Vrabel Date: Thu Feb 14 03:18:58 2013 +0000 xen-netback: cancel the credit timer when taking the vif down [ Upstream commit 3e55f8b306cf305832a4ac78aa82e1b40e818ece ] If the credit timer is left armed after calling xen_netbk_remove_xenvif(), then it may fire and attempt to schedule the vif which will then oops as vif->netbk == NULL. This may happen both in the fatal error path and during normal disconnection from the front end. The sequencing during shutdown is critical to ensure that: a) vif->netbk doesn't become unexpectedly NULL; and b) the net device/vif is not freed. 1. Mark as unschedulable (netif_carrier_off()). 2. Synchronously cancel the timer. 3. Remove the vif from the schedule list. 4. Remove it from it netback thread group. 5. Wait for vif->refcnt to become 0. Signed-off-by: David Vrabel Acked-by: Ian Campbell Reported-by: Christopher S. Aker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 320c1509197bce83d2ebb45d4cc5f9b4d91c05dc Author: David Vrabel Date: Thu Feb 14 03:18:57 2013 +0000 xen-netback: correctly return errors from netbk_count_requests() [ Upstream commit 35876b5ffc154c357476b2c3bdab10feaf4bd8f0 ] netbk_count_requests() could detect an error, call netbk_fatal_tx_error() but return 0. The vif may then be used afterwards (e.g., in a call to netbk_tx_error(). Since netbk_fatal_tx_error() could set vif->refcnt to 1, the vif may be freed immediately after the call to netbk_fatal_tx_error() (e.g., if the vif is also removed). Netback thread Xenwatch thread ------------------------------------------- netbk_fatal_tx_err() netback_remove() xenvif_disconnect() ... free_netdev() netbk_tx_err() Oops! Signed-off-by: Wei Liu Signed-off-by: Jan Beulich Signed-off-by: David Vrabel Reported-by: Christopher S. Aker Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b5428e471b91192a2438d04c1d2ff2b3d4708366 Author: Eric Dumazet Date: Tue Feb 12 06:16:53 2013 +0000 net: fix infinite loop in __skb_recv_datagram() [ Upstream commit 77c1090f94d1b0b5186fb13a1b71b47b1343f87f ] Tommi was fuzzing with trinity and reported the following problem : commit 3f518bf745 (datagram: Add offset argument to __skb_recv_datagram) missed that a raw socket receive queue can contain skbs with no payload. We can loop in __skb_recv_datagram() with MSG_PEEK mode, because wait_for_packet() is not prepared to skip these skbs. [ 83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0, t=26002 jiffies, g=27673, c=27672, q=75) [ 83.541011] INFO: Stall ended before state dump start [ 108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847] ... [ 108.067010] Call Trace: [ 108.067010] [] __skb_recv_datagram+0x1a3/0x3b0 [ 108.067010] [] skb_recv_datagram+0x2d/0x30 [ 108.067010] [] rawv6_recvmsg+0xad/0x240 [ 108.067010] [] sock_common_recvmsg+0x34/0x50 [ 108.067010] [] sock_recvmsg+0xbc/0xf0 [ 108.067010] [] sys_recvfrom+0xde/0x150 [ 108.067010] [] system_call_fastpath+0x16/0x1b Reported-by: Tommi Rantala Tested-by: Tommi Rantala Signed-off-by: Eric Dumazet Cc: Pavel Emelyanov Acked-by: Pavel Emelyanov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6e95f970d1cb6801b5f26d2c167fb1e0ad6c5dba Author: Stephen Hemminger Date: Mon Feb 11 08:22:22 2013 +0000 bridge: set priority of STP packets [ Upstream commit 547b4e718115eea74087e28d7fa70aec619200db ] Spanning Tree Protocol packets should have always been marked as control packets, this causes them to get queued in the high prirority FIFO. As Radia Perlman mentioned in her LCA talk, STP dies if bridge gets overloaded and can't communicate. This is a long-standing bug back to the first versions of Linux bridge. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a9115fba99247ad51211beb3ffd23b6553c80ee9 Author: David Herrmann Date: Mon Feb 18 01:47:15 2013 +0100 HID: wiimote: fix nunchuck button parser commit 89bdd0c6f38ccf0de43d5a36ede384a730f3394e upstream. The buttons of the Wii Remote Nunchuck extension are actually active low. Fix the parser to forward the inverted values. The comment in the function always said "0 == pressed" but the implementation was wrong from the beginning. Reported-by: Victor Quicksilver Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6a924a76039689fd260ee311b85fb2202bcd4910 Author: Shawn Guo Date: Tue Jan 15 23:30:27 2013 +0800 mmc: sdhci-esdhc-imx: fix host version read commit ef4d0888bb7e1b963880f086575081c3d39cad2d upstream. When commit 95a2482 (mmc: sdhci-esdhc-imx: add basic imx6q usdhc support) works around host version issue on imx6q, it gets the register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc. Thus, the controller version on these SoCs is wrongly identified as v1 while it's actually v2. Add the address fixup back and take a different approach to correct imx6q host version, so that the host version read gets back to work for all SoCs. Signed-off-by: Shawn Guo Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit f515e1d59602f8eafaad39b6842bd823ad34654e Author: Takashi Iwai Date: Fri Jan 25 10:28:18 2013 +1000 fb: Yet another band-aid for fixing lockdep mess commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream. I've still got lockdep warnings even after Alan's patch, and it seems that yet more band aids are required to paper over similar paths for unbind_con_driver() and unregister_con_driver(). After this hack, lockdep warnings are finally gone. Signed-off-by: Takashi Iwai Cc: Alan Cox Cc: Florian Tobias Schandinat Cc: Jiri Kosina Tested-by: Sedat Dilek Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c30b55c385288be48f7accd16a6929ad4d983311 Author: Alan Cox Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeover commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment] [akpm@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox Cc: Florian Tobias Schandinat Cc: Stephen Rothwell Cc: Jiri Kosina Tested-by: Sedat Dilek Reviewed-by: Daniel Vetter Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 62a3dcc78d04dcd84276eaa7a40dec1066054532 Author: Dave Airlie Date: Thu Jan 24 16:12:41 2013 +1000 fbcon: don't lose the console font across generic->chip driver switch commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream. If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code is doing the right thing, it frees the font because otherwise it would leak memory. However we can assume that if you are removing the generic firmware driver (vesa/efi/offb), that a new driver *should* be loading soon after, so we effectively leak the font. However the old code left a dangling pointer in vc->vc_font.data and we can now reuse that dangling pointer to load the font into the new driver, now that we aren't freeing it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340 Signed-off-by: Dave Airlie Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman commit 0bbdba111a75875890290150333c07f2d79b160a Author: Anatolij Gustschin Date: Thu Jan 17 21:28:37 2013 +0100 drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp commit 5d3cc311a76073f6e0a27c0752f7e41f69e95ea7 upstream. Framebuffer colors for 24 and 16 bpp are currently wrong. The order of the color component arguments in the MAKE_PF() is not natural and causes some confusion. The generated pixel format values for 24 and 16 bpp depths do not much the values in the comments. Fix the macro arguments to be in the natural RGB order and adjust the arguments for all depths to generate correct pixel format values (equal to the values mentioned in the comments). Signed-off-by: Anatolij Gustschin Cc: Timur Tabi Acked-by: Timur Tabi Signed-off-by: Greg Kroah-Hartman commit aa3fc3566478493f635d265731d81a3defcef98d Author: Jean Delvare Date: Sun Dec 16 22:00:50 2012 +0100 pcmcia/vrc4171: Add missing spinlock init commit 811af9723859884f2f771f3174f3ddedab7c53b5 upstream. It doesn't seem this spinlock was properly initialized. This bug was introduced by commit 7a410e8d4d97457c8c381e2de9cdc7bd3306badc. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 49e8ae95b16fbc66b630b50ad3a18273b9342a06 Author: John David Anglin Date: Mon Jan 14 19:45:00 2013 -0500 Purge existing TLB entries in set_pte_at and ptep_set_wrprotect commit 7139bc1579901b53db7e898789e916ee2fb52d78 upstream. This patch goes a long way toward fixing the minifail bug, and it  significantly improves the stability of SMP machines such as the rp3440.  When write  protecting a page for COW, we need to purge the existing translation.  Otherwise, the COW break doesn't occur as expected because the TLB may still have a stale entry which allows writes. [jejb: fix up checkpatch errors] Signed-off-by: John David Anglin Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 25c3a0840c99270041487907b6365cb5bfc8a03f Author: Phileas Fogg Date: Sat Feb 23 00:32:19 2013 +0100 powerpc/kexec: Disable hard IRQ before kexec commit 8520e443aa56cc157b015205ea53e7b9fc831291 upstream. Disable hard IRQ before kexec a new kernel image. Not doing it can result in corrupted data in the memory segments reserved for the new kernel. Signed-off-by: Phileas Fogg Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 27c303244ef8049be6fd8088230c7f5e02a522b3 Author: Joonsoo Kim Date: Sat Feb 9 05:52:45 2013 +0100 ARM: 7643/1: sched: correct update_sched_clock() commit 7c4e9ced424be4d36df6a3e3825763e97ee97607 upstream. If we want load epoch_cyc and epoch_ns atomically, we should update epoch_cyc_copy first of all. This notify reader that updating is in progress. If we update epoch_cyc first like as current implementation, there is subtle error case. Look at the below example. cyc = 9 ns = 900 cyc_copy = 9 == CASE 1 == write cyc = 10 read cyc = 10 read ns = 900 write ns = 1000 write cyc_copy = 10 read cyc_copy = 10 output = (10, 900) == CASE 2 == read cyc = 9 write cyc = 10 write ns = 1000 read ns = 1000 read cyc_copy = 9 write cyc_copy = 10 output = (9, 1000) If atomic read is ensured, output should be (9, 900) or (10, 1000). But, output in example case are not. So, change updating sequence in order to correct this problem. Signed-off-by: Joonsoo Kim Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit cae53e2a9a03e53152fdd331067923f7d65fc72e Author: Arnd Bergmann Date: Tue Jan 8 21:58:31 2013 +0000 ARM: samsung: fix assembly syntax for new gas commit 2815774bb38445006074e16251b9ef5123bdc616 upstream. Recent assembler versions complain about extraneous whitespace inside [] brackets. This fixes all of these instances for the samsung platforms. We should backport this to all kernels that might need to be built with new binutils. arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]' arch/arm/kernel/debug.S: Assembler messages: arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages: arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]' arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' Signed-off-by: Arnd Bergmann Acked-by: Kukjin Kim Cc: Ben Dooks Signed-off-by: Greg Kroah-Hartman commit 76753d39bf46abf7e37df89e2258bef933bb2207 Author: Igor Grinberg Date: Sun Jan 13 13:49:47 2013 +0200 ARM: PXA3xx: program the CSMSADRCFG register commit d107a204154ddd79339203c2deeb7433f0cf6777 upstream. The Chip Select Configuration Register must be programmed to 0x2 in order to achieve the correct behavior of the Static Memory Controller. Without this patch devices wired to DFI and accessed through SMC cannot be accessed after resume from S2. Do not rely on the boot loader to program the CSMSADRCFG register by programming it in the kernel smemc module. Signed-off-by: Igor Grinberg Acked-by: Eric Miao Signed-off-by: Haojian Zhuang Signed-off-by: Greg Kroah-Hartman commit 03e578b9213094935c692d5728229cc8c0df0fd6 Author: Chris Rattray Date: Fri Feb 1 15:51:41 2013 +0000 ASoC: wm2200: correct IN2L and IN3L digital mute commit 0d2b6422529a26ac4dee06196524ba9da70cf735 upstream. Signed-off-by: Chris Rattray Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4aee4099c7309d0610cf857d9d02d27ebfeb1b95 Author: Malcolm Priestley Date: Wed Jan 30 20:07:29 2013 +0000 staging: vt6656: Fix URB submitted while active warning. commit ae5943de8c8c4438cbac5cda599ff0b88c224468 upstream. This error happens because PIPEnsControlOut and PIPEnsControlIn unlock the spin lock for delay, letting in another thread. The patch moves the current MP_SET_FLAG to before filling of sUsbCtlRequest for pControlURB and clears it in event of failing. Any thread calling either function while fMP_CONTROL_READS or fMP_CONTROL_WRITES flags set will return STATUS_FAILURE. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit 59959c9505e28cc7b9ead416cb064b4e56ba7dd5 Author: Ian Abbott Date: Mon Jan 28 16:14:31 2013 +0000 staging: comedi: disallow COMEDI_DEVCONFIG on non-board minors commit 754ab5c0e55dd118273ca2c217c4d95e9fbc8259 upstream. Comedi has two sorts of minor devices: (a) normal board minor devices in the range 0 to COMEDI_NUM_BOARD_MINORS-1 inclusive; and (b) special subdevice minor devices in the range COMEDI_NUM_BOARD_MINORS upwards that are used to open the same underlying comedi device as the normal board minor devices, but with non-default read and write subdevices for asynchronous commands. The special subdevice minor devices get created when a board supporting asynchronous commands is attached to a normal board minor device, and destroyed when the board is detached from the normal board minor device. One way to attach or detach a board is by using the COMEDI_DEVCONFIG ioctl. This should only be used on normal board minors as the special subdevice minors are too ephemeral. In particular, the change introduced in commit 7d3135af399e92cf4c9bbc5f86b6c140aab3b88c ("staging: comedi: prevent auto-unconfig of manually configured devices") breaks horribly for special subdevice minor devices. Since there's no legitimate use for the COMEDI_DEVCONFIG ioctl on a special subdevice minor device node, disallow it and return -ENOTTY. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit a143ae690fbf24c2473d5c7c42875c29e150bd13 Author: Patrik Jakobsson Date: Wed Feb 13 22:20:22 2013 +0100 drm/i915: Set i9xx sdvo clock limits according to specifications commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2 upstream. The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. Signed-off-by: Patrik Jakobsson Reviewed-by: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359 Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 6bdf87562cb048e3e9a76d18e440794830647657 Author: Mika Kuoppala Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe commit 24a1f16de97c4cf0029d9acd04be06db32208726 upstream. If encoder is switched off by BIOS, but the panel fitter is left on, we never try to turn off the panel fitter and leave it still attached to the pipe - which can cause blurry output elsewhere. Based on work by Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867 Signed-off-by: Mika Kuoppala Tested-by: Andreas Sturmlechner [danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny comment.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit df87bd32f94547ecaa586052a6edeb653294a5b4 Author: Daniel Vetter Date: Mon Jan 21 19:48:59 2013 +0100 intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets commit 210561ffd72d00eccf12c0131b8024d5436bae95 upstream. We already have the quirk entry for the mobile platform, but also reports on some desktop versions. So be paranoid and set it everywhere. References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html Reported-and-tested-by: Mihai Moldovan Cc: David Woodhouse Cc: "Sankaran, Rajesh" Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit bdfb3335569583fd195a3a1a89380d7648a9a85f Author: Nicholas Bellinger Date: Tue Feb 19 03:15:14 2013 +0000 target: Fix divide by zero bug in fabric_max_sectors for unconfigured devices commit 7a3cf6ca1ab2a2f7161c6dec5a787fc7a5de864e upstream This patch fixes a possible divide by zero bug when the fabric_max_sectors device attribute is written and backend se_device failed to be successfully configured -> enabled. Go ahead and use block_size=512 within se_dev_set_fabric_max_sectors() in the event of a target_configure_device() failure case, as no valid dev->dev_attrib.block_size value will have been setup yet. Signed-off-by: Nicholas Bellinger Cc: Herton Ronaldo Krzesinski Signed-off-by: Greg Kroah-Hartman commit 61d40262e55fe00b817fe7e28f0f4dfad6e31fca Author: Dave Airlie Date: Thu Feb 7 10:10:04 2013 +1000 drm/usb: bind driver to correct device commit 9f23de52b64f7fb801fd76f3dd8651a0dc89187b upstream. While looking at plymouth on udl I noticed that plymouth was trying to use its fb plugin not its drm one, it was trying to drmOpen a driver called usb not udl, noticed that we actually had out driver pointing at the wrong device. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit d8a5f7fe8d632290ecbb6f692b98136957abe21a Author: Ville Syrjälä Date: Thu Jan 31 19:43:38 2013 +0200 drm: Use C8 instead of RGB332 when determining the format from depth/bpp commit d84f031bd230fdf9c3b7734940c859bf28b90219 upstream. Support for real RGB332 is a rarity, most hardware only really support C8. So use C8 instead of RGB332 when determining the format based on depth/bpp. This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not RGB332. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572 Signed-off-by: Ville Syrjälä Acked-by: Dave Airlie Tested-by: mlsemon35@gmail.com Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit d8fe02dde5c0aa474a32fe13d0743be515bb41dc Author: Ville Syrjälä Date: Thu Jan 31 19:43:37 2013 +0200 drm: Fill depth/bits_per_pixel for C8 format commit c51a6bc5f6d328926a9a4a1247c5030faf190a80 upstream. Set depth/bits_per_pixel to 8 for C8 format. Signed-off-by: Ville Syrjälä Acked-by: Dave Airlie Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 7b480b03691358af771e6104087e05ffecc7d16a Author: Paulo Zanoni Date: Fri Feb 15 13:36:27 2013 -0200 drm: don't add inferred modes for monitors that don't support them commit 196e077dc165a307efbd9e7569f81bbdbcf18f65 upstream. If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher Reviewed-by: Adam Jackson Signed-off-by: Paulo Zanoni Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit df28f4890263a0540b395402b43b57f047ccf7d5 Author: Dave Airlie Date: Thu Jan 24 14:14:19 2013 +1000 vgacon/vt: clear buffer attributes when we load a 512 character font (v2) commit 2a2483072393b27f4336ab068a1f48ca19ff1c1e upstream. When we switch from 256->512 byte font rendering mode, it means the current contents of the screen is being reinterpreted. The bit that holds the high bit of the 9-bit font, may have been previously set, and thus the new font misrenders. The problem case we see is grub2 writes spaces with the bit set, so it ends up with data like 0x820, which gets reinterpreted into 0x120 char which the font translates into G with a circumflex. This flashes up on screen at boot and is quite ugly. A current side effect of this patch though is that any rendering on the screen changes color to a slightly darker color, but at least the screen no longer corrupts. v2: as suggested by hpa, always clear the attribute space, whether we are are going to or from 512 chars. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit ae4c05e0232e869cf2418ac6c0c862bb5287d672 Author: Dave Airlie Date: Thu Feb 7 12:30:25 2013 +1000 drm/udl: disable fb_defio by default commit 677d23b70bf949f75746c80cbae92c233c6b5e2a upstream. There seems to be a bad interaction between gem/shmem and defio on top, I get list corruption on the page lru in the shmem code. Turn it off for now until we get some more digging done. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit b701cf407f9508fb899b482d9224daba2cedec75 Author: Dave Airlie Date: Thu Feb 7 11:19:15 2013 +1000 drm/udl: make usage as a console safer commit bcb39af4486be07e896fc374a2336bad3104ae0a upstream. Okay you don't really want to use udl devices as your console, but if you are unlucky enough to do so, you run into a lot of schedule while atomic due to printk being called from all sorts of funky places. So check if we are in an atomic context, and queue the damage for later, the next printk should cause it to appear. This isn't ideal, but it is simple, and seems to work okay in my testing here. (dirty area idea came from xenfb) fixes a bunch of sleeping while atomic issues running fbcon on udl devices. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 746042cf26dbcf5a8feb4f8938a3531a6169c96e Author: Alex Deucher Date: Tue Feb 5 11:47:09 2013 -0500 drm/radeon/dce6: fix display powergating commit 0e3d50bfcbd338254795a700dcff429a96cba1a6 upstream. Only enable it when we disable the display rather than at DPMS time since enabling it requires a full modeset to restore the display state. Fixes blank screens in certain cases. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5cf5b734496e73c30f43833138078ee7884ec725 Author: David S. Miller Date: Thu Feb 14 11:49:01 2013 -0800 sunvdc: Fix off-by-one in generic_request(). [ Upstream commit f4d9605434c0fd4cc8639bf25cfc043418c52362 ] The 'operations' bitmap corresponds one-for-one with the operation codes, no adjustment is necessary. Reported-by: Mark Kettenis Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 652328944e2514cd8306a71a2bbac4896efa49ed Author: David Henningsson Date: Tue Feb 19 16:11:22 2013 +0100 ALSA: hda - hdmi: ELD shouldn't be valid after unplug commit bbfd8a19b6913f50a362457c34d49bfafe5e456e upstream. Currently, eld_valid is never set to false, except at kernel module load time. This patch makes sure that eld is no longer valid when the cable is (hot-)unplugged. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7e8b41d605b06c68a7df890e34cb560d837e87ac Author: Fernando Luis Vazquez Cao Date: Tue Feb 12 16:47:44 2013 +0900 ALSA: hda - Workaround for silent output on Sony Vaio VGC-LN51JGB with ALC889 commit 12e31a78c70dc12897fda2489113f445c0e94a18 upstream. Some Vaio all-in-one desktop PCs (for example VGC-LN51JGB) are affected by the same issue that caused Vaio Z laptops to become silent: the speaker pin must be connected to the first DAC even though the codec itself advertises flexible routing through any of the DACs. Use the no-primary-hp fixup for choosing the speaker pin as the primary so that the right DAC is assigned on this device. Signed-off-by: Fernando Luis Vazquez Cao Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 63b2afe91cef7d844ea07a1ad17be63ded94e8ca Author: Takashi Iwai Date: Fri Feb 1 14:01:27 2013 +0100 ALSA: hda - Release assigned pin/cvt at error path of hdmi_pcm_open() commit 2ad779b7329d6894a80df94e693e72eaa0d56790 upstream. If the driver detects and invalid ELD, it gives an open error. But it forgot to release the assigned pin, converter and spdif ctls before returning. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e32afc122e3a808944a9f7af5612bf2a3cbea89a Author: Pawel Moll Date: Thu Feb 21 01:55:50 2013 +0000 ALSA: usb: Fix Processing Unit Descriptor parsers commit b531f81b0d70ffbe8d70500512483227cc532608 upstream. Commit 99fc86450c439039d2ef88d06b222fd51a779176 "ALSA: usb-mixer: parse descriptors with structs" introduced a set of useful parsers for descriptors. Unfortunately the parses for the Processing Unit Descriptor came with a very subtle bug... Functions uac_processing_unit_iProcessing() and uac_processing_unit_specific() were indexing the baSourceID array forgetting the fields before the iProcessing and process-specific descriptors. The problem was observed with Sound Blaster Extigy mixer, where nNrModes in Up/Down-mix Processing Unit Descriptor was accessed at offset 10 of the descriptor (value 0) instead of offset 15 (value 7). In result the resulting control had interesting limit values: Simple mixer control 'Channel Routing Mode Select',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - -1 Mono: -1 [100%] Fixed by starting from the bmControls, which was calculated correctly, instead of baSourceID. Now the mentioned control is fine: Simple mixer control 'Channel Routing Mode Select',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 6 Mono: 0 [0%] Signed-off-by: Pawel Moll Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e3fc3cb2a03623b48250dd3a12378a42d276f20e Author: Clemens Ladisch Date: Thu Jan 31 21:14:33 2013 +0100 ALSA: usb-audio: fix Roland A-PRO support commit 7da58046482fceb17c4a0d4afefd9507ec56de7f upstream. The quirk for the Roland/Cakewalk A-PRO keyboards accidentally used the wrong interface number, which prevented the driver from attaching to the device. Signed-off-by: Clemens Ladisch Signed-off-by: Greg Kroah-Hartman commit a8fb02fe99203fea52046151817672102124d389 Author: Tomasz Guszkowski Date: Tue Feb 5 22:10:31 2013 +0100 p54usb: corrected USB ID for T-Com Sinus 154 data II commit 008e33f733ca51acb2dd9d88ea878693b04d1d2a upstream. Corrected USB ID for T-Com Sinus 154 data II. ISL3887-based. The device was tested in managed mode with no security, WEP 128 bit and WPA-PSK (TKIP) with firmware 2.13.1.0.lm87.arm (md5sum: 7d676323ac60d6e1a3b6d61e8c528248). It works. Signed-off-by: Tomasz Guszkowski Acked-By: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 92a5267ac37e74cf44675f5992fc6fa4ad694a04 Author: Trond Myklebust Date: Tue Feb 19 12:04:42 2013 -0500 NLM: Ensure that we resend all pending blocking locks after a reclaim commit 666b3d803a511fbc9bc5e5ea8ce66010cf03ea13 upstream. Currently, nlmclnt_lock will break out of the for(;;) loop when the reclaimer wakes up the blocking lock thread by setting nlm_lck_denied_grace_period. This causes the lock request to fail with an ENOLCK error. The intention was always to ensure that we resend the lock request after the grace period has expired. Reported-by: Wangyuan Zhang Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8e0ed8259d2016543b07a43896bc6f4b7f541e42 Author: fanchaoting Date: Mon Feb 4 21:15:02 2013 +0800 umount oops when remove blocklayoutdriver first commit 5a12cca697aca5dfba42a7d4c3356acc0445a2b0 upstream. now pnfs client uses block layout, maybe we can remove blocklayoutdriver first. if we umount later, it can cause oops in unset_pnfs_layoutdriver. because nfss->pnfs_curr_ld->clear_layoutdriver is invalid. reproduce it: modprobe blocklayoutdriver mount -t nfs4 -o minorversion=1 pnfsip:/ /mnt/ rmmod blocklayoutdriver umount /mnt then you can see following CPU 0 Pid: 17023, comm: umount.nfs4 Tainted: GF O 3.7.0-rc6-pnfs #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[] [] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4] RSP: 0018:ffff8800022d9e48 EFLAGS: 00010286 RAX: ffffffffa04a1b00 RBX: ffff88000b013800 RCX: 0000000000000001 RDX: ffffffff81ae8ee0 RSI: ffff880001ee94b8 RDI: ffff88000b013800 RBP: ffff8800022d9e58 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880001ee9400 R13: ffff8800105978c0 R14: 00007fff25846c08 R15: 0000000001bba550 FS: 00007f45ae7f0700(0000) GS:ffff880012c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffa04a1b38 CR3: 0000000002c0c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process umount.nfs4 (pid: 17023, threadinfo ffff8800022d8000, task ffff880006e48aa0) Stack: ffff8800105978c0 ffff88000b013800 ffff8800022d9e78 ffffffffa04cd0ce ffff8800022d9e78 ffff88000b013800 ffff8800022d9ea8 ffffffffa04755a7 ffff8800022d9ea8 ffff880002f96400 ffff88000b013800 ffff880002f96400 Call Trace: [] nfs4_destroy_server+0x1e/0x30 [nfsv4] [] nfs_free_server+0xb7/0x150 [nfs] [] nfs_kill_super+0x35/0x40 [nfs] [] deactivate_locked_super+0x45/0x70 [] deactivate_super+0x4a/0x70 [] mntput_no_expire+0xd2/0x130 [] sys_umount+0x72/0xe0 [] system_call_fastpath+0x16/0x1b Code: 06 e1 b8 ea ff ff ff eb 9e 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 48 8b 87 80 03 00 00 48 89 fb 48 85 c0 74 29 <48> 8b 40 38 48 85 c0 74 02 ff d0 48 8b 03 3e ff 48 04 0f 94 c2 RIP [] unset_pnfs_layoutdriver+0x1d/0x70 [nfsv4] RSP CR2: ffffffffa04a1b38 ---[ end trace 29f75aaedda058bf ]--- Signed-off-by: fanchaoting Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 38bc0fe99edd35ef738800167c67055f8ca7e476 Author: Grant Likely Date: Thu Feb 14 18:14:27 2013 +0000 drivercore: Fix ordering between deferred_probe and exiting initcalls commit d72cca1eee5b26e313da2a380d4862924e271031 upstream. One of the side effects of deferred probe is that some drivers which used to be probed before initcalls completed are now happening slightly later. This causes two problems. - If a console driver gets deferred, then it may not be ready when userspace starts. For example, if a uart depends on pinctrl, then the uart will get deferred and /dev/console will not be available - __init sections will be discarded before built-in drivers are probed. Strictly speaking, __init functions should not be called in a drivers __probe path, but there are a lot of drivers (console stuff again) that do anyway. In the past it was perfectly safe to do so because all built-in drivers got probed before the end of initcalls. This patch fixes the problem by forcing the first pass of the deferred list to complete at late_initcall time. This is late enough to catch the drivers that are known to have the above issues. Signed-off-by: Grant Likely Tested-by: Haojian Zhuang Cc: Arnd Bergmann Cc: Russell King Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f4ce5b3f263c05e7af66fa4eba7c4eb8e1b006bf Author: Mel Gorman Date: Fri Feb 22 16:35:59 2013 -0800 mm/fadvise.c: drain all pagevecs if POSIX_FADV_DONTNEED fails to discard all pages commit 67d46b296a1ba1477c0df8ff3bc5e0167a0b0732 upstream. Rob van der Heij reported the following (paraphrased) on private mail. The scenario is that I want to avoid backups to fill up the page cache and purge stuff that is more likely to be used again (this is with s390x Linux on z/VM, so I don't give it as much memory that we don't care anymore). So I have something with LD_PRELOAD that intercepts the close() call (from tar, in this case) and issues a posix_fadvise() just before closing the file. This mostly works, except for small files (less than 14 pages) that remains in page cache after the face. Unfortunately Rob has not had a chance to test this exact patch but the test program below should be reproducing the problem he described. The issue is the per-cpu pagevecs for LRU additions. If the pages are added by one CPU but fadvise() is called on another then the pages remain resident as the invalidate_mapping_pages() only drains the local pagevecs via its call to pagevec_release(). The user-visible effect is that a program that uses fadvise() properly is not obeyed. A possible fix for this is to put the necessary smarts into invalidate_mapping_pages() to globally drain the LRU pagevecs if a pagevec page could not be discarded. The downside with this is that an inode cache shrink would send a global IPI and memory pressure potentially causing global IPI storms is very undesirable. Instead, this patch adds a check during fadvise(POSIX_FADV_DONTNEED) to check if invalidate_mapping_pages() discarded all the requested pages. If a subset of pages are discarded it drains the LRU pagevecs and tries again. If the second attempt fails, it assumes it is due to the pages being mapped, locked or dirty and does not care. With this patch, an application using fadvise() correctly will be obeyed but there is a downside that a malicious application can force the kernel to send global IPIs and increase overhead. If accepted, I would like this to be considered as a -stable candidate. It's not an urgent issue but it's a system call that is not working as advertised which is weak. The following test program demonstrates the problem. It should never report that pages are still resident but will without this patch. It assumes that CPU 0 and 1 exist. int main() { int fd; int pagesize = getpagesize(); ssize_t written = 0, expected; char *buf; unsigned char *vec; int resident, i; cpu_set_t set; /* Prepare a buffer for writing */ expected = FILESIZE_PAGES * pagesize; buf = malloc(expected + 1); if (buf == NULL) { printf("ENOMEM\n"); exit(EXIT_FAILURE); } buf[expected] = 0; memset(buf, 'a', expected); /* Prepare the mincore vec */ vec = malloc(FILESIZE_PAGES); if (vec == NULL) { printf("ENOMEM\n"); exit(EXIT_FAILURE); } /* Bind ourselves to CPU 0 */ CPU_ZERO(&set); CPU_SET(0, &set); if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) { perror("sched_setaffinity"); exit(EXIT_FAILURE); } /* open file, unlink and write buffer */ fd = open("fadvise-test-file", O_CREAT|O_EXCL|O_RDWR); if (fd == -1) { perror("open"); exit(EXIT_FAILURE); } unlink("fadvise-test-file"); while (written < expected) { ssize_t this_write; this_write = write(fd, buf + written, expected - written); if (this_write == -1) { perror("write"); exit(EXIT_FAILURE); } written += this_write; } free(buf); /* * Force ourselves to another CPU. If fadvise only flushes the local * CPUs pagevecs then the fadvise will fail to discard all file pages */ CPU_ZERO(&set); CPU_SET(1, &set); if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) { perror("sched_setaffinity"); exit(EXIT_FAILURE); } /* sync and fadvise to discard the page cache */ fsync(fd); if (posix_fadvise(fd, 0, expected, POSIX_FADV_DONTNEED) == -1) { perror("posix_fadvise"); exit(EXIT_FAILURE); } /* map the file and use mincore to see which parts of it are resident */ buf = mmap(NULL, expected, PROT_READ, MAP_SHARED, fd, 0); if (buf == NULL) { perror("mmap"); exit(EXIT_FAILURE); } if (mincore(buf, expected, vec) == -1) { perror("mincore"); exit(EXIT_FAILURE); } /* Check residency */ for (i = 0, resident = 0; i < FILESIZE_PAGES; i++) { if (vec[i]) resident++; } if (resident != 0) { printf("Nr unexpected pages resident: %d\n", resident); exit(EXIT_FAILURE); } munmap(buf, expected); close(fd); free(vec); exit(EXIT_SUCCESS); } Signed-off-by: Mel Gorman Reported-by: Rob van der Heij Tested-by: Rob van der Heij Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 06c7976c91566d676766ad57b574757f6d0abd02 Author: Greg Thelen Date: Fri Feb 22 16:36:01 2013 -0800 tmpfs: fix use-after-free of mempolicy object commit 5f00110f7273f9ff04ac69a5f85bb535a4fd0987 upstream. The tmpfs remount logic preserves filesystem mempolicy if the mpol=M option is not specified in the remount request. A new policy can be specified if mpol=M is given. Before this patch remounting an mpol bound tmpfs without specifying mpol= mount option in the remount request would set the filesystem's mempolicy object to a freed mempolicy object. To reproduce the problem boot a DEBUG_PAGEALLOC kernel and run: # mkdir /tmp/x # mount -t tmpfs -o size=100M,mpol=interleave nodev /tmp/x # grep /tmp/x /proc/mounts nodev /tmp/x tmpfs rw,relatime,size=102400k,mpol=interleave:0-3 0 0 # mount -o remount,size=200M nodev /tmp/x # grep /tmp/x /proc/mounts nodev /tmp/x tmpfs rw,relatime,size=204800k,mpol=??? 0 0 # note ? garbage in mpol=... output above # dd if=/dev/zero of=/tmp/x/f count=1 # panic here Panic: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) [...] Oops: 0010 [#1] SMP DEBUG_PAGEALLOC Call Trace: mpol_shared_policy_init+0xa5/0x160 shmem_get_inode+0x209/0x270 shmem_mknod+0x3e/0xf0 shmem_create+0x18/0x20 vfs_create+0xb5/0x130 do_last+0x9a1/0xea0 path_openat+0xb3/0x4d0 do_filp_open+0x42/0xa0 do_sys_open+0xfe/0x1e0 compat_sys_open+0x1b/0x20 cstar_dispatch+0x7/0x1f Non-debug kernels will not crash immediately because referencing the dangling mpol will not cause a fault. Instead the filesystem will reference a freed mempolicy object, which will cause unpredictable behavior. The problem boils down to a dropped mpol reference below if shmem_parse_options() does not allocate a new mpol: config = *sbinfo shmem_parse_options(data, &config, true) mpol_put(sbinfo->mpol) sbinfo->mpol = config.mpol /* BUG: saves unreferenced mpol */ This patch avoids the crash by not releasing the mempolicy if shmem_parse_options() doesn't create a new mpol. How far back does this issue go? I see it in both 2.6.36 and 3.3. I did not look back further. Signed-off-by: Greg Thelen Acked-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3b6e03c9ac4d57ccb03737a997069dc7ab65601c Author: Lars-Peter Clausen Date: Thu Feb 21 16:44:04 2013 -0800 drivers/video/backlight/adp88?0_bl.c: fix resume commit 5eb02c01bd1f3ef195989ab05e835e2b0711b5a9 upstream. Clearing the NSTBY bit in the control register also automatically clears the BLEN bit. So we need to make sure to set it again during resume, otherwise the backlight will stay off. Signed-off-by: Lars-Peter Clausen Acked-by: Michael Hennerich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cd336937712589aff73931ed84c2bc56d0574a3c Author: Junxiao Bi Date: Thu Feb 21 16:42:45 2013 -0800 ocfs2: unlock super lock if lockres refresh failed commit 3278bb748d2437eb1464765f36429e5d6aa91c38 upstream. If lockres refresh failed, the super lock will never be released which will cause some processes on other cluster nodes hung forever. Signed-off-by: Junxiao Bi Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9fd4e539ed0737be165fc633063885a477ac556a Author: MITSUNARI Shigeo Date: Thu Feb 21 16:42:01 2013 -0800 fs/block_dev.c: page cache wrongly left invalidated after revalidate_disk() commit 7630b661da330b35dd57b6f5d6d62b386f2dd751 upstream. We found that bdev->bd_invalidated was left set once revalidate_disk() is called, which results in page cache flush every time that device is open. Specifically, we found this problem in MD block device. Once we resize a MD device, mdadm --monitor periodically flush all page cache for that device every 60 or 1000 seconds when it opens the device. This bug lies since at least 3.2.0 till the latest kernel(3.6.2). Patch is attached. The following steps will reproduce the problem. 1. prepair a block device (eg /dev/sdb). 2. create two partitions: sudo parted /dev/sdb mklabel gpt mkpart primary 0% 50% mkpart primary 50% 100% 3. create a md device. sudo mdadm -C /dev/md/hoge -l 1 -n 2 -e 1.2 --assume-clean --auto=md --symlink=no /dev/sdb1 /dev/sdb2 4. create file system and mount it sudo mkfs.ext3 /dev/md/hoge sudo mkdir /mnt/test sudo mount /dev/md/hoge /mnt/test 5. try to resize the device sudo mdadm -G /dev/md/hoge --size=max 6. create a file to fill file cache. sudo dd if=/dev/urandom of=/mnt/test/data bs=1M count=10 and verify the current status of file by free command. 7. mdadm monitor will open the md device every 1000 seconds and you will find all file cache on the device are cleared. The timing can be reduced by the following steps. a) kill mdadm and restart it with --delay option /sbin/mdadm --monitor --delay=30 --pid-file /var/run/mdadm/monitor.pid --daemonise --scan --syslog or open the md device directly. sudo dd if=/dev/md/hoge of=/dev/null bs=4096 count=1 Signed-off-by: MITSUNARI Shigeo Cc: Al Viro Cc: Jeff Moyer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0b7fba4034da2a6dd6ebb994ad9f592939a752cf Author: Jim Somerville Date: Thu Feb 21 16:41:59 2013 -0800 inotify: remove broken mask checks causing unmount to be EINVAL commit 676a0675cf9200ac047fb50825f80867b3bb733b upstream. Running the command: inotifywait -e unmount /mnt/disk immediately aborts with a -EINVAL return code. This is however a valid parameter. This abort occurs only if unmount is the sole event parameter. If other event parameters are supplied, then the unmount event wait will work. The problem was introduced by commit 44b350fc23e ("inotify: Fix mask checks"). In that commit, it states: The mask checks in inotify_update_existing_watch() and inotify_new_watch() are useless because inotify_arg_to_mask() sets FS_IN_IGNORED and FS_EVENT_ON_CHILD bits anyway. But instead of removing the useless checks, it did this: mask = inotify_arg_to_mask(arg); - if (unlikely(!mask)) + if (unlikely(!(mask & IN_ALL_EVENTS))) return -EINVAL; The problem is that IN_ALL_EVENTS doesn't include IN_UNMOUNT, and other parts of the code keep IN_UNMOUNT separate from IN_ALL_EVENTS. So the check should be: if (unlikely(!(mask & (IN_ALL_EVENTS | IN_UNMOUNT)))) But inotify_arg_to_mask(arg) always sets the IN_UNMOUNT bit in the mask anyway, so the check is always going to pass and thus should simply be removed. Also note that inotify_arg_to_mask completely controls what mask bits get set from arg, there's no way for invalid bits to get enabled there. Lets fix it by simply removing the useless broken checks. Signed-off-by: Jim Somerville Signed-off-by: Paul Gortmaker Cc: Jerome Marchand Cc: John McCutchan Cc: Robert Love Cc: Eric Paris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 803437207a3e6fef7791adeb7a0c2adb4b012459 Author: Thomas Gleixner Date: Mon Feb 18 09:52:08 2013 +0100 futex: Revert "futex: Mark get_robust_list as deprecated" commit fe2b05f7ca9f906be61dced5489f63b8b4d7c770 upstream. This reverts commit ec0c4274e33c0373e476b73e01995c53128f1257. get_robust_list() is in use and a removal would break existing user space. With the permission checks in place it's not longer a security hole. Remove the deprecation warnings. Signed-off-by: Thomas Gleixner Cc: Cyrill Gorcunov Cc: Richard Weinberger Cc: akpm@linux-foundation.org Cc: paul.gortmaker@windriver.com Cc: davej@redhat.com Cc: keescook@chromium.org Cc: ebiederm@xmission.com Signed-off-by: Greg Kroah-Hartman commit e3aa5ed471454f36e99b8d3a960746eb58c07180 Author: Christian Borntraeger Date: Fri Jan 25 15:34:15 2013 +0100 s390/kvm: Fix store status for ACRS/FPRS commit 15bc8d8457875f495c59d933b05770ba88d1eacb upstream. On store status we need to copy the current state of registers into a save area. Currently we might save stale versions: The sie state descriptor doesnt have fields for guest ACRS,FPRS, those registers are simply stored in the host registers. The host program must copy these away if needed. We do that in vcpu_put/load. If we now do a store status in KVM code between vcpu_put/load, the saved values are not up-to-date. Lets collect the ACRS/FPRS before saving them. This also fixes some strange problems with hotplug and virtio-ccw, since the low level machine check handler (on hotplug a machine check will happen) will revalidate all registers with the content of the save area. Signed-off-by: Christian Borntraeger Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit 2030511afec79a7f65b967c3d8a22e4a1edd9532 Author: Cornelia Huck Date: Fri Dec 14 17:02:16 2012 +0100 KVM: s390: Handle hosts not supporting s390-virtio. commit 55c171a6d90dc0574021f9c836127cfd1a7d2e30 upstream. Running under a kvm host does not necessarily imply the presence of a page mapped above the main memory with the virtio information; however, the code includes a hard coded access to that page. Instead, check for the presence of the page and exit gracefully before we hit an addressing exception if it does not exist. Reviewed-by: Marcelo Tosatti Reviewed-by: Alexander Graf Signed-off-by: Cornelia Huck Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit 7fecb64cca9a98f60ff4bc794bb353512bd5c665 Author: Robin Holt Date: Fri Feb 22 16:35:34 2013 -0800 mmu_notifier_unregister NULL Pointer deref and multiple ->release() callouts commit 751efd8610d3d7d67b7bdf7f62646edea7365dd7 upstream. There is a race condition between mmu_notifier_unregister() and __mmu_notifier_release(). Assume two tasks, one calling mmu_notifier_unregister() as a result of a filp_close() ->flush() callout (task A), and the other calling mmu_notifier_release() from an mmput() (task B). A B t1 srcu_read_lock() t2 if (!hlist_unhashed()) t3 srcu_read_unlock() t4 srcu_read_lock() t5 hlist_del_init_rcu() t6 synchronize_srcu() t7 srcu_read_unlock() t8 hlist_del_rcu() <--- NULL pointer deref. Additionally, the list traversal in __mmu_notifier_release() is not protected by the by the mmu_notifier_mm->hlist_lock which can result in callouts to the ->release() notifier from both mmu_notifier_unregister() and __mmu_notifier_release(). -stable suggestions: The stable trees prior to 3.7.y need commits 21a92735f660 and 70400303ce0c cherry-picked in that order prior to cherry-picking this commit. The 3.7.y tree already has those two commits. Signed-off-by: Robin Holt Cc: Andrea Arcangeli Cc: Wanpeng Li Cc: Xiao Guangrong Cc: Avi Kivity Cc: Hugh Dickins Cc: Marcelo Tosatti Cc: Sagi Grimberg Cc: Haggai Eran Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d0730c2bf33c1cdab392f88013be6b5ebacf0f29 Author: Andrea Arcangeli Date: Mon Oct 8 16:31:52 2012 -0700 mm: mmu_notifier: make the mmu_notifier srcu static commit 70400303ce0c4ced3139499c676d5c79636b0c72 upstream. The variable must be static especially given the variable name. s/RCU/SRCU/ over a few comments. Signed-off-by: Andrea Arcangeli Cc: Xiao Guangrong Cc: Sagi Grimberg Cc: Peter Zijlstra Cc: Haggai Eran Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4209ee0d3f7992af3903b5f9a3359f6d2f597c4b Author: Sagi Grimberg Date: Mon Oct 8 16:29:24 2012 -0700 mm: mmu_notifier: have mmu_notifiers use a global SRCU so they may safely schedule commit 21a92735f660eaecf69a6f2e777f18463760ec32 upstream. With an RCU based mmu_notifier implementation, any callout to mmu_notifier_invalidate_range_{start,end}() or mmu_notifier_invalidate_page() would not be allowed to call schedule() as that could potentially allow a modification to the mmu_notifier structure while it is currently being used. Since srcu allocs 4 machine words per instance per cpu, we may end up with memory exhaustion if we use srcu per mm. So all mms share a global srcu. Note that during large mmu_notifier activity exit & unregister paths might hang for longer periods, but it is tolerable for current mmu_notifier clients. Signed-off-by: Sagi Grimberg Signed-off-by: Andrea Arcangeli Cc: Peter Zijlstra Cc: Haggai Eran Cc: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 362efcc9b0ba020f9124c70c56381ed64491aeca Author: Bjorn Helgaas Date: Tue Jan 29 16:44:27 2013 -0700 Driver core: treat unregistered bus_types as having no devices commit 4fa3e78be7e985ca814ce2aa0c09cbee404efcf7 upstream. A bus_type has a list of devices (klist_devices), but the list and the subsys_private structure that contains it are not initialized until the bus_type is registered with bus_register(). The panic/reboot path has fixups that look up devices in pci_bus_type. If we panic before registering pci_bus_type, the bus_type exists but the list does not, so mach_reboot_fixups() trips over a null pointer and panics again: mach_reboot_fixups pci_get_device .. bus_find_device(&pci_bus_type, ...) bus->p is NULL Joonsoo reported a problem when panicking before PCI was initialized. I think this patch should be sufficient to replace the patch he posted here: https://lkml.org/lkml/2012/12/28/75 ("[PATCH] x86, reboot: skip reboot_fixups in early boot phase") Reported-by: Joonsoo Kim Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 2199a6528ce9b299f3a3e2a6b50cfd197cbc135e Author: Wei Liu Date: Mon Feb 18 14:57:58 2013 +0000 xen: close evtchn port if binding to irq fails commit e7e44e444876478d50630f57b0c31d29f6725020 upstream. Signed-off-by: Wei Liu Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 4f4eb62481b02ffec9edee9f109d22d6debe0281 Author: Stefan Bader Date: Fri Feb 15 09:48:52 2013 +0100 xen: Send spinlock IPI to all waiters commit 76eaca031f0af2bb303e405986f637811956a422 upstream. There is a loophole between Xen's current implementation of pv-spinlocks and the scheduler. This was triggerable through a testcase until v3.6 changed the TLB flushing code. The problem potentially is still there just not observable in the same way. What could happen was (is): 1. CPU n tries to schedule task x away and goes into a slow wait for the runq lock of CPU n-# (must be one with a lower number). 2. CPU n-#, while processing softirqs, tries to balance domains and goes into a slow wait for its own runq lock (for updating some records). Since this is a spin_lock_irqsave in softirq context, interrupts will be re-enabled for the duration of the poll_irq hypercall used by Xen. 3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives an interrupt (e.g. endio) and when processing the interrupt, tries to wake up task x. But that is in schedule and still on_cpu, so try_to_wake_up goes into a tight loop. 4. The runq lock of CPU n-# gets unlocked, but the message only gets sent to the first waiter, which is CPU n-# and that is busily stuck. 5. CPU n-# never returns from the nested interruption to take and release the lock because the scheduler uses a busy wait. And CPU n never finishes the task migration because the unlock notification only went to CPU n-#. To avoid this and since the unlocking code has no real sense of which waiter is best suited to grab the lock, just send the IPI to all of them. This causes the waiters to return from the hyper- call (those not interrupted at least) and do active spinlocking. BugLink: http://bugs.launchpad.net/bugs/1011792 Acked-by: Jan Beulich Signed-off-by: Stefan Bader Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 6a171676006047cd613093b74a6cfdcba8686065 Author: Jussi Kivilinna Date: Mon Feb 18 10:29:30 2013 +0200 rtlwifi: usb: allocate URB control message setup_packet and data buffer separately commit bc6b89237acb3dee6af6e64e51a18255fef89cc2 upstream. rtlwifi allocates both setup_packet and data buffer of control message urb, using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for allocating is: struct { u8 data[254]; struct usb_ctrlrequest dr; }; Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory corruptions and freezes. Patch changes setup packet to be allocated separately. [v2]: - Use WARN_ON_ONCE instead of WARN_ON Signed-off-by: Jussi Kivilinna Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d1179077b018d6c5488eaaa5c71349094d5104f3 Author: Larry Finger Date: Fri Feb 8 12:28:18 2013 -0600 rtlwifi: rtl8192cu: Add new USB ID commit 8708aac79e4572ba673d7a21e94ddca9f3abb7fc upstream. A new model of the RTL8188CUS has appeared. Reported-and-tested-by: Thomas Rosenkrantz Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1946c763f335fcc7482936c039fddeb179c7f384 Author: Larry Finger Date: Sun Feb 17 17:01:20 2013 +0000 b43: Increase number of RX DMA slots commit ccae0e50c16a7f7adb029c169147400d1ce9f703 upstream. Bastian Bittorf reported that some of the silent freezes on a Linksys WRT54G were due to overflow of the RX DMA ring buffer, which was created with 64 slots. That finding reminded me that I was seeing similar crashed on a netbook, which also has a relatively slow processor. After increasing the number of slots to 128, runs on the netbook that previously failed now worked; however, I found that 109 slots had been used in one test. For that reason, the number of slots is being increased to 256. Signed-off-by: Larry Finger Cc: Bastian Bittorf Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 906c9c42101742d1ec86ab22eb55d24d496830a7 Author: Johan Hovold Date: Wed Feb 13 17:53:28 2013 +0100 USB: serial: fix null-pointer dereferences on disconnect commit b2ca699076573c94fee9a73cb0d8645383b602a0 upstream. Make sure serial-driver dtr_rts is called with disc_mutex held after checking the disconnected flag. Due to a bug in the tty layer, dtr_rts may get called after a device has been disconnected and the tty-device unregistered. Some drivers have had individual checks for disconnect to make sure the disconnected interface was not accessed, but this should really be handled in usb-serial core (at least until the long-standing tty-bug has been fixed). Note that the problem has been made more acute with commit 0998d0631001 ("device-core: Ensure drvdata = NULL when no driver is bound") as the port data is now also NULL when dtr_rts is called resulting in further oopses. Reported-by: Chris Ruehl Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 46605dae03a55a70d7fd9886f466b435afc7738b Author: Oleg Nesterov Date: Tue Jan 29 20:07:41 2013 +0100 tty: set_termios/set_termiox should not return -EINTR commit 183d95cdd834381c594d3aa801c1f9f9c0c54fa9 upstream. See https://bugzilla.redhat.com/show_bug.cgi?id=904907 read command causes bash to abort with double free or corruption (out). A simple test-case from Roman: // Compile the reproducer and send sigchld ti that process. // EINTR occurs even if SA_RESTART flag is set. void handler(int sig) { } main() { struct sigaction act; act.sa_handler = handler; act.sa_flags = SA_RESTART; sigaction (SIGCHLD, &act, 0); struct termio ttp; ioctl(0, TCGETA, &ttp); while(1) { if (ioctl(0, TCSETAW, ttp) < 0) { if (errno == EINTR) { fprintf(stderr, "BUG!"); return(1); } } } } Change set_termios/set_termiox to return -ERESTARTSYS to fix this particular problem. I didn't dare to change other EINTR's in drivers/tty/, but they look equally wrong. Reported-by: Roman Rakus Reported-by: Lingzhu Xiang Signed-off-by: Oleg Nesterov Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 0c10d7fd0d53e3e44cc04edc37120bce6d74e2ca Author: Dirkjan Bussink Date: Wed Jan 30 11:44:50 2013 +0100 tty: Prevent deadlock in n_gsm driver commit 4d9b109060f690f5c835130ff54165ae157b3087 upstream. This change fixes a deadlock when the multiplexer is closed while there are still client side ports open. When the multiplexer is closed and there are active tty's it tries to close them with tty_vhangup. This has a problem though, because tty_vhangup needs the tty_lock. This patch changes it to unlock the tty_lock before attempting the hangup and relocks afterwards. The additional call to tty_port_tty_set is needed because otherwise the port stays active because of the reference counter. This change also exposed another problem that other code paths don't expect that the multiplexer could have been closed. This patch also adds checks for these cases in the gsmtty_ class of function that could be called. The documentation explicitly states that "first close all virtual ports before closing the physical port" but we've found this to not always reality in our field situations. The GPRS / UTMS modem sometimes crashes and needs a power cycle in that case which means cleanly shutting down everything is not always possible. This change makes it much more robust for our situation where at least the system is recoverable with this patch and doesn't hang in a deadlock situation inside the kernel. The patch is against the long term support kernel (3.4.27) and should apply cleanly to more recent branches. Tested with a Telit GE864-QUADV2 and Telit HE910 modem. Signed-off-by: Dirkjan Bussink Signed-off-by: Greg Kroah-Hartman commit ceb0446b6dff34bfe41c9fa54796e7b21a17bd56 Author: Denis Efremov Date: Mon Feb 11 19:04:06 2013 +0400 ALSA: rme32.c irq enabling after spin_lock_irq commit f49a59c4471d81a233e09dda45187cc44fda009d upstream. According to the other code in this driver and similar code in rme96 it seems, that spin_lock_irq in snd_rme32_capture_close function should be paired with spin_unlock_irq. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Denis Efremov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7fb3e95821e901ed594c88747e5729a39723d2ff Author: Denis Efremov Date: Mon Feb 11 19:49:48 2013 +0400 ALSA: ali5451: remove irq enabling in pointer callback commit dacae5a19b4cbe1b5e3a86de23ea74cbe9ec9652 upstream. snd_ali_pointer function is called with local interrupts disabled. However it seems very strange to reenable them in such way. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Denis Efremov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 507d34bf74e3cef390d74b180ed9695e6bf3dcbb Author: Olaf Hering <[mailto:olaf@aepfle.de]> Date: Sun Feb 3 17:22:37 2013 -0800 x86: Hyper-V: register clocksource only if its advertised commit 32068f6527b8f1822a30671dedaf59c567325026 upstream. Enable hyperv_clocksource only if its advertised as a feature. XenServer 6 returns the signature which is checked in ms_hyperv_platform(), but it does not offer all features. Currently the clocksource is enabled unconditionally in ms_hyperv_init_platform(), and the result is a hanging guest. Hyper-V spec Bit 1 indicates the availability of Partition Reference Counter. Register the clocksource only if this bit is set. The guest in question prints this in dmesg: [ 0.000000] Hypervisor detected: Microsoft HyperV [ 0.000000] HyperV: features 0x70, hints 0x0 This bug can be reproduced easily be setting 'viridian=1' in a HVM domU .cfg file. A workaround without this patch is to boot the HVM guest with 'clocksource=jiffies'. Signed-off-by: Olaf Hering Link: http://lkml.kernel.org/r/1359940959-32168-1-git-send-email-kys@microsoft.com Signed-off-by: K. Y. Srinivasan Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit dd9c58a90c955ae794c1080156db8d8f64a52a21 Author: Leonid Shatz Date: Mon Feb 4 14:33:37 2013 +0200 hrtimer: Prevent hrtimer_enqueue_reprogram race commit b22affe0aef429d657bc6505aacb1c569340ddd2 upstream. hrtimer_enqueue_reprogram contains a race which could result in timer.base switch during unlock/lock sequence. hrtimer_enqueue_reprogram is releasing the lock protecting the timer base for calling raise_softirq_irqsoff() due to a lock ordering issue versus rq->lock. If during that time another CPU calls __hrtimer_start_range_ns() on the same hrtimer, the timer base might switch, before the current CPU can lock base->lock again and therefor the unlock_timer_base() call will unlock the wrong lock. [ tglx: Added comment and massaged changelog ] Signed-off-by: Leonid Shatz Signed-off-by: Izik Eidus Cc: Andrea Arcangeli Link: http://lkml.kernel.org/r/1359981217-389-1-git-send-email-izik.eidus@ravellosystems.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 7c3e516d99265e4aa915f3c05611b0f426bf8ce3 Author: Stanislaw Gruszka Date: Fri Feb 15 11:08:11 2013 +0100 posix-cpu-timers: Fix nanosleep task_struct leak commit e6c42c295e071dd74a66b5a9fcf4f44049888ed8 upstream. The trinity fuzzer triggered a task_struct reference leak via clock_nanosleep with CPU_TIMERs. do_cpu_nanosleep() calls posic_cpu_timer_create(), but misses a corresponding posix_cpu_timer_del() which leads to the task_struct reference leak. Reported-and-tested-by: Tommi Rantala Signed-off-by: Stanislaw Gruszka Cc: Dave Jones Cc: John Stultz Cc: Oleg Nesterov Link: http://lkml.kernel.org/r/20130215100810.GF4392@redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit b3c57f009cfd9ed81737169c4026bfd03191d993 Author: Thomas Gleixner Date: Fri Nov 23 10:08:44 2012 +0100 genirq: Avoid deadlock in spurious handling commit e716efde75267eab919cdb2bef5b2cb77f305326 upstream. commit 52553ddf(genirq: fix regression in irqfixup, irqpoll) introduced a potential deadlock by calling the action handler with the irq descriptor lock held. Remove the call and let the handling code run even for an interrupt where only a single action is registered. That matches the goal of the above commit and avoids the deadlock. Document the confusing action = desc->action reload in the handling loop while at it. Reported-and-tested-by: "Wang, Warner" Tested-by: Edward Donovan Cc: "Wang, Song-Bo (Stoney)" Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 526a26556b9069238ea7eecb9095cc672daef0e5 Author: H. Peter Anvin Date: Thu Feb 7 17:14:08 2013 -0800 timeconst.pl: Eliminate Perl warning commit 63a3f603413ffe82ad775f2d62a5afff87fd94a0 upstream. defined(@array) is deprecated in Perl and gives off a warning. Restructure the code to remove that warning. [ hpa: it would be interesting to revert to the timeconst.bc script. It appears that the failures reported by akpm during testing of that script was due to a known broken version of make, not a problem with bc. The Makefile rules could probably be restructured to avoid the make bug, or it is probably old enough that it doesn't matter. ] Reported-by: Andi Kleen Signed-off-by: H. Peter Anvin Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 17c2f96bd1de5999900303b3eb923b8cdf6ee2ba Author: Linus Torvalds Date: Mon Feb 18 09:58:02 2013 -0800 mm: fix pageblock bitmap allocation commit 7c45512df987c5619db041b5c9b80d281e26d3db upstream. Commit c060f943d092 ("mm: use aligned zone start for pfn_to_bitidx calculation") fixed out calculation of the index into the pageblock bitmap when a !SPARSEMEM zome was not aligned to pageblock_nr_pages. However, the _allocation_ of that bitmap had never taken this alignment requirement into accout, so depending on the exact size and alignment of the zone, the use of that index could then access past the allocation, resulting in some very subtle memory corruption. This was reported (and bisected) by Ingo Molnar: one of his random config builds would hang with certain very specific kernel command line options. In the meantime, commit c060f943d092 has been marked for stable, so this fix needs to be back-ported to the stable kernels that backported the commit to use the right alignment. Bisected-and-tested-by: Ingo Molnar Acked-by: Mel Gorman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5c444ede11d516377ec6a3230d450441f46cfb4f Author: H. Peter Anvin Date: Thu Jan 31 14:00:48 2013 -0800 x86-32, mm: Remove reference to alloc_remap() commit 07f4207a305c834f528d08428df4531744e25678 upstream. We have removed the remap allocator for x86-32, and x86-64 never had it (and doesn't need it). Remove residual reference to it. Reported-by: Yinghai Lu Signed-off-by: H. Peter Anvin Cc: Dave Hansen Link: http://lkml.kernel.org/r/CAE9FiQVn6_QZi3fNQ-JHYiR-7jeDJ5hT0SyT_%2BzVvfOj=PzF3w@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit 99867c9603b88d11ef8c7223b978d389fcb8e4c6 Author: H. Peter Anvin Date: Thu Jan 31 13:53:10 2013 -0800 x86-32, mm: Remove reference to resume_map_numa_kva() commit bb112aec5ee41427e9b9726e3d57b896709598ed upstream. Remove reference to removed function resume_map_numa_kva(). Signed-off-by: H. Peter Anvin Cc: Dave Hansen Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com Signed-off-by: Greg Kroah-Hartman commit 025cee7f8fef02af09b03c8e1cd9843cb32adf9b Author: Dave Hansen Date: Wed Jan 30 16:56:16 2013 -0800 x86-32, mm: Rip out x86_32 NUMA remapping code commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream. This code was an optimization for 32-bit NUMA systems. It has probably been the cause of a number of subtle bugs over the years, although the conditions to excite them would have been hard to trigger. Essentially, we remap part of the kernel linear mapping area, and then sometimes part of that area gets freed back in to the bootmem allocator. If those pages get used by kernel data structures (say mem_map[] or a dentry), there's no big deal. But, if anyone ever tried to use the linear mapping for these pages _and_ cared about their physical address, bad things happen. For instance, say you passed __GFP_ZERO to the page allocator and then happened to get handed one of these pages, it zero the remapped page, but it would make a pte to the _old_ page. There are probably a hundred other ways that it could screw with things. We don't need to hang on to performance optimizations for these old boxes any more. All my 32-bit NUMA systems are long dead and buried, and I probably had access to more than most people. This code is causing real things to break today: https://lkml.org/lkml/2013/1/9/376 I looked in to actually fixing this, but it requires surgery to way too much brittle code, as well as stuff like per_cpu_ptr_to_phys(). [ hpa: Cc: this for -stable, since it is a memory corruption issue. However, an alternative is to simply mark NUMA as depends BROKEN rather than EXPERIMENTAL in the X86_32 subclause... ] Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman