commit 72c0f4193873987686d776813b96ef5e17b060b0 Author: Greg Kroah-Hartman Date: Sat May 31 12:41:04 2014 -0700 Linux 3.10.41 commit 42f6bc6cc89d4ee5cb4993ea818abdac15f3de17 Author: Bjørn Mork Date: Fri Apr 25 19:00:34 2014 +0200 net: qmi_wwan: add a number of Dell devices [ Upstream commit 6f10c5d1b1aeddb63d33070abb8bc5a177beeb1f ] Dan writes: "The Dell drivers use the same configuration for PIDs: 81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card 81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card 81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card 81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card 81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card These devices are all clearly Sierra devices, but are also definitely Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750. >From DellGobi5kSetup.exe from the Dell drivers: usbif0: serial/firmware loader? usbif2: nmea usbif3: modem/ppp usbif8: net/QMI" Reported-by: AceLan Kao Reported-by: Dan Williams Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bba6bf92d366754bd6d38ead630e79e0931d5882 Author: Bjørn Mork Date: Fri Apr 25 19:00:33 2014 +0200 net: qmi_wwan: add a number of CMOTech devices [ Upstream commit 41be7d90993b1502d445bfc59e58348c258ce66a ] A number of older CMOTech modems are based on Qualcomm chips and exporting a QMI/wwan function. Reported-by: Lars Melin Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7f5aae1811e48982998002c844773a70f6b3e4d3 Author: Bjørn Mork Date: Fri Apr 25 19:00:32 2014 +0200 net: qmi_wwan: add Alcatel L800MA [ Upstream commit 75573660c47a0db7cc931dcf154945610e02130a ] Device interface layout: 0: ff/ff/ff - serial 1: ff/00/00 - serial AT+PPP 2: ff/ff/ff - QMI/wwan 3: 08/06/50 - storage Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 499c5ec702fb9733776a735df2a254d223e9bd72 Author: Bjørn Mork Date: Fri Apr 25 19:00:31 2014 +0200 net: qmi_wwan: add Olivetti Olicard 500 [ Upstream commit efc0b25c3add97717ece57bf5319792ca98f348e ] Device interface layout: 0: ff/ff/ff - serial 1: ff/ff/ff - serial AT+PPP 2: 08/06/50 - storage 3: ff/ff/ff - serial 4: ff/ff/ff - QMI/wwan Reported-by: Julio Araujo Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3479cf433eb04a5be0ff5927c7debf2cb94d33f0 Author: Bjørn Mork Date: Fri Apr 25 19:00:30 2014 +0200 net: qmi_wwan: add Sierra Wireless MC7305/MC7355 [ Upstream commit 9214224e43e4264b02686ea8b455f310935607b5 ] Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b859cc11f3aba6289e683b80c78a294333830844 Author: Bjørn Mork Date: Fri Apr 25 19:00:29 2014 +0200 net: qmi_wwan: add Sierra Wireless MC73xx [ Upstream commit 1c138607a7be64074d7fba68d0d533ec38f9d17b ] Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 36b73cc01f11f18af837f9a898041f899057bc29 Author: Bjørn Mork Date: Fri Apr 25 19:00:28 2014 +0200 net: qmi_wwan: add Sierra Wireless EM7355 [ Upstream commit b85f5deaf052340021d025e120a9858f084a1d79 ] Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 59938f4f489c0c9d1ebcec9e4fd597ac865b0594 Author: Aleksander Morgado Date: Wed Feb 12 15:55:14 2014 +0100 net: qmi_wwan: add support for Cinterion PXS8 and PHS8 [ Upstream commit 9b2b6a2d669c909dd0b125fc834da94bcfc0aee7 ] When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a QMI port and a WWAN interface. CC: Hans-Christoph Schemmel CC: Christian Schmiedl CC: Nicolaus Colberg CC: David McCullough Signed-off-by: Aleksander Morgado Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 82002e24bd0dd0e033ed791984a347374236a920 Author: Raymond Wanyoike Date: Sun Feb 9 00:01:02 2014 +0300 net: qmi_wwan: add ZTE MF667 [ Upstream commit 7653aabfbdc73c1567e29a9790701f5898ba1420 ] The driver description files give these descriptions to the vendor specific ports on this modem: VID_19D2&PID_1270&MI_00: "ZTE MF667 Diagnostics Port" VID_19D2&PID_1270&MI_01: "ZTE MF667 AT Port" VID_19D2&PID_1270&MI_02: "ZTE MF667 ATExt2 Port" VID_19D2&PID_1270&MI_03: "ZTE MF667 ATExt Port" VID_19D2&PID_1270&MI_04: "ZTE MF667 USB Modem" VID_19D2&PID_1270&MI_05: "ZTE MF667 Network Adapter" Signed-off-by: Raymond Wanyoike Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4215770e625f9749f09a4a6d2b15b9b5e4c3e8ee Author: Enrico Mioso Date: Tue Oct 15 15:06:48 2013 +0200 net: qmi_wwan: Olivetti Olicard 200 support [ Upstream commit ce97fef4235378108ed3bd96e1b3eab8fd0a1fbd ] This is a QMI device, manufactured by TCT Mobile Phones. A companion patch blacklisting this device's QMI interface in the option.c driver has been sent. Signed-off-by: Enrico Mioso Signed-off-by: Antonella Pellizzari Tested-by: Dan Williams Acked-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a82172d5c173b63971f872fe3e152ac7a0f1abed Author: Aleksander Morgado Date: Wed Sep 25 17:02:36 2013 +0200 net: qmi_wwan: fix Cinterion PLXX product ID [ Upstream commit 2d77f343343c4f38b8f94be1964bbbc6456a147f ] Cinterion PLXX LTE devices have a 0x0060 product ID, not 0x12d1. The blacklisting in the serial/option driver does actually use the correct PID, as per commit 8ff10bdb14a52e3f25d4ce09e0582a8684c1a6db ('USB: Blacklisted Cinterion's PLxx WWAN Interface'). CC: Hans-Christoph Schemmel CC: Christian Schmiedl CC: Nicolaus Colberg Signed-off-by: Aleksander Morgado Acked-by: Bjørn Mork Acked-by: Christian Schmiedl Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 540c709a2b761f7b474ef5f5d66a546a07808e1a Author: Fabio Porcedda Date: Wed Sep 25 11:21:25 2013 +0200 net: qmi_wwan: add Telit LE920 newer firmware support [ Upstream commit 905468fa4d54c3e572ed3045cd47cce37780716e ] Newer firmware use a new pid and a different interface. Signed-off-by: Fabio Porcedda Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7a055bb354443b753f5753c80334442d1c52a0c Author: Enrico Mioso Date: Sat Jun 29 15:39:19 2013 +0200 qmi_wwan: add ONDA MT689DC device ID (fwd) [ Upstream commit d8eb8f9963a55ccf6ebafa4bfdb9f70c17067825 ] Another QMI-speaking device by ZTE, re-branded by ONDA! I'm connected ovr this device's QMI interface right now, so I can say I tested it! :) Note: a follow-up patch was posted to the linux-usb mailing list, to prevent the option driver from binding to the device's QMI interface, making it unusable. Signed-off-by: Enrico Mioso Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit df99837b6180a6491d3660fad220391cddf21ddc Author: Bjørn Mork Date: Fri Jun 28 17:17:51 2013 +0200 net: qmi_wwan: add TP-LINK MA260 [ Upstream commit d0b5e516298fba30774e2df22cfbd00ecb09c298 ] Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 61fd33e7db4e9bbd1f279fa220879763bd23c404 Author: Bjørn Mork Date: Fri Jun 28 17:17:50 2013 +0200 net: qmi_wwan: add Option GTM681W [ Upstream commit aa3aba1cbcbe823bba623c7cab33d84ddf0fb6cd ] A standard Gobi 3000 reference design module. Reported-by: Richard Weinberger Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b1cf31e9d3de759e7ee0e9cc3e2b8e350fcbaa3c Author: Bjørn Mork Date: Fri Jun 28 17:17:49 2013 +0200 net: qmi_wwan: fixup Sierra Wireless MC8305 entry [ Upstream commit 5a008ffa73b4401251d548c10cadac6f8a67cfb5 ] The MC8305 module got an additional entry added based solely on information from a Windows driver *.inf file. We now have the actual descriptor layout from one of these modules, and it consists of two alternate configurations where cfg #1 is a normal Gobi 2k layout and cfg #2 is MBIM only, using interface numbers 5 and 6 for MBIM control and data. The extra Windows driver entry for interface number 5 was most likely a bug. Deleting the bogus entry to avoid unnecessary qmi_wwan probe failures when using the MBIM configuration. Reported-by: Lana Black Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fd6b1194f0096af91c6e2b31065f5f9d2b066d80 Author: Eric Dumazet Date: Thu Apr 3 09:28:10 2014 -0700 net-gro: reset skb->truesize in napi_reuse_skb() [ Upstream commit e33d0ba8047b049c9262fdb1fcafb93cb52ceceb ] Recycling skb always had been very tough... This time it appears GRO layer can accumulate skb->truesize adjustments made by drivers when they attach a fragment to skb. skb_gro_receive() can only subtract from skb->truesize the used part of a fragment. I spotted this problem seeing TcpExtPruneCalled and TcpExtTCPRcvCollapsed that were unexpected with a recent kernel, where TCP receive window should be sized properly to accept traffic coming from a driver not overshooting skb->truesize. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 809d0bf75e96b1f9241e58e9d6ef64d1de8ce053 Author: Li RongQing Date: Thu May 22 16:36:55 2014 +0800 ipv4: initialise the itag variable in __mkroute_input [ Upstream commit fbdc0ad095c0a299e9abf5d8ac8f58374951149a ] the value of itag is a random value from stack, and may not be initiated by fib_validate_source, which called fib_combine_itag if CONFIG_IP_ROUTE_CLASSID is not set This will make the cached dst uncertainty Signed-off-by: Li RongQing Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4cba246ac61971484e454ee16efabb51e7452572 Author: Susant Sahani Date: Sat May 10 00:11:32 2014 +0530 ip6_tunnel: fix potential NULL pointer dereference [ Upstream commit c8965932a2e3b70197ec02c6741c29460279e2a8 ] The function ip6_tnl_validate assumes that the rtnl attribute IFLA_IPTUN_PROTO always be filled . If this attribute is not filled by the userspace application kernel get crashed with NULL pointer dereference. This patch fixes the potential kernel crash when IFLA_IPTUN_PROTO is missing . Signed-off-by: Susant Sahani Acked-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8b64afaca4d6cb80d0d1b2a4651b1efb7231f220 Author: Peter Christensen Date: Thu May 8 11:15:37 2014 +0200 macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces. [ Upstream commit bbeb0eadcf9fe74fb2b9b1a6fea82cd538b1e556 ] Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti overflow on the underlying interface. Attempting the set IFF_ALLMULTI on the underlying interface would cause an error and the log message: "allmulti touches root, set allmulti failed." Signed-off-by: Peter Christensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b237dc48b3c64aa48c822e0387d9ea1d00714dcb Author: Bjørn Mork Date: Fri May 9 14:45:00 2014 +0200 net: cdc_mbim: handle unaccelerated VLAN tagged frames [ Upstream commit 6b5eeb7f874b689403e52a646e485d0191ab9507 ] This driver maps 802.1q VLANs to MBIM sessions. The mapping is based on a bogus assumption that all tagged frames will use the acceleration API because we enable NETIF_F_HW_VLAN_CTAG_TX. This fails for e.g. frames tagged in userspace using packet sockets. Such frames will erroneously be considered as untagged and silently dropped based on not being IP. Fix by falling back to looking into the ethernet header for a tag if no accelerated tag was found. Fixes: a82c7ce5bc5b ("net: cdc_ncm: map MBIM IPS SessionID to VLAN ID") Cc: Greg Suarez Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6e020d8ab8dad5c4ebb5317898d05d437a6f5c49 Author: Sergey Popovich Date: Tue May 6 18:23:08 2014 +0300 ipv4: fib_semantics: increment fib_info_cnt after fib_info allocation [ Upstream commit aeefa1ecfc799b0ea2c4979617f14cecd5cccbfd ] Increment fib_info_cnt in fib_create_info() right after successfuly alllocating fib_info structure, overwise fib_metrics allocation failure leads to fib_info_cnt incorrectly decremented in free_fib_info(), called on error path from fib_create_info(). Signed-off-by: Sergey Popovich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bbdd224c0ad28a77161aeb8c45d34fe0928ef997 Author: Florian Westphal Date: Mon May 5 00:03:34 2014 +0200 net: ipv6: send pkttoobig immediately if orig frag size > mtu [ Upstream commit 418a31561d594a2b636c1e2fa94ecd9e1245abb1 ] If conntrack defragments incoming ipv6 frags it stores largest original frag size in ip6cb and sets ->local_df. We must thus first test the largest original frag size vs. mtu, and not vice versa. Without this patch PKTTOOBIG is still generated in ip6_fragment() later in the stack, but 1) IPSTATS_MIB_INTOOBIGERRORS won't increment 2) packet did (needlessly) traverse netfilter postrouting hook. Fixes: fe6cc55f3a9 ("net: ip, ipv6: handle gso skbs in forwarding path") Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5478c9cb6b408df9d649e73816d23c40aa7d6d4b Author: Florian Westphal Date: Sun May 4 23:24:31 2014 +0200 net: ipv4: ip_forward: fix inverted local_df test [ Upstream commit ca6c5d4ad216d5942ae544bbf02503041bd802aa ] local_df means 'ignore DF bit if set', so if its set we're allowed to perform ip fragmentation. This wasn't noticed earlier because the output path also drops such skbs (and emits needed icmp error) and because netfilter ip defrag did not set local_df until couple of days ago. Only difference is that DF-packets-larger-than MTU now discarded earlier (f.e. we avoid pointless netfilter postrouting trip). While at it, drop the repeated test ip_exceeds_mtu, checking it once is enough... Fixes: fe6cc55f3a9 ("net: ip, ipv6: handle gso skbs in forwarding path") Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28e00c4c37f1100394928e28e7fcdc58640440aa Author: Liu Yu Date: Wed Apr 30 17:34:09 2014 +0800 tcp_cubic: fix the range of delayed_ack [ Upstream commit 0cda345d1b2201dd15591b163e3c92bad5191745 ] commit b9f47a3aaeab (tcp_cubic: limit delayed_ack ratio to prevent divide error) try to prevent divide error, but there is still a little chance that delayed_ack can reach zero. In case the param cnt get negative value, then ratio+cnt would overflow and may happen to be zero. As a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero. In some old kernels, such as 2.6.32, there is a bug that would pass negative param, which then ultimately leads to this divide error. commit 5b35e1e6e9c (tcp: fix tcp_trim_head() to adjust segment count with skb MSS) fixed the negative param issue. However, it's safe that we fix the range of delayed_ack as well, to make sure we do not hit a divide by zero. CC: Stephen Hemminger Signed-off-by: Liu Yu Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eb964f9d22544a002acc363c393955d85d4d0385 Author: Vlad Yasevich Date: Tue Apr 29 10:09:51 2014 -0400 Revert "macvlan : fix checksums error when we are in bridge mode" [ Upstream commit f114890cdf84d753f6b41cd0cc44ba51d16313da ] This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019. The commit above doesn't appear to be necessary any more as the checksums appear to be correctly computed/validated. Additionally the above commit breaks kvm configurations where one VM is using a device that support checksum offload (virtio) and the other VM does not. In this case, packets leaving virtio device will have CHECKSUM_PARTIAL set. The packets is forwarded to a macvtap that has offload features turned off. Since we use CHECKSUM_UNNECESSARY, the host does does not update the checksum and thus a bad checksum is passed up to the guest. CC: Daniel Lezcano CC: Patrick McHardy CC: Andrian Nord CC: Eric Dumazet CC: Michael S. Tsirkin CC: Jason Wang Signed-off-by: Vlad Yasevich Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4de3e298aa5eaf1982c4068d76a2246054eed34c Author: Xufeng Zhang Date: Fri Apr 25 16:55:41 2014 +0800 sctp: reset flowi4_oif parameter on route lookup [ Upstream commit 85350871317a5adb35519d9dc6fc9e80809d42ad ] commit 813b3b5db83 (ipv4: Use caller's on-stack flowi as-is in output route lookups.) introduces another regression which is very similar to the problem of commit e6b45241c (ipv4: reset flowi parameters on route connect) wants to fix: Before we call ip_route_output_key() in sctp_v4_get_dst() to get a dst that matches a bind address as the source address, we have already called this function previously and the flowi parameters have been initialized including flowi4_oif, so when we call this function again, the process in __ip_route_output_key() will be different because of the setting of flowi4_oif, and we'll get a networking device which corresponds to the inputted flowi4_oif as the output device, this is wrong because we'll never hit this place if the previously returned source address of dst match one of the bound addresses. To reproduce this problem, a vlan setting is enough: # ifconfig eth0 up # route del default # vconfig add eth0 2 # vconfig add eth0 3 # ifconfig eth0.2 10.0.1.14 netmask 255.255.255.0 # route add default gw 10.0.1.254 dev eth0.2 # ifconfig eth0.3 10.0.0.14 netmask 255.255.255.0 # ip rule add from 10.0.0.14 table 4 # ip route add table 4 default via 10.0.0.254 src 10.0.0.14 dev eth0.3 # sctp_darn -H 10.0.0.14 -P 36422 -h 10.1.4.134 -p 36422 -s -I You'll detect that all the flow are routed to eth0.2(10.0.1.254). Signed-off-by: Xufeng Zhang Signed-off-by: Julian Anastasov Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28ad29fc24863062b43c0893f8475bedb38d4862 Author: Toshiaki Makita Date: Fri Apr 25 17:01:18 2014 +0900 bridge: Handle IFLA_ADDRESS correctly when creating bridge device [ Upstream commit 30313a3d5794472c3548d7288e306a5492030370 ] When bridge device is created with IFLA_ADDRESS, we are not calling br_stp_change_bridge_id(), which leads to incorrect local fdb management and bridge id calculation, and prevents us from receiving frames on the bridge device. Reported-by: Tom Gundersen Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 83445f0d5cd735169879d9e1179d1d35d559ea07 Author: Kumar Sundararajan Date: Thu Apr 24 09:48:53 2014 -0400 ipv6: fib: fix fib dump restart [ Upstream commit 1c2658545816088477e91860c3a645053719cb54 ] When the ipv6 fib changes during a table dump, the walk is restarted and the number of nodes dumped are skipped. But the existing code doesn't advance to the next node after a node is skipped. This can cause the dump to loop or produce lots of duplicates when the fib is modified during the dump. This change advances the walk to the next node if the current node is skipped after a restart. Signed-off-by: Kumar Sundararajan Signed-off-by: Chris Mason Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fd9fcd8adba8d772582b13a4cf56896721f740af Author: David Gibson Date: Thu Apr 24 10:22:36 2014 +1000 rtnetlink: Only supply IFLA_VF_PORTS information when RTEXT_FILTER_VF is set [ Upstream commit c53864fd60227de025cb79e05493b13f69843971 ] Since 115c9b81928360d769a76c632bae62d15206a94a (rtnetlink: Fix problem with buffer allocation), RTM_NEWLINK messages only contain the IFLA_VFINFO_LIST attribute if they were solicited by a GETLINK message containing an IFLA_EXT_MASK attribute with the RTEXT_FILTER_VF flag. That was done because some user programs broke when they received more data than expected - because IFLA_VFINFO_LIST contains information for each VF it can become large if there are many VFs. However, the IFLA_VF_PORTS attribute, supplied for devices which implement ndo_get_vf_port (currently the 'enic' driver only), has the same problem. It supplies per-VF information and can therefore become large, but it is not currently conditional on the IFLA_EXT_MASK value. Worse, it interacts badly with the existing EXT_MASK handling. When IFLA_EXT_MASK is not supplied, the buffer for netlink replies is fixed at NLMSG_GOODSIZE. If the information for IFLA_VF_PORTS exceeds this, then rtnl_fill_ifinfo() returns -EMSGSIZE on the first message in a packet. netlink_dump() will misinterpret this as having finished the listing and omit data for this interface and all subsequent ones. That can cause getifaddrs(3) to enter an infinite loop. This patch addresses the problem by only supplying IFLA_VF_PORTS when IFLA_EXT_MASK is supplied with the RTEXT_FILTER_VF flag set. Signed-off-by: David Gibson Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1ab27dd7edb75bc3034daab503a912647bdf95ba Author: David Gibson Date: Thu Apr 24 10:22:35 2014 +1000 rtnetlink: Warn when interface's information won't fit in our packet [ Upstream commit 973462bbde79bb827824c73b59027a0aed5c9ca6 ] Without IFLA_EXT_MASK specified, the information reported for a single interface in response to RTM_GETLINK is expected to fit within a netlink packet of NLMSG_GOODSIZE. If it doesn't, however, things will go badly wrong, When listing all interfaces, netlink_dump() will incorrectly treat -EMSGSIZE on the first message in a packet as the end of the listing and omit information for that interface and all subsequent ones. This can cause getifaddrs(3) to enter an infinite loop. This patch won't fix the problem, but it will WARN_ON() making it easier to track down what's going wrong. Signed-off-by: David Gibson Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eac664d2832178c1d3a5e7560a26c10001717b77 Author: Andrew Lutomirski Date: Wed Apr 16 21:41:34 2014 -0700 net: Fix ns_capable check in sock_diag_put_filterinfo [ Upstream commit 78541c1dc60b65ecfce5a6a096fc260219d6784e ] The caller needs capabilities on the namespace being queried, not on their own namespace. This is a security bug, although it likely has only a minor impact. Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e5eae4a0511241959498b180fa0df0d4f1b11b9c Author: Vlad Yasevich Date: Thu Apr 17 17:26:50 2014 +0200 net: sctp: cache auth_enable per endpoint [ Upstream commit b14878ccb7fac0242db82720b784ab62c467c0dc ] Currently, it is possible to create an SCTP socket, then switch auth_enable via sysctl setting to 1 and crash the system on connect: Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.1-mipsgit-20140415 #1 task: ffffffff8056ce80 ti: ffffffff8055c000 task.ti: ffffffff8055c000 [...] Call Trace: [] sctp_auth_asoc_set_default_hmac+0x68/0x80 [] sctp_process_init+0x5e0/0x8a4 [] sctp_sf_do_5_1B_init+0x234/0x34c [] sctp_do_sm+0xb4/0x1e8 [] sctp_endpoint_bh_rcv+0x1c4/0x214 [] sctp_rcv+0x588/0x630 [] sctp6_rcv+0x10/0x24 [] ip6_input+0x2c0/0x440 [] __netif_receive_skb_core+0x4a8/0x564 [] process_backlog+0xb4/0x18c [] net_rx_action+0x12c/0x210 [] __do_softirq+0x17c/0x2ac [] irq_exit+0x54/0xb0 [] ret_from_irq+0x0/0x4 [] rm7k_wait_irqoff+0x24/0x48 [] cpu_startup_entry+0xc0/0x148 [] start_kernel+0x37c/0x398 Code: dd0900b8 000330f8 0126302d 50c0fff1 0047182a a48306a0 03e00008 00000000 ---[ end trace b530b0551467f2fd ]--- Kernel panic - not syncing: Fatal exception in interrupt What happens while auth_enable=0 in that case is, that ep->auth_hmacs is initialized to NULL in sctp_auth_init_hmacs() when endpoint is being created. After that point, if an admin switches over to auth_enable=1, the machine can crash due to NULL pointer dereference during reception of an INIT chunk. When we enter sctp_process_init() via sctp_sf_do_5_1B_init() in order to respond to an INIT chunk, the INIT verification succeeds and while we walk and process all INIT params via sctp_process_param() we find that net->sctp.auth_enable is set, therefore do not fall through, but invoke sctp_auth_asoc_set_default_hmac() instead, and thus, dereference what we have set to NULL during endpoint initialization phase. The fix is to make auth_enable immutable by caching its value during endpoint initialization, so that its original value is being carried along until destruction. The bug seems to originate from the very first days. Fix in joint work with Daniel Borkmann. Reported-by: Joshua Kinard Signed-off-by: Vlad Yasevich Signed-off-by: Daniel Borkmann Acked-by: Neil Horman Tested-by: Joshua Kinard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d923c843eb608bf84456969a6f19e50c39835343 Author: Ivan Vecera Date: Thu Apr 17 14:51:08 2014 +0200 tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled The patch fixes a problem with dropped jumbo frames after usage of 'ethtool -G ... rx'. Scenario: 1. ip link set eth0 up 2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo 3. ip link set mtu 9000 dev eth0 The ethtool command set rx_jumbo_pending to zero so any received jumbo packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N' to workaround the issue. The patch changes the logic so rx_jumbo_pending value is changed only if jumbo frames are enabled (MTU > 1500). Signed-off-by: Ivan Vecera Acked-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bc433f76e505044349bcde41e80aa0135aa9d46b Author: dingtianhong Date: Thu Apr 17 18:40:36 2014 +0800 vlan: Fix lockdep warning when vlan dev handle notification [ Upstream commit dc8eaaa006350d24030502a4521542e74b5cb39f ] When I open the LOCKDEP config and run these steps: modprobe 8021q vconfig add eth2 20 vconfig add eth2.20 30 ifconfig eth2 xx.xx.xx.xx then the Call Trace happened: [32524.386288] ============================================= [32524.386293] [ INFO: possible recursive locking detected ] [32524.386298] 3.14.0-rc2-0.7-default+ #35 Tainted: G O [32524.386302] --------------------------------------------- [32524.386306] ifconfig/3103 is trying to acquire lock: [32524.386310] (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_mc_sync+0x64/0xb0 [32524.386326] [32524.386326] but task is already holding lock: [32524.386330] (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_set_rx_mode+0x23/0x40 [32524.386341] [32524.386341] other info that might help us debug this: [32524.386345] Possible unsafe locking scenario: [32524.386345] [32524.386350] CPU0 [32524.386352] ---- [32524.386354] lock(&vlan_netdev_addr_lock_key/1); [32524.386359] lock(&vlan_netdev_addr_lock_key/1); [32524.386364] [32524.386364] *** DEADLOCK *** [32524.386364] [32524.386368] May be due to missing lock nesting notation [32524.386368] [32524.386373] 2 locks held by ifconfig/3103: [32524.386376] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20 [32524.386387] #1: (&vlan_netdev_addr_lock_key/1){+.....}, at: [] dev_set_rx_mode+0x23/0x40 [32524.386398] [32524.386398] stack backtrace: [32524.386403] CPU: 1 PID: 3103 Comm: ifconfig Tainted: G O 3.14.0-rc2-0.7-default+ #35 [32524.386409] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [32524.386414] ffffffff81ffae40 ffff8800d9625ae8 ffffffff814f68a2 ffff8800d9625bc8 [32524.386421] ffffffff810a35fb ffff8800d8a8d9d0 00000000d9625b28 ffff8800d8a8e5d0 [32524.386428] 000003cc00000000 0000000000000002 ffff8800d8a8e5f8 0000000000000000 [32524.386435] Call Trace: [32524.386441] [] dump_stack+0x6a/0x78 [32524.386448] [] __lock_acquire+0x7ab/0x1940 [32524.386454] [] ? __lock_acquire+0x3ea/0x1940 [32524.386459] [] lock_acquire+0xe4/0x110 [32524.386464] [] ? dev_mc_sync+0x64/0xb0 [32524.386471] [] _raw_spin_lock_nested+0x2a/0x40 [32524.386476] [] ? dev_mc_sync+0x64/0xb0 [32524.386481] [] dev_mc_sync+0x64/0xb0 [32524.386489] [] vlan_dev_set_rx_mode+0x2b/0x50 [8021q] [32524.386495] [] __dev_set_rx_mode+0x5f/0xb0 [32524.386500] [] dev_set_rx_mode+0x2b/0x40 [32524.386506] [] __dev_open+0xef/0x150 [32524.386511] [] __dev_change_flags+0xa7/0x190 [32524.386516] [] dev_change_flags+0x32/0x80 [32524.386524] [] devinet_ioctl+0x7d6/0x830 [32524.386532] [] ? dev_ioctl+0x34b/0x660 [32524.386540] [] inet_ioctl+0x80/0xa0 [32524.386550] [] sock_do_ioctl+0x2d/0x60 [32524.386558] [] sock_ioctl+0x82/0x2a0 [32524.386568] [] do_vfs_ioctl+0x93/0x590 [32524.386578] [] ? rcu_read_lock_held+0x45/0x50 [32524.386586] [] ? __fget_light+0x105/0x110 [32524.386594] [] SyS_ioctl+0x91/0xb0 [32524.386604] [] system_call_fastpath+0x16/0x1b ======================================================================== The reason is that all of the addr_lock_key for vlan dev have the same class, so if we change the status for vlan dev, the vlan dev and its real dev will hold the same class of addr_lock_key together, so the warning happened. we should distinguish the lock depth for vlan dev and its real dev. v1->v2: Convert the vlan_netdev_addr_lock_key to an array of eight elements, which could support to add 8 vlan id on a same vlan dev, I think it is enough for current scene, because a netdev's name is limited to IFNAMSIZ which could not hold 8 vlan id, and the vlan dev would not meet the same class key with its real dev. The new function vlan_dev_get_lockdep_subkey() will return the subkey and make the vlan dev could get a suitable class key. v2->v3: According David's suggestion, I use the subclass to distinguish the lock key for vlan dev and its real dev, but it make no sense, because the difference for subclass in the lock_class_key doesn't mean that the difference class for lock_key, so I use lock_depth to distinguish the different depth for every vlan dev, the same depth of the vlan dev could have the same lock_class_key, I import the MAX_LOCK_DEPTH from the include/linux/sched.h, I think it is enough here, the lockdep should never exceed that value. v3->v4: Add a huge array of locking keys will waste static kernel memory and is not a appropriate method, we could use _nested() variants to fix the problem, calculate the depth for every vlan dev, and use the depth as the subclass for addr_lock_key. Signed-off-by: Ding Tianhong Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 278d20a5318e5f2ad30be49607da867ff9ff8b03 Author: Nicolas Dichtel Date: Mon Apr 14 17:11:38 2014 +0200 ip6_gre: don't allow to remove the fb_tunnel_dev [ Upstream commit 54d63f787b652755e66eb4dd8892ee6d3f5197fc ] It's possible to remove the FB tunnel with the command 'ip link del ip6gre0' but this is unsafe, the module always supposes that this device exists. For example, ip6gre_tunnel_lookup() may use it unconditionally. Let's add a rtnl handler for dellink, which will never remove the FB tunnel (we let ip6gre_destroy_tunnels() do the job). Introduced by commit c12b395a4664 ("gre: Support GRE over IPv6"). CC: Dmitry Kozlov Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 314760e66c35c8ffa51b4c4ca6948d207e783079 Author: Mathias Krause Date: Sun Apr 13 18:23:33 2014 +0200 filter: prevent nla extensions to peek beyond the end of the message [ Upstream commit 05ab8f2647e4221cbdb3856dd7d32bd5407316b3 ] The BPF_S_ANC_NLATTR and BPF_S_ANC_NLATTR_NEST extensions fail to check for a minimal message length before testing the supplied offset to be within the bounds of the message. This allows the subtraction of the nla header to underflow and therefore -- as the data type is unsigned -- allowing far to big offset and length values for the search of the netlink attribute. The remainder calculation for the BPF_S_ANC_NLATTR_NEST extension is also wrong. It has the minuend and subtrahend mixed up, therefore calculates a huge length value, allowing to overrun the end of the message while looking for the netlink attribute. The following three BPF snippets will trigger the bugs when attached to a UNIX datagram socket and parsing a message with length 1, 2 or 3. ,-[ PoC for missing size check in BPF_S_ANC_NLATTR ]-- | ld #0x87654321 | ldx #42 | ld #nla | ret a `--- ,-[ PoC for the same bug in BPF_S_ANC_NLATTR_NEST ]-- | ld #0x87654321 | ldx #42 | ld #nlan | ret a `--- ,-[ PoC for wrong remainder calculation in BPF_S_ANC_NLATTR_NEST ]-- | ; (needs a fake netlink header at offset 0) | ld #0 | ldx #42 | ld #nlan | ret a `--- Fix the first issue by ensuring the message length fulfills the minimal size constrains of a nla header. Fix the second bug by getting the math for the remainder calculation right. Fixes: 4738c1db15 ("[SKFILTER]: Add SKF_ADF_NLATTR instruction") Fixes: d214c7537b ("filter: add SKF_AD_NLATTR_NEST to look for nested..") Cc: Patrick McHardy Cc: Pablo Neira Ayuso Signed-off-by: Mathias Krause Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit da1bba1f78da2ced35b8852efd922daabfc54219 Author: Julian Anastasov Date: Sun Apr 13 18:08:02 2014 +0300 ipv4: return valid RTA_IIF on ip route get [ Upstream commit 91146153da2feab18efab2e13b0945b6bb704ded ] Extend commit 13378cad02afc2adc6c0e07fca03903c7ada0b37 ("ipv4: Change rt->rt_iif encoding.") from 3.6 to return valid RTA_IIF on 'ip route get ... iif DEVICE' instead of rt_iif 0 which is displayed as 'iif *'. inet_iif is not appropriate to use because skb_iif is not set. Use the skb->dev->ifindex instead. Signed-off-by: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8dbc8dc8e84b998ca8a7394ae22614f3a58d4c38 Author: Wang, Xiaoming Date: Mon Apr 14 12:30:45 2014 -0400 net: ipv4: current group_info should be put after using. [ Upstream commit b04c46190219a4f845e46a459e3102137b7f6cac ] Plug a group_info refcount leak in ping_init. group_info is only needed during initialization and the code failed to release the reference on exit. While here move grabbing the reference to a place where it is actually needed. Signed-off-by: Chuansheng Liu Signed-off-by: Zhang Dongxing Signed-off-by: xiaoming wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4008a994ddcee13c1baa7ed8a7e66fcbddc85d29 Author: Nicolas Dichtel Date: Fri Apr 11 15:51:19 2014 +0200 vti: don't allow to add the same tunnel twice [ Upstream commit 8d89dcdf80d88007647945a753821a06eb6cc5a5 ] Before the patch, it was possible to add two times the same tunnel: ip l a vti1 type vti remote 10.16.0.121 local 10.16.0.249 key 41 ip l a vti2 type vti remote 10.16.0.121 local 10.16.0.249 key 41 It was possible, because ip_tunnel_newlink() calls ip_tunnel_find() with the argument dev->type, which was set only later (when calling ndo_init handler in register_netdevice()). Let's set this type in the setup handler, which is called before newlink handler. Introduced by commit b9959fd3b0fa ("vti: switch to new ip tunnel code"). CC: Cong Wang CC: Steffen Klassert Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5ef58c401b86c22a69e5724d783d799fa5176ce6 Author: Nicolas Dichtel Date: Fri Apr 11 15:51:18 2014 +0200 gre: don't allow to add the same tunnel twice [ Upstream commit 5a4552752d8f7f4cef1d98775ece7adb7616fde2 ] Before the patch, it was possible to add two times the same tunnel: ip l a gre1 type gre remote 10.16.0.121 local 10.16.0.249 ip l a gre2 type gre remote 10.16.0.121 local 10.16.0.249 It was possible, because ip_tunnel_newlink() calls ip_tunnel_find() with the argument dev->type, which was set only later (when calling ndo_init handler in register_netdevice()). Let's set this type in the setup handler, which is called before newlink handler. Introduced by commit c54419321455 ("GRE: Refactor GRE tunneling code."). CC: Pravin B Shelar Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 132da31a0b0143cac11799dafa961c1969ee122c Author: Eric Dumazet Date: Thu Apr 10 21:23:36 2014 -0700 ipv6: Limit mtu to 65575 bytes [ Upstream commit 30f78d8ebf7f514801e71b88a10c948275168518 ] Francois reported that setting big mtu on loopback device could prevent tcp sessions making progress. We do not support (yet ?) IPv6 Jumbograms and cook corrupted packets. We must limit the IPv6 MTU to (65535 + 40) bytes in theory. Tested: ifconfig lo mtu 70000 netperf -H ::1 Before patch : Throughput : 0.05 Mbits After patch : Throughput : 35484 Mbits Reported-by: Francois WELLENREITER Signed-off-by: Eric Dumazet Acked-by: YOSHIFUJI Hideaki Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4902599654b2e606529241d06c5748c48ed6dc87 Author: Toshiaki Makita Date: Wed Apr 9 17:00:30 2014 +0900 bridge: Fix double free and memory leak around br_allowed_ingress [ Upstream commit eb7076182d1ae4bc4641534134ed707100d76acc ] br_allowed_ingress() has two problems. 1. If br_allowed_ingress() is called by br_handle_frame_finish() and vlan_untag() in br_allowed_ingress() fails, skb will be freed by both vlan_untag() and br_handle_frame_finish(). 2. If br_allowed_ingress() is called by br_dev_xmit() and br_allowed_ingress() fails, the skb will not be freed. Fix these two problems by freeing the skb in br_allowed_ingress() if it fails. Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 91ce31b21cfd51be269746b72ae4db8ced8b6799 Author: Thomas Richter Date: Wed Apr 9 12:52:59 2014 +0200 bonding: Remove debug_fs files when module init fails [ Upstream commit db29868653394937037d71dc3545768302dda643 ] Remove the bonding debug_fs entries when the module initialization fails. The debug_fs entries should be removed together with all other already allocated resources. Signed-off-by: Thomas Richter Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8362bf4315e8fc69fd342429eb4b962a2e819df Author: Florian Westphal Date: Wed Apr 9 10:28:50 2014 +0200 net: core: don't account for udp header size when computing seglen [ Upstream commit 6d39d589bb76ee8a1c6cde6822006ae0053decff ] In case of tcp, gso_size contains the tcpmss. For UFO (udp fragmentation offloading) skbs, gso_size is the fragment payload size, i.e. we must not account for udp header size. Otherwise, when using virtio drivers, a to-be-forwarded UFO GSO packet will be needlessly fragmented in the forward path, because we think its individual segments are too large for the outgoing link. Fixes: fe6cc55f3a9a053 ("net: ip, ipv6: handle gso skbs in forwarding path") Cc: Eric Dumazet Reported-by: Tobias Brunner Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ea4dd539a9a5994c215ce48377483f7dba01613 Author: Dmitry Petukhov Date: Wed Apr 9 02:23:20 2014 +0600 l2tp: take PMTU from tunnel UDP socket [ Upstream commit f34c4a35d87949fbb0e0f31eba3c054e9f8199ba ] When l2tp driver tries to get PMTU for the tunnel destination, it uses the pointer to struct sock that represents PPPoX socket, while it should use the pointer that represents UDP socket of the tunnel. Signed-off-by: Dmitry Petukhov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3947574d9ccb493843d518fea97f92f6acdb8c8a Author: Daniel Borkmann Date: Wed Apr 9 16:10:20 2014 +0200 net: sctp: test if association is dead in sctp_wake_up_waiters [ Upstream commit 1e1cdf8ac78793e0875465e98a648df64694a8d0 ] In function sctp_wake_up_waiters(), we need to involve a test if the association is declared dead. If so, we don't have any reference to a possible sibling association anymore and need to invoke sctp_write_space() instead, and normally walk the socket's associations and notify them of new wmem space. The reason for special casing is that otherwise, we could run into the following issue when a sctp_primitive_SEND() call from sctp_sendmsg() fails, and tries to flush an association's outq, i.e. in the following way: sctp_association_free() `-> list_del(&asoc->asocs) <-- poisons list pointer asoc->base.dead = true sctp_outq_free(&asoc->outqueue) `-> __sctp_outq_teardown() `-> sctp_chunk_free() `-> consume_skb() `-> sctp_wfree() `-> sctp_wake_up_waiters() <-- dereferences poisoned pointers if asoc->ep->sndbuf_policy=0 Therefore, only walk the list in an 'optimized' way if we find that the current association is still active. We could also use list_del_init() in addition when we call sctp_association_free(), but as Vlad suggests, we want to trap such bugs and thus leave it poisoned as is. Why is it safe to resolve the issue by testing for asoc->base.dead? Parallel calls to sctp_sendmsg() are protected under socket lock, that is lock_sock()/release_sock(). Only within that path under lock held, we're setting skb/chunk owner via sctp_set_owner_w(). Eventually, chunks are freed directly by an association still under that lock. So when traversing association list on destruction time from sctp_wake_up_waiters() via sctp_wfree(), a different CPU can't be running sctp_wfree() while another one calls sctp_association_free() as both happens under the same lock. Therefore, this can also not race with setting/testing against asoc->base.dead as we are guaranteed for this to happen in order, under lock. Further, Vlad says: the times we check asoc->base.dead is when we've cached an association pointer for later processing. In between cache and processing, the association may have been freed and is simply still around due to reference counts. We check asoc->base.dead under a lock, so it should always be safe to check and not race against sctp_association_free(). Stress-testing seems fine now, too. Fixes: cd253f9f357d ("net: sctp: wake up all assocs if sndbuf policy is per socket") Signed-off-by: Daniel Borkmann Cc: Vlad Yasevich Acked-by: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 83bd973b675208476e2a29b159b68c6ef796b66d Author: Daniel Borkmann Date: Tue Apr 8 17:26:13 2014 +0200 net: sctp: wake up all assocs if sndbuf policy is per socket [ Upstream commit 52c35befb69b005c3fc5afdaae3a5717ad013411 ] SCTP charges chunks for wmem accounting via skb->truesize in sctp_set_owner_w(), and sctp_wfree() respectively as the reverse operation. If a sender runs out of wmem, it needs to wait via sctp_wait_for_sndbuf(), and gets woken up by a call to __sctp_write_space() mostly via sctp_wfree(). __sctp_write_space() is being called per association. Although we assign sk->sk_write_space() to sctp_write_space(), which is then being done per socket, it is only used if send space is increased per socket option (SO_SNDBUF), as SOCK_USE_WRITE_QUEUE is set and therefore not invoked in sock_wfree(). Commit 4c3a5bdae293 ("sctp: Don't charge for data in sndbuf again when transmitting packet") fixed an issue where in case sctp_packet_transmit() manages to queue up more than sndbuf bytes, sctp_wait_for_sndbuf() will never be woken up again unless it is interrupted by a signal. However, a still remaining issue is that if net.sctp.sndbuf_policy=0, that is accounting per socket, and one-to-many sockets are in use, the reclaimed write space from sctp_wfree() is 'unfairly' handed back on the server to the association that is the lucky one to be woken up again via __sctp_write_space(), while the remaining associations are never be woken up again (unless by a signal). The effect disappears with net.sctp.sndbuf_policy=1, that is wmem accounting per association, as it guarantees a fair share of wmem among associations. Therefore, if we have reclaimed memory in case of per socket accounting, wake all related associations to a socket in a fair manner, that is, traverse the socket association list starting from the current neighbour of the association and issue a __sctp_write_space() to everyone until we end up waking ourselves. This guarantees that no association is preferred over another and even if more associations are taken into the one-to-many session, all receivers will get messages from the server and are not stalled forever on high load. This setting still leaves the advantage of per socket accounting in touch as an association can still use up global limits if unused by others. Fixes: 4eb701dfc618 ("[SCTP] Fix SCTP sendbuffer accouting.") Signed-off-by: Daniel Borkmann Cc: Thomas Graf Cc: Neil Horman Cc: Vlad Yasevich Acked-by: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 634207ccdaaaa8429ab4230216013554097cc76f Author: Oleg Nesterov Date: Tue Nov 12 15:10:01 2013 -0800 list: introduce list_next_entry() and list_prev_entry() [ Upstream commit 008208c6b26f21c2648c250a09c55e737c02c5f8 ] Add two trivial helpers list_next_entry() and list_prev_entry(), they can have a lot of users including list.h itself. In fact the 1st one is already defined in events/core.c and bnx2x_sp.c, so the patch simply moves the definition to list.h. Signed-off-by: Oleg Nesterov Cc: Eilon Greenstein Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6d611183634723139f9f77ecef77ed8cb1e5789c Author: Alex Deucher Date: Mon Mar 31 11:19:46 2014 -0400 drm/radeon: call drm_edid_to_eld when we update the edid commit 16086279353cbfecbb3ead474072dced17b97ddc upstream. This needs to be done to update some of the fields in the connector structure used by the audio code. Noticed by several users on irc. Signed-off-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit dec8ba10d0770e4361259e52217ec81bea8d96a2 Author: Maarten Lankhorst Date: Tue Apr 1 15:15:47 2014 +0200 drm/qxl: unset a pointer in sync_obj_unref commit 41ccec352f3c823931a7d9d2a9c7880c14d7415a upstream. This fixes a BUG_ON(bo->sync_obj != NULL); in ttm_bo_release_list. Signed-off-by: Maarten Lankhorst Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit a741acc0124c0d20941a86edb475329eb47e0aee Author: Thomas Hellstrom Date: Tue Apr 15 18:25:48 2014 +0200 drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2 commit cbd75e97a525e3819c02dc18bc2d67aa544c9e45 upstream. We already check that the buffer object we're accessing is registered with the file. Now also make sure that we can't DMA across buffer object boundaries. v2: Code commenting update. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Signed-off-by: Greg Kroah-Hartman commit e766686f8ac76d5b262baf7101f31f3b50c4803d Author: Christopher Friedt Date: Sat Feb 1 10:01:15 2014 -0500 drm/vmwgfx: correct fb_fix_screeninfo.line_length commit aa6de142c901cd2d90ef08db30ae87da214bedcc upstream. Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour. See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples. Signed-off-by: Christopher Friedt Reviewed-by: Thomas Hellstrom Signed-off-by: Greg Kroah-Hartman commit 8cfe6831bd3fc42a4b1d276e59d005d2be4f4f7d Author: Bjørn Mork Date: Fri Apr 25 18:49:20 2014 +0200 usb: option: add and update a number of CMOTech devices commit 34f972d6156fe9eea2ab7bb418c71f9d1d5c8e7b upstream. A number of older CMOTech modems are based on Qualcomm chips. The blacklisted interfaces are QMI/wwan. Reported-by: Lars Melin Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 447bcef42bf28e03be09eebb1c922b4c1a1f9b8a Author: Bjørn Mork Date: Fri Apr 25 18:49:19 2014 +0200 usb: option: add Alcatel L800MA commit dd6b48ecec2ea7d15f28d5e5474388681899a5e1 upstream. Device interface layout: 0: ff/ff/ff - serial 1: ff/00/00 - serial AT+PPP 2: ff/ff/ff - QMI/wwan 3: 08/06/50 - storage Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 4f4010b4d135f0f93dba9e1382600d74b17f9ba9 Author: Bjørn Mork Date: Fri Apr 25 18:49:18 2014 +0200 usb: option: add Olivetti Olicard 500 commit 533b3994610f316e5cd61b56d0c4daa15c830f89 upstream. Device interface layout: 0: ff/ff/ff - serial 1: ff/ff/ff - serial AT+PPP 2: 08/06/50 - storage 3: ff/ff/ff - serial 4: ff/ff/ff - QMI/wwan Reported-by: Julio Araujo Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 954be371ab9d3409f3c1853f9d280b1583cc796d Author: Bjørn Mork Date: Fri Apr 25 18:49:17 2014 +0200 usb: qcserial: add Sierra Wireless MC7305/MC7355 commit bce4f588f19d59fc07fadfeb0b2a3a06c942827a upstream. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit b287dd081ace55a7d3e1ee69f40a82e3fe39b84d Author: Bjørn Mork Date: Fri Apr 25 18:49:16 2014 +0200 usb: qcserial: add Sierra Wireless MC73xx commit 70a3615fc07c2330ed7c1e922f3c44f4a67c0762 upstream. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit f39486db5f3fefb2c48f65d7c29071c2ef42c602 Author: Bjørn Mork Date: Fri Apr 25 18:49:15 2014 +0200 usb: qcserial: add Sierra Wireless EM7355 commit a00986f81182a69dee4d2c48e8c19805bdf0f790 upstream. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 9e036f060793ddb0a9f3f70d4753877b85e894b4 Author: Johan Hovold Date: Fri Apr 25 15:23:03 2014 +0200 USB: io_ti: fix firmware download on big-endian machines commit 5509076d1b4485ce9fb07705fcbcd2695907ab5b upstream. During firmware download the device expects memory addresses in big-endian byte order. As the wIndex parameter which hold the address is sent in little-endian byte order regardless of host byte order, we need to use swab16 rather than cpu_to_be16. Also make sure to handle the struct ti_i2c_desc size parameter which is returned in little-endian byte order. Reported-by: Ludovic Drolez Tested-by: Ludovic Drolez Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2eb1a584d440a3aed1b4793f39d091c1fff3f6d7 Author: Johan Hovold Date: Wed Apr 23 11:32:19 2014 +0200 USB: serial: fix sysfs-attribute removal deadlock commit 10164c2ad6d2c16809f6c09e278f946e47801b3a upstream. Fix driver new_id sysfs-attribute removal deadlock by making sure to not hold any locks that the attribute operations grab when removing the attribute. Specifically, usb_serial_deregister holds the table mutex when deregistering the driver, which includes removing the new_id attribute. This can lead to a deadlock as writing to new_id increments the attribute's active count before trying to grab the same mutex in usb_serial_probe. The deadlock can easily be triggered by inserting a sleep in usb_serial_deregister and writing the id of an unbound device to new_id during module unload. As the table mutex (in this case) is used to prevent subdriver unload during probe, it should be sufficient to only hold the lock while manipulating the usb-serial driver list during deregister. A racing probe will then either fail to find a matching subdriver or fail to get the corresponding module reference. Since v3.15-rc1 this also triggers the following lockdep warning: ====================================================== [ INFO: possible circular locking dependency detected ] 3.15.0-rc2 #123 Tainted: G W ------------------------------------------------------- modprobe/190 is trying to acquire lock: (s_active#4){++++.+}, at: [] kernfs_remove_by_name_ns+0x4c/0x94 but task is already holding lock: (table_lock){+.+.+.}, at: [] usb_serial_deregister+0x3c/0x78 [usbserial] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (table_lock){+.+.+.}: [] __lock_acquire+0x1694/0x1ce4 [] lock_acquire+0xb4/0x154 [] _raw_spin_lock+0x4c/0x5c [] usb_store_new_id+0x14c/0x1ac [] new_id_store+0x68/0x70 [usbserial] [] drv_attr_store+0x30/0x3c [] sysfs_kf_write+0x5c/0x60 [] kernfs_fop_write+0xd4/0x194 [] vfs_write+0xbc/0x198 [] SyS_write+0x4c/0xa0 [] ret_fast_syscall+0x0/0x48 -> #0 (s_active#4){++++.+}: [] print_circular_bug+0x68/0x2f8 [] __lock_acquire+0x1928/0x1ce4 [] lock_acquire+0xb4/0x154 [] __kernfs_remove+0x254/0x310 [] kernfs_remove_by_name_ns+0x4c/0x94 [] remove_files.isra.1+0x48/0x84 [] sysfs_remove_group+0x58/0xac [] sysfs_remove_groups+0x34/0x44 [] driver_remove_groups+0x1c/0x20 [] bus_remove_driver+0x3c/0xe4 [] driver_unregister+0x38/0x58 [] usb_serial_bus_deregister+0x84/0x88 [usbserial] [] usb_serial_deregister+0x6c/0x78 [usbserial] [] usb_serial_deregister_drivers+0x2c/0x4c [usbserial] [] usb_serial_module_exit+0x14/0x1c [sierra] [] SyS_delete_module+0x184/0x210 [] ret_fast_syscall+0x0/0x48 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(table_lock); lock(s_active#4); lock(table_lock); lock(s_active#4); *** DEADLOCK *** 1 lock held by modprobe/190: #0: (table_lock){+.+.+.}, at: [] usb_serial_deregister+0x3c/0x78 [usbserial] stack backtrace: CPU: 0 PID: 190 Comm: modprobe Tainted: G W 3.15.0-rc2 #123 [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x24/0x28) [] (dump_stack) from [] (print_circular_bug+0x2ec/0x2f8) [] (print_circular_bug) from [] (__lock_acquire+0x1928/0x1ce4) [] (__lock_acquire) from [] (lock_acquire+0xb4/0x154) [] (lock_acquire) from [] (__kernfs_remove+0x254/0x310) [] (__kernfs_remove) from [] (kernfs_remove_by_name_ns+0x4c/0x94) [] (kernfs_remove_by_name_ns) from [] (remove_files.isra.1+0x48/0x84) [] (remove_files.isra.1) from [] (sysfs_remove_group+0x58/0xac) [] (sysfs_remove_group) from [] (sysfs_remove_groups+0x34/0x44) [] (sysfs_remove_groups) from [] (driver_remove_groups+0x1c/0x20) [] (driver_remove_groups) from [] (bus_remove_driver+0x3c/0xe4) [] (bus_remove_driver) from [] (driver_unregister+0x38/0x58) [] (driver_unregister) from [] (usb_serial_bus_deregister+0x84/0x88 [usbserial]) [] (usb_serial_bus_deregister [usbserial]) from [] (usb_serial_deregister+0x6c/0x78 [usbserial]) [] (usb_serial_deregister [usbserial]) from [] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial]) [] (usb_serial_deregister_drivers [usbserial]) from [] (usb_serial_module_exit+0x14/0x1c [sierra]) [] (usb_serial_module_exit [sierra]) from [] (SyS_delete_module+0x184/0x210) [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x48) Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 4b2ac05d9b30b3a1fdb03d64400a98fac4ec8980 Author: Johan Hovold Date: Fri Mar 28 18:05:10 2014 +0100 Revert "USB: serial: add usbid for dell wwan card to sierra.c" commit 2e01280d2801c72878cf3a7119eac30077b463d5 upstream. This reverts commit 1ebca9dad5abe8b2ed4dbd186cd657fb47c1f321. This device was erroneously added to the sierra driver even though it's not a Sierra device and was already handled by the option driver. Cc: Richard Farina Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fa028c45b4433f8786dd24c8a6cd2b3aff22ac41 Author: Daniele Palmas Date: Wed Apr 2 11:19:48 2014 +0200 usb: option driver, add support for Telit UE910v2 commit d6de486bc22255779bd54b0fceb4c240962bf146 upstream. option driver, added VID/PID for Telit UE910v2 modem Signed-off-by: Daniele Palmas Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9e1bf425712a9edbe6b033ca6ab86fd5067a7fb3 Author: Michele Baldessari Date: Mon Mar 31 10:51:00 2014 +0200 USB: serial: ftdi_sio: add id for Brainboxes serial cards commit efe26e16b1d93ac0085e69178cc18811629e8fc5 upstream. Custom VID/PIDs for Brainboxes cards as reported in https://bugzilla.redhat.com/show_bug.cgi?id=1071914 Signed-off-by: Michele Baldessari Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9781c6a26a489c54b53ca31ca227e8423e76693a Author: Johan Hovold Date: Thu Apr 3 13:06:46 2014 +0200 USB: usb_wwan: fix handling of missing bulk endpoints commit bd73bd8831696f189a479a0712ae95208e513d7e upstream. Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix bulk-urb allocation") by making sure to require both bulk-in and out endpoints during port probe. The original option driver (which usb_wwan is based on) was written under the assumption that either endpoint could be missing, but evidently this cannot have been tested properly. Specifically, it would handle opening a device without bulk-in (but would blow up during resume which was implemented later), but not a missing bulk-out in write() (although it is handled in some places such as write_room()). Fortunately (?), the driver also got the test for missing endpoints wrong so the urbs were in fact always allocated, although they would be initialised using the wrong endpoint address (0) and any submission of such an urb would fail. The commit mentioned above fixed the test for missing endpoints but thereby exposed the other bugs which would now generate null-pointer exceptions rather than failed urb submissions. The regression was introduced in v3.7, but the offending commit was also marked for stable. Reported-by: Rafał Miłecki Signed-off-by: Johan Hovold Tested-by: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman commit 05fdd16c9f90522fcf4b56dbd33e9ab92c0bf2ea Author: Tristan Bruns Date: Sun Apr 13 23:57:16 2014 +0200 USB: cp210x: Add 8281 (Nanotec Plug & Drive) commit 72b3007951010ce1bbf950e23b19d9839fa905a5 upstream. Signed-off-by: Tristan Bruns Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ed37e0cb63f1e39411150e29061beeaaed064540 Author: Michael Ulbricht Date: Tue Mar 25 10:34:18 2014 +0100 USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver commit 895d240d1db0b2736d779200788e4c4aea28a0c6 upstream. By specifying NO_UNION_NORMAL the ACM driver does only use the first two USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA interfaces are left to the USB serial driver. Signed-off-by: Michael Ulbricht Signed-off-by: Alexander Stein Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 6fe8c0a06b858e6225fcfb80e3be0a319ff84ea7 Author: Mel Gorman Date: Fri Apr 18 15:07:21 2014 -0700 mm: use paravirt friendly ops for NUMA hinting ptes commit 29c7787075c92ca8af353acd5301481e6f37082f upstream. David Vrabel identified a regression when using automatic NUMA balancing under Xen whereby page table entries were getting corrupted due to the use of native PTE operations. Quoting him Xen PV guest page tables require that their entries use machine addresses if the preset bit (_PAGE_PRESENT) is set, and (for successful migration) non-present PTEs must use pseudo-physical addresses. This is because on migration MFNs in present PTEs are translated to PFNs (canonicalised) so they may be translated back to the new MFN in the destination domain (uncanonicalised). pte_mknonnuma(), pmd_mknonnuma(), pte_mknuma() and pmd_mknuma() set and clear the _PAGE_PRESENT bit using pte_set_flags(), pte_clear_flags(), etc. In a Xen PV guest, these functions must translate MFNs to PFNs when clearing _PAGE_PRESENT and translate PFNs to MFNs when setting _PAGE_PRESENT. His suggested fix converted p[te|md]_[set|clear]_flags to using paravirt-friendly ops but this is overkill. He suggested an alternative of using p[te|md]_modify in the NUMA page table operations but this is does more work than necessary and would require looking up a VMA for protections. This patch modifies the NUMA page table operations to use paravirt friendly operations to set/clear the flags of interest. Unfortunately this will take a performance hit when updating the PTEs on CONFIG_PARAVIRT but I do not see a way around it that does not break Xen. Signed-off-by: Mel Gorman Acked-by: David Vrabel Tested-by: David Vrabel Cc: Ingo Molnar Cc: Peter Anvin Cc: Fengguang Wu Cc: Linus Torvalds Cc: Steven Noonan Cc: Rik van Riel Cc: Peter Zijlstra Cc: Andrea Arcangeli Cc: Dave Hansen Cc: Srikar Dronamraju Cc: Cyrill Gorcunov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b934932aa9b3e8e2361122cd0560b63c478081da Author: Mizuma, Masayoshi Date: Fri Apr 18 15:07:18 2014 -0700 mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages() commit 7848a4bf51b34f41fcc9bd77e837126d99ae84e3 upstream. soft lockup in freeing gigantic hugepage fixed in commit 55f67141a892 "mm: hugetlb: fix softlockup when a large number of hugepages are freed." can happen in return_unused_surplus_pages(), so let's fix it. Signed-off-by: Masayoshi Mizuma Signed-off-by: Naoya Horiguchi Cc: Joonsoo Kim Cc: Michal Hocko Cc: Aneesh Kumar Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fdc9aa48b7ca57c9e2154ad68bf0fcd731dabeb7 Author: NeilBrown Date: Wed Apr 9 12:25:43 2014 +1000 md/raid1: r1buf_pool_alloc: free allocate pages when subsequent allocation fails. commit da1aab3dca9aa88ae34ca392470b8943159e25fe upstream. When performing a user-request check/repair (MD_RECOVERY_REQUEST is set) on a raid1, we allocate multiple bios each with their own set of pages. If the page allocations for one bio fails, we currently do *not* free the pages allocated for the previous bios, nor do we free the bio itself. This patch frees all the already-allocate pages, and makes sure that all the bios are freed as well. This bug can cause a memory leak which can ultimately OOM a machine. It was introduced in 3.10-rc1. Fixes: a07876064a0b73ab5ef1ebcf14b1cf0231c07858 Cc: Kent Overstreet Reported-by: Russell King - ARM Linux Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 68ad89c73da6085d14e18f18ec7298821d408b2d Author: Al Viro Date: Fri Mar 14 10:56:20 2014 -0400 don't bother with {get,put}_write_access() on non-regular files commit dd20908a8a06b22c171f6c3fcdbdbd65bed07505 upstream. it's pointless and actually leads to wrong behaviour in at least one moderately convoluted case (pipe(), close one end, try to get to another via /proc/*/fd and run into ETXTBUSY). Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit cd09dfbdad430e807be3dee98ce03f452b7ef001 Author: Helge Deller Date: Sun Apr 13 00:03:55 2014 +0200 parisc: fix epoll_pwait syscall on compat kernel commit ab3e55b119c9653b19ea4edffb86f04db867ac98 upstream. This bug was detected with the libio-epoll-perl debian package where the test case IO-Ppoll-compat.t failed. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit dd154e74b0aa11cd45d9c0f054fb8dabeba35935 Author: Mikulas Patocka Date: Thu Jan 23 14:42:43 2014 -0500 tgafb: fix mode setting with fbset commit 624966589041deb32a2626ee2e176e8274581101 upstream. Mode setting in the TGA driver is broken for these reasons: - info->fix.line_length is set just once in tgafb_init_fix function. If we change videomode, info->fix.line_length is not recalculated - so the video mode is changed but the screen is corrupted because of wrong info->fix.line_length. - info->fix.smem_len is set in tgafb_init_fix to the size of the default video mode (640x480). If we set a higher resolution, info->fix.smem_len is smaller than the current screen size, preventing the userspace program from mapping the framebuffer. This patch fixes it: - info->fix.line_length initialization is moved to tgafb_set_par so that it is recalculated with each mode change. - info->fix.smem_len is set to a fixed value representing the real amount of video ram (the values are taken from xfree86 driver). - add a check to tgafb_check_var to prevent us from setting a videomode that doesn't fit into videoram. - in tgafb_register, tgafb_init_fix is moved upwards, to be called before fb_find_mode (because fb_find_mode already needs the videoram size set in tgafb_init_fix). Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 70c6edb3bcb97887f004515f17dd247657177cb5 Author: Andreas Schwab Date: Mon Dec 30 15:31:17 2013 +0100 powerpc: Add vr save/restore functions commit 8fe9c93e7453e67b8bd09f263ec1bb0783c733fc upstream. GCC 4.8 now generates out-of-line vr save/restore functions when optimizing for size. They are needed for the raid6 altivec support. Signed-off-by: Andreas Schwab Signed-off-by: Benjamin Herrenschmidt Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 04168b98a30d5257d20a7213f58ff0b27174e489 Author: Ilya Dryomov Date: Tue Mar 4 11:57:17 2014 +0200 rbd: fix error paths in rbd_img_request_fill() commit 42dd037c08c7cd6e3e9af7824b0c1d063f838885 upstream. Doing rbd_obj_request_put() in rbd_img_request_fill() error paths is not only insufficient, but also triggers an rbd_assert() in rbd_obj_request_destroy(): Assertion failure in rbd_obj_request_destroy() at line 1867: rbd_assert(obj_request->img_request == NULL); rbd_img_obj_request_add() adds obj_requests to the img_request, the opposite is rbd_img_obj_request_del(). Use it. Fixes: http://tracker.ceph.com/issues/7327 Signed-off-by: Ilya Dryomov Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit e1af8f80e8398591f96d2e35e02a5deca6118c38 Author: Olof Johansson Date: Mon Sep 16 09:01:24 2013 -0700 ARM: multi_v7_defconfig: enable ARM_ATAG_DTB_COMPAT commit a0396b9bd5a4a7baf598b60d2ca53c605c440a42 upstream. Without this, legacy platforms that can boot with a multiplatform kernel but that need the DTB to be appended, won't have a way to pass firmware-set bootargs to the kernel. This is needed to boot multi_v7_defconfig on snowball, for instance. Signed-off-by: Olof Johansson Cc: Jason Cooper Cc: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit ee5e96604bdf348b3fcb9b32b59a63589d66548c Author: Soren Brinkmann Date: Wed Jun 19 10:53:04 2013 -0700 arm: multi_v7_defconfig: Enable initrd/initramfs support commit c12d82b84353784f8233c28ee43cec0ac9fbd7d2 upstream. Add CONFIG_BLK_DEV_INITRD to the defconfig to support initramfs and initrd. Signed-off-by: Soren Brinkmann Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman commit b615a1622098d5164aa2dc278550553c38da7d33 Author: Stefan Richter Date: Thu Mar 6 20:39:04 2014 +0100 firewire: ohci: fix probe failure with Agere/LSI controllers commit 0ca49345b6f489e95f8d6edeb0b092e257475b2a upstream. Since commit bd972688eb24 "firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8", there is a high chance that firewire-ohci fails to initialize LSI née Agere controllers. https://bugzilla.kernel.org/show_bug.cgi?id=65151 Peter Hurley points out the reason: IEEE 1394a:2000 clause 5A.1 (or IEEE 1394:2008 clause 17.2.1) say: "The PHY shall insure that no more than 10 ms elapse from the reassertion of LPS until the interface is reset. The link shall not assert LReq until the reset is complete." In other words, the link needs to give the PHY at least 10 ms to get the interface operational. With just the msleep(1) in bd972688eb24, the first read_phy_reg() during ohci_enable() may happen before the phy-link interface reset was finished, and fail. Due to the high variability of msleep(n) with small n, this failure was not fully reproducible, and not apparent at all with low CONFIG_HZ setting. On the other hand, Peter can no longer reproduce the issue with FW643 rev8. The read phy reg failures that happened back then may have had an unrelated cause. So, just revert bd972688eb24, except for the valid comment on TSB82AA2 cards. Reported-by: Mikhail Gavrilov Reported-by: Jay Fenlason Reported-by: Clemens Ladisch Reported-by: Peter Hurley Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit fc6b2d2c27a836a42ac39c471a9de219d31414e5 Author: Stefan Richter Date: Mon Aug 5 15:14:36 2013 +0200 firewire: ohci: beautify some macro definitions commit 0dbe15f88be5b2cdf4ca4145797861dfb0d583a5 upstream. a) Sort device IDs by vendor -- device -- revision. b) Write quirk flags in hexadecimal. This affects the user-visible output of "modinfo firewire-ohci". Since more flags have been added recently, it is now easier to cope with them in hexadecimal represen- tation. Besides, the device-specific combination of quirk flags is shown in hexadecimal in the kernel log too. (And firewire-sbp2 presents its own quirk flags in modinfo as hexadecimals as well.) Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 7ba8b86fa59aee2895bb94824768c2217fd92623 Author: Steven Rostedt (Red Hat) Date: Wed Feb 26 10:54:36 2014 -0500 tracepoint: Do not waste memory on mods with no tracepoints commit 7dec935a3aa04412cba2cebe1524ae0d34a30c24 upstream. No reason to allocate tp_module structures for modules that have no tracepoints. This just wastes memory. Fixes: b75ef8b44b1c "Tracepoint: Dissociate from module mutex" Acked-by: Mathieu Desnoyers Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit c5e4ef499cfc78de45a4f01b8c557b5964d77c53 Author: Thomas Graf Date: Fri Apr 4 17:57:45 2014 +0200 netfilter: Can't fail and free after table replacement commit c58dd2dd443c26d856a168db108a0cd11c285bf3 upstream. All xtables variants suffer from the defect that the copy_to_user() to copy the counters to user memory may fail after the table has already been exchanged and thus exposed. Return an error at this point will result in freeing the already exposed table. Any subsequent packet processing will result in a kernel panic. We can't copy the counters before exposing the new tables as we want provide the counter state after the old table has been unhooked. Therefore convert this into a silent error. Cc: Florian Westphal Signed-off-by: Thomas Graf Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a843619f1b755a2870f235b8aab5d2cc327bf456 Author: Andrey Vagin Date: Fri Mar 28 13:54:32 2014 +0400 netfilter: nf_conntrack: reserve two bytes for nf_ct_ext->len commit 223b02d923ecd7c84cf9780bb3686f455d279279 upstream. "len" contains sizeof(nf_ct_ext) and size of extensions. In a worst case it can contain all extensions. Bellow you can find sizes for all types of extensions. Their sum is definitely bigger than 256. nf_ct_ext_types[0]->len = 24 nf_ct_ext_types[1]->len = 32 nf_ct_ext_types[2]->len = 24 nf_ct_ext_types[3]->len = 32 nf_ct_ext_types[4]->len = 152 nf_ct_ext_types[5]->len = 2 nf_ct_ext_types[6]->len = 16 nf_ct_ext_types[7]->len = 8 I have seen "len" up to 280 and my host has crashes w/o this patch. The right way to fix this problem is reducing the size of the ecache extension (4) and Florian is going to do this, but these changes will be quite large to be appropriate for a stable tree. Fixes: 5b423f6a40a0 (netfilter: nf_conntrack: fix racy timer handling with reliable) Cc: Pablo Neira Ayuso Cc: Patrick McHardy Cc: Jozsef Kadlecsik Cc: "David S. Miller" Signed-off-by: Andrey Vagin Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e9d933941569c107e0083c3c115467c699a57db2 Author: Roman Pen Date: Tue Mar 4 23:13:10 2014 +0900 blktrace: fix accounting of partially completed requests commit af5040da01ef980670b3741b3e10733ee3e33566 upstream. trace_block_rq_complete does not take into account that request can be partially completed, so we can get the following incorrect output of blkparser: C R 232 + 240 [0] C R 240 + 232 [0] C R 248 + 224 [0] C R 256 + 216 [0] but should be: C R 232 + 8 [0] C R 240 + 8 [0] C R 248 + 8 [0] C R 256 + 8 [0] Also, the whole output summary statistics of completed requests and final throughput will be incorrect. This patch takes into account real completion size of the request and fixes wrong completion accounting. Signed-off-by: Roman Pen CC: Steven Rostedt CC: Frederic Weisbecker CC: Ingo Molnar CC: linux-kernel@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8d6b283d97db2d4d8fb6d1b8cfc630906f883f2f Author: Dan Carpenter Date: Wed Oct 30 20:13:51 2013 +0300 SCSI: megaraid: missing bounds check in mimd_to_kioc() commit 3de2260140417759c669d391613d583baf03b0cf upstream. pthru32->dataxferlen comes from the user so we need to check that it's not too large so we don't overflow the buffer. Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Signed-off-by: Dan Carpenter Acked-by: Sumit Saxena Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e623c2cdb5b9151e1ca8c846e2814977ba4dfcac Author: James Bottomley Date: Tue Jan 21 07:01:41 2014 -0800 SCSI: dual scan thread bug fix commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream. In the highly unusual case where two threads are running concurrently through the scanning code scanning the same target, we run into the situation where one may allocate the target while the other is still using it. In this case, because the reap checks for STARGET_CREATED and kills the target without reference counting, the second thread will do the wrong thing on reap. Fix this by reference counting even creates and doing the STARGET_CREATED check in the final put. Tested-by: Sarah Sharp Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit c3c8d397fef461c0b3a273f68abf9adffc85aa3a Author: James Bottomley Date: Tue Jan 21 07:00:50 2014 -0800 scsi: fix our current target reap infrastructure commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream. This patch eliminates the reap_ref and replaces it with a proper kref. On last put of this kref, the target is removed from visibility in sysfs. The final call to scsi_target_reap() for the device is done from __scsi_remove_device() and only if the device was made visible. This ensures that the target disappears as soon as the last device is gone rather than waiting until final release of the device (which is often too long). Reviewed-by: Alan Stern Tested-by: Sarah Sharp Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman