commit 60917545df1ffc7f918550512dc4a14758f74784 Author: Sasha Levin Date: Tue Dec 15 12:45:27 2015 -0500 Linux 3.18.25 Signed-off-by: Sasha Levin commit 1ced23539f9809cbdb86eed9b9626495720530aa Author: Eric Dumazet Date: Tue Dec 1 07:20:07 2015 -0800 ipv6: sctp: implement sctp_v6_destroy_sock() [ Upstream commit 602dd62dfbda3e63a2d6a3cbde953ebe82bf5087 ] Dmitry Vyukov reported a memory leak using IPV6 SCTP sockets. We need to call inet6_destroy_sock() to properly release inet6 specific fields. Reported-by: Dmitry Vyukov Signed-off-by: Eric Dumazet Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 18c103ad86330b59a9ea2f8de4ce73cbb36fa573 Author: Konstantin Khlebnikov Date: Tue Dec 1 01:14:48 2015 +0300 net/neighbour: fix crash at dumping device-agnostic proxy entries [ Upstream commit 6adc5fd6a142c6e2c80574c1db0c7c17dedaa42e ] Proxy entries could have null pointer to net-device. Signed-off-by: Konstantin Khlebnikov Fixes: 84920c1420e2 ("net: Allow ipv6 proxies and arp proxies be shown with iproute2") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 46ddb98e2018a5a62cefa75b3c80882850c91e39 Author: Eric Dumazet Date: Sun Nov 29 19:37:57 2015 -0800 ipv6: add complete rcu protection around np->opt [ Upstream commit 45f6fad84cc305103b28d73482b344d7f5b76f39 ] This patch addresses multiple problems : UDP/RAW sendmsg() need to get a stable struct ipv6_txoptions while socket is not locked : Other threads can change np->opt concurrently. Dmitry posted a syzkaller (http://github.com/google/syzkaller) program desmonstrating use-after-free. Starting with TCP/DCCP lockless listeners, tcp_v6_syn_recv_sock() and dccp_v6_request_recv_sock() also need to use RCU protection to dereference np->opt once (before calling ipv6_dup_options()) This patch adds full RCU protection to np->opt Reported-by: Dmitry Vyukov Signed-off-by: Eric Dumazet Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e33c9be772f35cab83e100160b2b42e03f1eb2cc Author: Michal Kubeček Date: Tue Nov 24 15:07:11 2015 +0100 ipv6: distinguish frag queues by device for multicast and link-local packets [ Upstream commit 264640fc2c5f4f913db5c73fa3eb1ead2c45e9d7 ] If a fragmented multicast packet is received on an ethernet device which has an active macvlan on top of it, each fragment is duplicated and received both on the underlying device and the macvlan. If some fragments for macvlan are processed before the whole packet for the underlying device is reassembled, the "overlapping fragments" test in ip6_frag_queue() discards the whole fragment queue. To resolve this, add device ifindex to the search key and require it to match reassembling multicast packets and packets to link-local addresses. Note: similar patch has been already submitted by Yoshifuji Hideaki in http://patchwork.ozlabs.org/patch/220979/ but got lost and forgotten for some reason. Signed-off-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fbf44baf4444511fb1f42cd3dcfd511aba995c0a Author: Aaro Koskinen Date: Sun Nov 22 01:08:54 2015 +0200 broadcom: fix PHY_ID_BCM5481 entry in the id table [ Upstream commit 3c25a860d17b7378822f35d8c9141db9507e3beb ] Commit fcb26ec5b18d ("broadcom: move all PHY_ID's to header") updated broadcom_tbl to use PHY_IDs, but incorrectly replaced 0x0143bca0 with PHY_ID_BCM5482 (making a duplicate entry, and completely omitting the original). Fix that. Fixes: fcb26ec5b18d ("broadcom: move all PHY_ID's to header") Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 357dc4e63e7c2a56df6c1f34826968423414c846 Author: Nikolay Aleksandrov Date: Fri Nov 20 13:54:20 2015 +0100 net: ip6mr: fix static mfc/dev leaks on table destruction [ Upstream commit 4c6980462f32b4f282c5d8e5f7ea8070e2937725 ] Similar to ipv4, when destroying an mrt table the static mfc entries and the static devices are kept, which leads to devices that can never be destroyed (because of refcnt taken) and leaked memory. Make sure that everything is cleaned up on netns destruction. Fixes: 8229efdaef1e ("netns: ip6mr: enable namespace support in ipv6 multicast forwarding code") CC: Benjamin Thery Signed-off-by: Nikolay Aleksandrov Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 691e3dcb40a7e7a83f368cfea1952ffa6aff6cc0 Author: Nikolay Aleksandrov Date: Fri Nov 20 13:54:19 2015 +0100 net: ipmr: fix static mfc/dev leaks on table destruction [ Upstream commit 0e615e9601a15efeeb8942cf7cd4dadba0c8c5a7 ] When destroying an mrt table the static mfc entries and the static devices are kept, which leads to devices that can never be destroyed (because of refcnt taken) and leaked memory, for example: unreferenced object 0xffff880034c144c0 (size 192): comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s) hex dump (first 32 bytes): 98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff .S.4.....S.4.... ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc+0x190/0x300 [] ip_mroute_setsockopt+0x5cb/0x910 [] do_ip_setsockopt.isra.11+0x105/0xff0 [] ip_setsockopt+0x30/0xa0 [] raw_setsockopt+0x33/0x90 [] sock_common_setsockopt+0x14/0x20 [] SyS_setsockopt+0x71/0xc0 [] entry_SYSCALL_64_fastpath+0x16/0x7a [] 0xffffffffffffffff Make sure that everything is cleaned on netns destruction. Signed-off-by: Nikolay Aleksandrov Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 306c535778cfb881a53b660ac80f3f633013d1db Author: Daniel Borkmann Date: Fri Nov 20 00:11:56 2015 +0100 net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds [ Upstream commit 6900317f5eff0a7070c5936e5383f589e0de7a09 ] David and HacKurx reported a following/similar size overflow triggered in a grsecurity kernel, thanks to PaX's gcc size overflow plugin: (Already fixed in later grsecurity versions by Brad and PaX Team.) [ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314 cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr; [ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ #7 [ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...] [ 1002.296153] ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8 [ 1002.296162] ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8 [ 1002.296169] ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60 [ 1002.296176] Call Trace: [ 1002.296190] [] dump_stack+0x45/0x57 [ 1002.296200] [] report_size_overflow+0x38/0x60 [ 1002.296209] [] scm_detach_fds+0x2ce/0x300 [ 1002.296220] [] unix_stream_read_generic+0x609/0x930 [ 1002.296228] [] unix_stream_recvmsg+0x4f/0x60 [ 1002.296236] [] ? unix_set_peek_off+0x50/0x50 [ 1002.296243] [] sock_recvmsg+0x47/0x60 [ 1002.296248] [] ___sys_recvmsg+0xe2/0x1e0 [ 1002.296257] [] __sys_recvmsg+0x46/0x80 [ 1002.296263] [] SyS_recvmsg+0x2c/0x40 [ 1002.296271] [] entry_SYSCALL_64_fastpath+0x12/0x85 Further investigation showed that this can happen when an *odd* number of fds are being passed over AF_UNIX sockets. In these cases CMSG_LEN(i * sizeof(int)) and CMSG_SPACE(i * sizeof(int)), where i is the number of successfully passed fds, differ by 4 bytes due to the extra CMSG_ALIGN() padding in CMSG_SPACE() to an 8 byte boundary on 64 bit. The padding is used to align subsequent cmsg headers in the control buffer. When the control buffer passed in from the receiver side *lacks* these 4 bytes (e.g. due to buggy/wrong API usage), then msg->msg_controllen will overflow in scm_detach_fds(): int cmlen = CMSG_LEN(i * sizeof(int)); <--- cmlen w/o tail-padding err = put_user(SOL_SOCKET, &cm->cmsg_level); if (!err) err = put_user(SCM_RIGHTS, &cm->cmsg_type); if (!err) err = put_user(cmlen, &cm->cmsg_len); if (!err) { cmlen = CMSG_SPACE(i * sizeof(int)); <--- cmlen w/ 4 byte extra tail-padding msg->msg_control += cmlen; msg->msg_controllen -= cmlen; <--- iff no tail-padding space here ... } ... wrap-around F.e. it will wrap to a length of 18446744073709551612 bytes in case the receiver passed in msg->msg_controllen of 20 bytes, and the sender properly transferred 1 fd to the receiver, so that its CMSG_LEN results in 20 bytes and CMSG_SPACE in 24 bytes. In case of MSG_CMSG_COMPAT (scm_detach_fds_compat()), I haven't seen an issue in my tests as alignment seems always on 4 byte boundary. Same should be in case of native 32 bit, where we end up with 4 byte boundaries as well. In practice, passing msg->msg_controllen of 20 to recvmsg() while receiving a single fd would mean that on successful return, msg->msg_controllen is being set by the kernel to 24 bytes instead, thus more than the input buffer advertised. It could f.e. become an issue if such application later on zeroes or copies the control buffer based on the returned msg->msg_controllen elsewhere. Maximum number of fds we can send is a hard upper limit SCM_MAX_FD (253). Going over the code, it seems like msg->msg_controllen is not being read after scm_detach_fds() in scm_recv() anymore by the kernel, good! Relevant recvmsg() handler are unix_dgram_recvmsg() (unix_seqpacket_recvmsg()) and unix_stream_recvmsg(). Both return back to their recvmsg() caller, and ___sys_recvmsg() places the updated length, that is, new msg_control - old msg_control pointer into msg->msg_controllen (hence the 24 bytes seen in the example). Long time ago, Wei Yongjun fixed something related in commit 1ac70e7ad24a ("[NET]: Fix function put_cmsg() which may cause usr application memory overflow"). RFC3542, section 20.2. says: The fields shown as "XX" are possible padding, between the cmsghdr structure and the data, and between the data and the next cmsghdr structure, if required by the implementation. While sending an application may or may not include padding at the end of last ancillary data in msg_controllen and implementations must accept both as valid. On receiving a portable application must provide space for padding at the end of the last ancillary data as implementations may copy out the padding at the end of the control message buffer and include it in the received msg_controllen. When recvmsg() is called if msg_controllen is too small for all the ancillary data items including any trailing padding after the last item an implementation may set MSG_CTRUNC. Since we didn't place MSG_CTRUNC for already quite a long time, just do the same as in 1ac70e7ad24a to avoid an overflow. Btw, even man-page author got this wrong :/ See db939c9b26e9 ("cmsg.3: Fix error in SCM_RIGHTS code sample"). Some people must have copied this (?), thus it got triggered in the wild (reported several times during boot by David and HacKurx). No Fixes tag this time as pre 2002 (that is, pre history tree). Reported-by: David Sterba Reported-by: HacKurx Cc: PaX Team Cc: Emese Revfy Cc: Brad Spengler Cc: Wei Yongjun Cc: Eric Dumazet Reviewed-by: Hannes Frederic Sowa Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d76c6f791676f1a27fcfad0031209e70509e226 Author: Eric Dumazet Date: Thu Nov 26 08:18:14 2015 -0800 tcp: initialize tp->copied_seq in case of cross SYN connection [ Upstream commit 142a2e7ece8d8ac0e818eb2c91f99ca894730e2a ] Dmitry provided a syzkaller (http://github.com/google/syzkaller) generated program that triggers the WARNING at net/ipv4/tcp.c:1729 in tcp_recvmsg() : WARN_ON(tp->copied_seq != tp->rcv_nxt && !(flags & (MSG_PEEK | MSG_TRUNC))); His program is specifically attempting a Cross SYN TCP exchange, that we support (for the pleasure of hackers ?), but it looks we lack proper tcp->copied_seq initialization. Thanks again Dmitry for your report and testings. Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ea5ef9fc2c94fd0156d4671f2327d14f830ec80b Author: Eric Dumazet Date: Wed Nov 18 21:03:33 2015 -0800 tcp: fix potential huge kmalloc() calls in TCP_REPAIR [ Upstream commit 5d4c9bfbabdb1d497f21afd81501e5c54b0c85d9 ] tcp_send_rcvq() is used for re-injecting data into tcp receive queue. Problems : - No check against size is performed, allowed user to fool kernel in attempting very large memory allocations, eventually triggering OOM when memory is fragmented. - In case of fault during the copy we do not return correct errno. Lets use alloc_skb_with_frags() to cook optimal skbs. Fixes: 292e8d8c8538 ("tcp: Move rcvq sending to tcp_input.c") Fixes: c0e88ff0f256 ("tcp: Repair socket queues") Signed-off-by: Eric Dumazet Cc: Pavel Emelyanov Acked-by: Pavel Emelyanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7af8323046e487cf0f9f0e9d202cf8f78b0225af Author: Eric Dumazet Date: Wed Nov 18 12:40:13 2015 -0800 tcp: md5: fix lockdep annotation [ Upstream commit 1b8e6a01e19f001e9f93b39c32387961c91ed3cc ] When a passive TCP is created, we eventually call tcp_md5_do_add() with sk pointing to the child. It is not owner by the user yet (we will add this socket into listener accept queue a bit later anyway) But we do own the spinlock, so amend the lockdep annotation to avoid following splat : [ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage! [ 8451.090932] [ 8451.090932] other info that might help us debug this: [ 8451.090932] [ 8451.090934] [ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1 [ 8451.090936] 3 locks held by socket_sockopt_/214795: [ 8451.090936] #0: (rcu_read_lock){.+.+..}, at: [] __netif_receive_skb_core+0x151/0xe90 [ 8451.090947] #1: (rcu_read_lock){.+.+..}, at: [] ip_local_deliver_finish+0x43/0x2b0 [ 8451.090952] #2: (slock-AF_INET){+.-...}, at: [] sk_clone_lock+0x1c5/0x500 [ 8451.090958] [ 8451.090958] stack backtrace: [ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_ [ 8451.091215] Call Trace: [ 8451.091216] [] dump_stack+0x55/0x76 [ 8451.091229] [] lockdep_rcu_suspicious+0xeb/0x110 [ 8451.091235] [] tcp_md5_do_add+0x1bf/0x1e0 [ 8451.091239] [] tcp_v4_syn_recv_sock+0x1f1/0x4c0 [ 8451.091242] [] ? tcp_v4_md5_hash_skb+0x167/0x190 [ 8451.091246] [] tcp_check_req+0x3c8/0x500 [ 8451.091249] [] ? tcp_v4_inbound_md5_hash+0x11e/0x190 [ 8451.091253] [] tcp_v4_rcv+0x3c0/0x9f0 [ 8451.091256] [] ? ip_local_deliver_finish+0x43/0x2b0 [ 8451.091260] [] ip_local_deliver_finish+0xb6/0x2b0 [ 8451.091263] [] ? ip_local_deliver_finish+0x43/0x2b0 [ 8451.091267] [] ip_local_deliver+0x48/0x80 [ 8451.091270] [] ip_rcv_finish+0x160/0x700 [ 8451.091273] [] ip_rcv+0x29e/0x3d0 [ 8451.091277] [] __netif_receive_skb_core+0xb47/0xe90 Fixes: a8afca0329988 ("tcp: md5: protects md5sig_info with RCU") Signed-off-by: Eric Dumazet Reported-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 922e1fd3808b517fb1dba27e8d277d3deb11f1a6 Author: Bjørn Mork Date: Wed Nov 18 21:13:07 2015 +0100 net: qmi_wwan: add XS Stick W100-2 from 4G Systems [ Upstream commit 68242a5a1e2edce39b069385cbafb82304eac0f1 ] Thomas reports " 4gsystems sells two total different LTE-surfsticks under the same name. .. The newer version of XS Stick W100 is from "omega" .. Under windows the driver switches to the same ID, and uses MI03\6 for network and MI01\6 for modem. .. echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=9b01 Rev=02.32 S: Manufacturer=USB Modem S: Product=USB Modem S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Now all important things are there: wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at) There is also ttyUSB0, but it is not usable, at least not for at. The device works well with qmi and ModemManager-NetworkManager. " Reported-by: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a3fd7012c7e9364de7817fc28dd9eaf6ea4d6325 Author: Neil Horman Date: Mon Nov 16 13:09:10 2015 -0500 snmp: Remove duplicate OUTMCAST stat increment [ Upstream commit 41033f029e393a64e81966cbe34d66c6cf8a2e7e ] the OUTMCAST stat is double incremented, getting bumped once in the mcast code itself, and again in the common ip output path. Remove the mcast bump, as its not needed Validated by the reporter, with good results Signed-off-by: Neil Horman Reported-by: Claus Jensen CC: Claus Jensen CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6cc44e6968fa1daa77fe2931a3c42da0821c4fdc Author: Jason A. Donenfeld Date: Thu Nov 12 17:35:58 2015 +0100 ip_tunnel: disable preemption when updating per-cpu tstats [ Upstream commit b4fe85f9c9146f60457e9512fb6055e69e6a7a65 ] Drivers like vxlan use the recently introduced udp_tunnel_xmit_skb/udp_tunnel6_xmit_skb APIs. udp_tunnel6_xmit_skb makes use of ip6tunnel_xmit, and ip6tunnel_xmit, after sending the packet, updates the struct stats using the usual u64_stats_update_begin/end calls on this_cpu_ptr(dev->tstats). udp_tunnel_xmit_skb makes use of iptunnel_xmit, which doesn't touch tstats, so drivers like vxlan, immediately after, call iptunnel_xmit_stats, which does the same thing - calls u64_stats_update_begin/end on this_cpu_ptr(dev->tstats). While vxlan is probably fine (I don't know?), calling a similar function from, say, an unbound workqueue, on a fully preemptable kernel causes real issues: [ 188.434537] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u8:0/6 [ 188.435579] caller is debug_smp_processor_id+0x17/0x20 [ 188.435583] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.6 #2 [ 188.435607] Call Trace: [ 188.435611] [] dump_stack+0x4f/0x7b [ 188.435615] [] check_preemption_disabled+0x19d/0x1c0 [ 188.435619] [] debug_smp_processor_id+0x17/0x20 The solution would be to protect the whole this_cpu_ptr(dev->tstats)/u64_stats_update_begin/end blocks with disabling preemption and then reenabling it. Signed-off-by: Jason A. Donenfeld Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 84564ff43407756dfc7018177d78a0de8d1bd4b2 Author: lucien Date: Thu Nov 12 13:07:07 2015 +0800 sctp: translate host order to network order when setting a hmacid [ Upstream commit ed5a377d87dc4c87fb3e1f7f698cba38cd893103 ] now sctp auth cannot work well when setting a hmacid manually, which is caused by that we didn't use the network order for hmacid, so fix it by adding the transformation in sctp_auth_ep_set_hmacs. even we set hmacid with the network order in userspace, it still can't work, because of this condition in sctp_auth_ep_set_hmacs(): if (id > SCTP_AUTH_HMAC_ID_MAX) return -EOPNOTSUPP; so this wasn't working before and thus it won't break compatibility. Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.") Signed-off-by: Xin Long Signed-off-by: Marcelo Ricardo Leitner Acked-by: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29ac1e1e04b77735383fb593a4b1d6b24f0a39e8 Author: Daniel Borkmann Date: Wed Nov 11 23:25:44 2015 +0100 packet: fix tpacket_snd max frame len [ Upstream commit 5cfb4c8d05b4409c4044cb9c05b19705c1d9818b ] Since it's introduction in commit 69e3c75f4d54 ("net: TX_RING and packet mmap"), TX_RING could be used from SOCK_DGRAM and SOCK_RAW side. When used with SOCK_DGRAM only, the size_max > dev->mtu + reserve check should have reserve as 0, but currently, this is unconditionally set (in it's original form as dev->hard_header_len). I think this is not correct since tpacket_fill_skb() would then take dev->mtu and dev->hard_header_len into account for SOCK_DGRAM, the extra VLAN_HLEN could be possible in both cases. Presumably, the reserve code was copied from packet_snd(), but later on missed the check. Make it similar as we have it in packet_snd(). Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Signed-off-by: Daniel Borkmann Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e0bc2c24307db64d6d3d20069344d5ed93bda8ff Author: Daniel Borkmann Date: Wed Nov 11 23:25:43 2015 +0100 packet: infer protocol from ethernet header if unset [ Upstream commit c72219b75fde768efccf7666342282fab7f9e4e7 ] In case no struct sockaddr_ll has been passed to packet socket's sendmsg() when doing a TX_RING flush run, then skb->protocol is set to po->num instead, which is the protocol passed via socket(2)/bind(2). Applications only xmitting can go the path of allocating the socket as socket(PF_PACKET, , 0) and do a bind(2) on the TX_RING with sll_protocol of 0. That way, register_prot_hook() is neither called on creation nor on bind time, which saves cycles when there's no interest in capturing anyway. That leaves us however with po->num 0 instead and therefore the TX_RING flush run sets skb->protocol to 0 as well. Eric reported that this leads to problems when using tools like trafgen over bonding device. I.e. the bonding's hash function could invoke the kernel's flow dissector, which depends on skb->protocol being properly set. In the current situation, all the traffic is then directed to a single slave. Fix it up by inferring skb->protocol from the Ethernet header when not set and we have ARPHRD_ETHER device type. This is only done in case of SOCK_RAW and where we have a dev->hard_header_len length. In case of ARPHRD_ETHER devices, this is guaranteed to cover ETH_HLEN, and therefore being accessed on the skb after the skb_store_bits(). Reported-by: Eric Dumazet Signed-off-by: Daniel Borkmann Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9293664afffe9a2fe04be4f8da1869601c3afba0 Author: Daniel Borkmann Date: Wed Nov 11 23:25:42 2015 +0100 packet: only allow extra vlan len on ethernet devices [ Upstream commit 3c70c132488794e2489ab045559b0ce0afcf17de ] Packet sockets can be used by various net devices and are not really restricted to ARPHRD_ETHER device types. However, when currently checking for the extra 4 bytes that can be transmitted in VLAN case, our assumption is that we generally probe on ARPHRD_ETHER devices. Therefore, before looking into Ethernet header, check the device type first. This also fixes the issue where non-ARPHRD_ETHER devices could have no dev->hard_header_len in TX_RING SOCK_RAW case, and thus the check would test unfilled linear part of the skb (instead of non-linear). Fixes: 57f89bfa2140 ("network: Allow af_packet to transmit +4 bytes for VLAN packets.") Fixes: 52f1454f629f ("packet: allow to transmit +4 byte in TX_RING slot for VLAN case") Signed-off-by: Daniel Borkmann Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e4f3c00338a3ddcc1c222396816d18a670ac4e67 Author: Alexander Drozdov Date: Tue Jul 28 13:57:01 2015 +0300 packet: tpacket_snd(): fix signed/unsigned comparison [ Upstream commit dbd46ab412b8fb395f2b0ff6f6a7eec9df311550 ] tpacket_fill_skb() can return a negative value (-errno) which is stored in tp_len variable. In that case the following condition will be (but shouldn't be) true: tp_len > dev->mtu + dev->hard_header_len as dev->mtu and dev->hard_header_len are both unsigned. That may lead to just returning an incorrect EMSGSIZE errno to the user. Fixes: 52f1454f629fa ("packet: allow to transmit +4 byte in TX_RING slot for VLAN case") Signed-off-by: Alexander Drozdov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 302c63565452db0bdb065605ad227c88ec93d4e8 Author: Daniel Borkmann Date: Wed Nov 11 23:25:41 2015 +0100 packet: always probe for transport header [ Upstream commit 8fd6c80d9dd938ca338c70698533a7e304752846 ] We concluded that the skb_probe_transport_header() should better be called unconditionally. Avoiding the call into the flow dissector has also not really much to do with the direct xmit mode. While it seems that only virtio_net code makes use of GSO from non RX/TX ring packet socket paths, we should probe for a transport header nevertheless before they hit devices. Reference: http://thread.gmane.org/gmane.linux.network/386173/ Signed-off-by: Daniel Borkmann Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 22fb967dc3ca91edb8298373d64beaec4a572373 Author: Daniel Borkmann Date: Wed Nov 11 23:25:40 2015 +0100 packet: do skb_probe_transport_header when we actually have data [ Upstream commit efdfa2f7848f64517008136fb41f53c4a1faf93a ] In tpacket_fill_skb() commit c1aad275b029 ("packet: set transport header before doing xmit") and later on 40893fd0fd4e ("net: switch to use skb_probe_transport_header()") was probing for a transport header on the skb from a ring buffer slot, but at a time, where the skb has _not even_ been filled with data yet. So that call into the flow dissector is pretty useless. Lets do it after we've set up the skb frags. Fixes: c1aad275b029 ("packet: set transport header before doing xmit") Reported-by: Eric Dumazet Signed-off-by: Daniel Borkmann Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e5d4fd3e2e4c0b373473fca676e40a8c4bee8b07 Author: Kamal Mostafa Date: Wed Nov 11 14:24:27 2015 -0800 tools/net: Use include/uapi with __EXPORTED_HEADERS__ [ Upstream commit d7475de58575c904818efa369c82e88c6648ce2e ] Use the local uapi headers to keep in sync with "recently" added #define's (e.g. SKF_AD_VLAN_TPID). Refactored CFLAGS, and bpf_asm doesn't need -I. Fixes: 3f356385e8a4 ("filter: bpf_asm: add minimal bpf asm tool") Signed-off-by: Kamal Mostafa Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3653158c9492ead7452ce59089b33c0d831330c8 Author: Sasha Levin Date: Mon Dec 14 12:11:09 2015 -0500 Revert "net: Fix skb_set_peeked use-after-free bug" This reverts commit d9a1133495b487154ac351cd33b26b416e966d2d. commit a9ff3cb5ec5a60c9b9a5dc3d1e870bdb29451f0a Author: Marcelo Leitner Date: Mon Feb 23 11:17:13 2015 -0300 ipv6: addrconf: validate new MTU before applying it [ Upstream commit 77751427a1ff25b27d47a4c36b12c3c8667855ac ] Currently we don't check if the new MTU is valid or not and this allows one to configure a smaller than minimum allowed by RFCs or even bigger than interface own MTU, which is a problem as it may lead to packet drops. If you have a daemon like NetworkManager running, this may be exploited by remote attackers by forging RA packets with an invalid MTU, possibly leading to a DoS. (NetworkManager currently only validates for values too small, but not for too big ones.) The fix is just to make sure the new value is valid. That is, between IPV6_MIN_MTU and interface's MTU. Note that similar check is already performed at ndisc_router_discovery(), for when kernel itself parses the RA. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b4df4648d73b9794f2a15f75ebb43d609d72694 Author: Nadav Amit Date: Thu Sep 18 22:39:40 2014 +0300 KVM: x86: Use new is_noncanonical_address in _linearize [ Upstream commit 4be4de7ef9fd3a4d77320d4713970299ffecd286 ] Replace the current canonical address check with the new function which is identical. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 79e62de2efb2f586726e46342c792360a9644319 Author: Eric Northup Date: Tue Nov 3 18:03:53 2015 +0100 KVM: x86: work around infinite loop in microcode when #AC is delivered [ Upstream commit 54a20552e1eae07aa240fa370a0293e006b5faed ] It was found that a guest can DoS a host by triggering an infinite stream of "alignment check" (#AC) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics pretty quickly due to the effects (CVE-2015-5307). Signed-off-by: Eric Northup Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a62b833dd4af3c58b839317367b0586a5ca12669 Author: Florian Fainelli Date: Sat Oct 3 13:03:47 2015 -0700 ARM: orion: Fix DSA platform device after mvmdio conversion [ Upstream commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 ] DSA expects the host_dev pointer to be the device structure associated with the MDIO bus controller driver. First commit breaking that was c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver"), and then, it got completely under the radar for a while. Reported-by: Frans van de Wiel Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver") CC: stable@vger.kernel.org Signed-off-by: Florian Fainelli Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit cf6580ef92b0f5baf6f9a0ff2c51d852ba5145ba Author: Sasha Levin Date: Tue Sep 8 10:53:40 2015 -0400 RDS: verify the underlying transport exists before creating a connection [ Upstream commit 74e98eb085889b0d2d4908f59f6e00026063014f ] There was no verification that an underlying transport exists when creating a connection, this would cause dereferencing a NULL ptr. It might happen on sockets that weren't properly bound before attempting to send a message, which will cause a NULL ptr deref: [135546.047719] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [135546.051270] Modules linked in: [135546.051781] CPU: 4 PID: 15650 Comm: trinity-c4 Not tainted 4.2.0-next-20150902-sasha-00041-gbaa1222-dirty #2527 [135546.053217] task: ffff8800835bc000 ti: ffff8800bc708000 task.ti: ffff8800bc708000 [135546.054291] RIP: __rds_conn_create (net/rds/connection.c:194) [135546.055666] RSP: 0018:ffff8800bc70fab0 EFLAGS: 00010202 [135546.056457] RAX: dffffc0000000000 RBX: 0000000000000f2c RCX: ffff8800835bc000 [135546.057494] RDX: 0000000000000007 RSI: ffff8800835bccd8 RDI: 0000000000000038 [135546.058530] RBP: ffff8800bc70fb18 R08: 0000000000000001 R09: 0000000000000000 [135546.059556] R10: ffffed014d7a3a23 R11: ffffed014d7a3a21 R12: 0000000000000000 [135546.060614] R13: 0000000000000001 R14: ffff8801ec3d0000 R15: 0000000000000000 [135546.061668] FS: 00007faad4ffb700(0000) GS:ffff880252000000(0000) knlGS:0000000000000000 [135546.062836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [135546.063682] CR2: 000000000000846a CR3: 000000009d137000 CR4: 00000000000006a0 [135546.064723] Stack: [135546.065048] ffffffffafe2055c ffffffffafe23fc1 ffffed00493097bf ffff8801ec3d0008 [135546.066247] 0000000000000000 00000000000000d0 0000000000000000 ac194a24c0586342 [135546.067438] 1ffff100178e1f78 ffff880320581b00 ffff8800bc70fdd0 ffff880320581b00 [135546.068629] Call Trace: [135546.069028] ? __rds_conn_create (include/linux/rcupdate.h:856 net/rds/connection.c:134) [135546.069989] ? rds_message_copy_from_user (net/rds/message.c:298) [135546.071021] rds_conn_create_outgoing (net/rds/connection.c:278) [135546.071981] rds_sendmsg (net/rds/send.c:1058) [135546.072858] ? perf_trace_lock (include/trace/events/lock.h:38) [135546.073744] ? lockdep_init (kernel/locking/lockdep.c:3298) [135546.074577] ? rds_send_drop_to (net/rds/send.c:976) [135546.075508] ? __might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3795) [135546.076349] ? __might_fault (mm/memory.c:3795) [135546.077179] ? rds_send_drop_to (net/rds/send.c:976) [135546.078114] sock_sendmsg (net/socket.c:611 net/socket.c:620) [135546.078856] SYSC_sendto (net/socket.c:1657) [135546.079596] ? SYSC_connect (net/socket.c:1628) [135546.080510] ? trace_dump_stack (kernel/trace/trace.c:1926) [135546.081397] ? ring_buffer_unlock_commit (kernel/trace/ring_buffer.c:2479 kernel/trace/ring_buffer.c:2558 kernel/trace/ring_buffer.c:2674) [135546.082390] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749) [135546.083410] ? trace_event_raw_event_sys_enter (include/trace/events/syscalls.h:16) [135546.084481] ? do_audit_syscall_entry (include/trace/events/syscalls.h:16) [135546.085438] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749) [135546.085515] rds_ib_laddr_check(): addr 36.74.25.172 ret -99 node type -1 Acked-by: Santosh Shilimkar Signed-off-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f236cda193b0f27d44c8f6f6809036e7246074fc Author: Francesco Ruggeri Date: Thu Nov 5 08:16:14 2015 -0800 packet: race condition in packet_bind [ Upstream commit 30f7ea1c2b5f5fb7462c5ae44fe2e40cb2d6a474 ] There is a race conditions between packet_notifier and packet_bind{_spkt}. It happens if packet_notifier(NETDEV_UNREGISTER) executes between the time packet_bind{_spkt} takes a reference on the new netdevice and the time packet_do_bind sets po->ifindex. In this case the notification can be missed. If this happens during a dev_change_net_namespace this can result in the netdevice to be moved to the new namespace while the packet_sock in the old namespace still holds a reference on it. When the netdevice is later deleted in the new namespace the deletion hangs since the packet_sock is not found in the new namespace' &net->packet.sklist. It can be reproduced with the script below. This patch makes packet_do_bind check again for the presence of the netdevice in the packet_sock's namespace after the synchronize_net in unregister_prot_hook. More in general it also uses the rcu lock for the duration of the bind to stop dev_change_net_namespace/rollback_registered_many from going past the synchronize_net following unlist_netdevice, so that no NETDEV_UNREGISTER notifications can happen on the new netdevice while the bind is executing. In order to do this some code from packet_bind{_spkt} is consolidated into packet_do_dev. import socket, os, time, sys proto=7 realDev='em1' vlanId=400 if len(sys.argv) > 1: vlanId=int(sys.argv[1]) dev='vlan%d' % vlanId os.system('taskset -p 0x10 %d' % os.getpid()) s = socket.socket(socket.PF_PACKET, socket.SOCK_RAW, proto) os.system('ip link add link %s name %s type vlan id %d' % (realDev, dev, vlanId)) os.system('ip netns add dummy') pid=os.fork() if pid == 0: # dev should be moved while packet_do_bind is in synchronize net os.system('taskset -p 0x20000 %d' % os.getpid()) os.system('ip link set %s netns dummy' % dev) os.system('ip netns exec dummy ip link del %s' % dev) s.close() sys.exit(0) time.sleep(.004) try: s.bind(('%s' % dev, proto+1)) except: print 'Could not bind socket' s.close() os.system('ip netns del dummy') sys.exit(0) os.waitpid(pid, 0) s.close() os.system('ip netns del dummy') sys.exit(0) Signed-off-by: Francesco Ruggeri Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 59fed94ad802b5c3fe337807da1cae6be1a957ac Author: WANG Cong Date: Tue Nov 3 14:32:57 2015 -0800 ipv4: disable BH when changing ip local port range [ Upstream commit 4ee3bd4a8c7463cdef0b82ebc33fc94a9170a7e0 ] This fixes the following lockdep warning: [ INFO: inconsistent lock state ] 4.3.0-rc7+ #1197 Not tainted --------------------------------- inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage. sysctl/1019 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&net->ipv4.ip_local_ports.lock)->seqcount){+.+-..}, at: [] ipv4_local_port_range+0xb4/0x12a {IN-SOFTIRQ-R} state was registered at: [] __lock_acquire+0x2f6/0xdf0 [] lock_acquire+0x11c/0x1a4 [] inet_get_local_port_range+0x4e/0xae [] udp_flow_src_port.constprop.40+0x23/0x116 [] vxlan_xmit_one+0x219/0xa6a [] vxlan_xmit+0xa6b/0xaa5 [] dev_hard_start_xmit+0x2ae/0x465 [] __dev_queue_xmit+0x531/0x633 [] dev_queue_xmit_sk+0x13/0x15 [] neigh_resolve_output+0x12f/0x14d [] ip6_finish_output2+0x344/0x39f [] ip6_finish_output+0x88/0x8e [] ip6_output+0x91/0xe5 [] dst_output_sk+0x47/0x4c [] NF_HOOK_THRESH.constprop.30+0x38/0x82 [] mld_sendpack+0x189/0x266 [] mld_ifc_timer_expire+0x1ef/0x223 [] call_timer_fn+0xfb/0x28c [] run_timer_softirq+0x1c7/0x1f1 Fixes: b8f1a55639e6 ("udp: Add function to make source port for UDP tunnels") Cc: Tom Herbert Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8d135fedee7e84a0d7f4dc20919d40e40d71fb8c Author: Sabrina Dubroca Date: Wed Nov 4 14:47:53 2015 +0100 ipv6: clean up dev_snmp6 proc entry when we fail to initialize inet6_dev [ Upstream commit 2a189f9e57650e9f310ddf4aad75d66c1233a064 ] In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up the dev_snmp6 entry that we have already registered for this device. Call snmp6_unregister_dev in this case. Fixes: a317a2f19da7d ("ipv6: fail early when creating netdev named all or default") Reported-by: Dmitry Vyukov Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 725242ca67ab5fdba61e2026ff411e96a854ebe5 Author: Martin Habets Date: Mon Nov 2 12:51:31 2015 +0000 sfc: push partner queue for skb->xmit_more [ Upstream commit b2663a4f30e85ec606b806f5135413e6d5c78d1e ] When the IP stack passes SKBs the sfc driver puts them in 2 different TX queues (called partners), one for checksummed and one for not checksummed. If the SKB has xmit_more set the driver will delay pushing the work to the NIC. When later it does decide to push the buffers this patch ensures it also pushes the partner queue, if that also has any delayed work. Before this fix the work in the partner queue would be left for a long time and cause a netdev watchdog. Fixes: 70b33fb ("sfc: add support for skb->xmit_more") Reported-by: Jianlin Shi Signed-off-by: Martin Habets Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 624fe175b82e2933717e97dc93fd154fe333d701 Author: Eric Dumazet Date: Mon Nov 2 17:08:19 2015 -0800 sit: fix sit0 percpu double allocations [ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ] sit0 device allocates its percpu storage twice : - One time in ipip6_tunnel_init() - One time in ipip6_fb_tunnel_init() Thus we leak 48 bytes per possible cpu per network namespace dismantle. ipip6_fb_tunnel_init() can be much simpler and does not return an error, and should be called after register_netdev() Note that ipip6_tunnel_clone_6rd() also needs to be called after register_netdev() (calling ipip6_tunnel_init()) Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.") Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Cc: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bcabffc26b55c2e2da5ed249e7488d5494eebc30 Author: Eric Dumazet Date: Sat Oct 24 05:47:44 2015 -0700 ipv6: gre: support SIT encapsulation [ Upstream commit 7e3b6e7423d5f994257c1de88e06b509673fdbcf ] gre_gso_segment() chokes if SIT frames were aggregated by GRO engine. Fixes: 61c1db7fae21e ("ipv6: sit: add GSO/TSO support") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 19f59729257b2e3c7de8560f3bdfe293ab8d5553 Author: Bjørn Mork Date: Thu Oct 22 14:15:58 2015 +0200 qmi_wwan: add Sierra Wireless MC74xx/EM74xx [ Upstream commit 0db65fcfcded76fe4f74e3ca9f4e2baf67b683ef ] New device IDs shamelessly lifted from the vendor driver. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit feeb0406f75ae3488ff6573903533000125b2faf Author: Jason Wang Date: Wed Aug 5 10:34:04 2015 +0800 virtio-net: drop NETIF_F_FRAGLIST [ Upstream commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 ] virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5bac169bb395d81ea3e7e824cb7b9682166ab991 Author: Eric Dumazet Date: Mon Nov 9 17:51:23 2015 -0800 net: fix a race in dst_release() [ Upstream commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 ] Only cpu seeing dst refcount going to 0 can safely dereference dst->flags. Otherwise an other cpu might already have freed the dst. Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst") Reported-by: Greg Thelen Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b2567c1c3e78d35dab01ac1f3f8331d42d3df062 Author: Eric Dumazet Date: Fri Oct 2 16:54:31 2015 -0700 net: avoid NULL deref in inet_ctl_sock_destroy() [ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ] Under low memory conditions, tcp_sk_init() and icmp_sk_init() can both iterate on all possible cpus and call inet_ctl_sock_destroy(), with eventual NULL pointer. Signed-off-by: Eric Dumazet Reported-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3e72d9e9b537883e140a9814778fa0b86df0330 Author: Bjørn Mork Date: Thu Oct 1 16:54:31 2015 -0700 qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module [ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ] The lt4112 is a HP branded Huawei me906e modem. Like other Huawei modems, it does not have a fixed interface to function mapping. Instead it uses a Huawei specific scheme: functions are mapped by subclass and protocol. However, the HP vendor ID is used for modems from many different manufacturers using different schemes, so we cannot apply a generic vendor rule like we do for the Huawei vendor ID. Replace the previous lt4112 entry pointing to an arbitrary interface number with a device specific subclass + protocol match. Reported-and-tested-by: Muri Nicanor Tested-by: Martin Hauke Fixes: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 37d4671cc4ee4dec336752740d591adb0d3f0768 Author: Ani Sinha Date: Fri Oct 30 16:54:31 2015 -0700 ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context. [ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ] Fixes the following kernel BUG : BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758 caller is __this_cpu_preempt_check+0x13/0x15 CPU: 0 PID: 2758 Comm: bash Tainted: P O 3.18.19 #2 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8 Call Trace: [] dump_stack+0x52/0x80 [] check_preemption_disabled+0xce/0xe1 [] __this_cpu_preempt_check+0x13/0x15 [] ipmr_queue_xmit+0x647/0x70c [] ip_mr_forward+0x32f/0x34e [] ip_mroute_setsockopt+0xe03/0x108c [] ? get_parent_ip+0x11/0x42 [] ? pollwake+0x4d/0x51 [] ? default_wake_function+0x0/0xf [] ? get_parent_ip+0x11/0x42 [] ? __wake_up_common+0x45/0x77 [] ? _raw_spin_unlock_irqrestore+0x1d/0x32 [] ? __wake_up_sync_key+0x4a/0x53 [] ? sock_def_readable+0x71/0x75 [] do_ip_setsockopt+0x9d/0xb55 [] ? unix_seqpacket_sendmsg+0x3f/0x41 [] ? sock_sendmsg+0x6d/0x86 [] ? sockfd_lookup_light+0x12/0x5d [] ? SyS_sendto+0xf3/0x11b [] ? new_sync_read+0x82/0xaa [] compat_ip_setsockopt+0x3b/0x99 [] compat_raw_setsockopt+0x11/0x32 [] compat_sock_common_setsockopt+0x18/0x1f [] compat_SyS_setsockopt+0x1a9/0x1cf [] compat_SyS_socketcall+0x180/0x1e3 [] cstar_dispatch+0x7/0x1e Signed-off-by: Ani Sinha Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 242f8dfc364f388ee48a7b405feab660cc6549da Author: Phil Reid Date: Fri Oct 30 16:43:55 2015 +0800 stmmac: Correctly report PTP capabilities. [ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ] priv->hwts_*_en indicate if timestamping is enabled/disabled at run time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp indicates HW is support for PTPv1/PTPv2. Signed-off-by: Phil Reid Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2e0ad74df3daf2b172e2d578875ab9a553a80469 Author: Carol L Soto Date: Tue Oct 27 17:36:20 2015 +0200 net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes [ Upstream commit c02b05011fadf8e409e41910217ca689f2fc9d91 ] When doing memcpy/memset of EQEs, we should use sizeof struct mlx4_eqe as the base size and not caps.eqe_size which could be bigger. If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt data in the master context. When using a 64 byte stride, the memcpy copied over 63 bytes to the slave_eq structure. This resulted in copying over the entire eqe of interest, including its ownership bit -- and also 31 bytes of garbage into the next WQE in the slave EQ -- which did NOT include the ownership bit (and therefore had no impact). However, once the stride is increased to 128, we are overwriting the ownership bits of *three* eqes in the slave_eq struct. This results in an incorrect ownership bit for those eqes, which causes the eq to seem to be full. The issue therefore surfaced only once 128-byte EQEs started being used in SRIOV and (overarchitectures that have 128/256 byte cache-lines such as PPC) - e.g after commit 77507aa249ae "net/mlx4_core: Enable CQE/EQE stride support". Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support') Signed-off-by: Carol L Soto Signed-off-by: Jack Morgenstein Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f21dcba4a3dfc307bacf8d0fa85da41895cdd3b Author: Sowmini Varadhan Date: Mon Oct 26 12:46:37 2015 -0400 RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv [ Upstream commit 8ce675ff39b9958d1c10f86cf58e357efaafc856 ] Either of pskb_pull() or pskb_trim() may fail under low memory conditions. If rds_tcp_data_recv() ignores such failures, the application will receive corrupted data because the skb has not been correctly carved to the RDS datagram size. Avoid this by handling pskb_pull/pskb_trim failure in the same manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and retry via the deferred call to rds_send_worker() that gets set up on ENOMEM from rds_tcp_read_sock() Signed-off-by: Sowmini Varadhan Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3a98eb90a63c50e72f388e37a2c4a7dd327be369 Author: Guillaume Nault Date: Thu Oct 22 16:57:10 2015 +0200 ppp: fix pppoe_dev deletion condition in pppoe_release() [ Upstream commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 ] We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev. PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies (po->pppoe_dev != NULL). Since we're releasing a PPPoE socket, we want to release the pppoe_dev if it exists and reset sk_state to PPPOX_DEAD, no matter the previous value of sk_state. So we can just check for po->pppoe_dev and avoid any assumption on sk->sk_state. Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c86d8c538078d03e2febbc33c51ecfb5e9197b00 Author: Jason Wang Date: Fri Oct 23 00:57:05 2015 -0400 macvtap: unbreak receiving of gro skb with frag list [ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ] We don't have fraglist support in TAP_FEATURES. This will lead software segmentation of gro skb with frag list. Fixes by having frag list support in TAP_FEATURES. With this patch single session of netperf receiving were restored from about 5Gb/s to about 12Gb/s on mlx4. Fixes a567dd6252 ("macvtap: simplify usage of tap_features") Cc: Vlad Yasevich Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e05f5d8ac8d0a3d386a4f582a8cadf3c0285bbc Author: Dan Carpenter Date: Mon Oct 19 13:16:49 2015 +0300 irda: precedence bug in irlmp_seq_hb_idx() [ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ] This is decrementing the pointer, instead of the value stored in the pointer. KASan detects it as an out of bounds reference. Reported-by: "Berry Cheng 程君(成淼)" Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 628306a21a28bfad0c9caeb0328436ff34aaa809 Author: Paul Moore Date: Tue Dec 30 09:26:21 2014 -0500 audit: create private file name copies when auditing inodes [ Upstream commit fcf22d8267ad2601fe9b6c549d1be96401c23e0b ] Unfortunately, while commit 4a928436 ("audit: correctly record file names with different path name types") fixed a problem where we were not recording filenames, it created a new problem by attempting to use these file names after they had been freed. This patch resolves the issue by creating a copy of the filename which the audit subsystem frees after it is done with the string. At some point it would be nice to resolve this issue with refcounts, or something similar, instead of having to allocate/copy strings, but that is almost surely beyond the scope of a -rcX patch so we'll defer that for later. On the plus side, only audit users should be impacted by the string copying. Reported-by: Toralf Foerster Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 6255c1142bf39a27347927441bada1ddcc2dd29c Author: Paul Moore Date: Mon Dec 22 12:27:39 2014 -0500 audit: correctly record file names with different path name types [ Upstream commit 4a92843601ad0f5067f441d2f0dca55bbe18c076 ] There is a problem with the audit system when multiple audit records are created for the same path, each with a different path name type. The root cause of the problem is in __audit_inode() when an exact match (both the path name and path name type) is not found for a path name record; the existing code creates a new path name record, but it never sets the path name in this record, leaving it NULL. This patch corrects this problem by assigning the path name to these newly created records. There are many ways to reproduce this problem, but one of the easiest is the following (assuming auditd is running): # mkdir /root/tmp/test # touch /root/tmp/test/567 # auditctl -a always,exit -F dir=/root/tmp/test # touch /root/tmp/test/567 Afterwards, or while the commands above are running, check the audit log and pay special attention to the PATH records. A faulty kernel will display something like the following for the file creation: type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch" type=CWD msg=audit(1416957442.025:93): cwd="/root/tmp" type=PATH msg=audit(1416957442.025:93): item=0 name="test/" inode=401409 ... nametype=PARENT type=PATH msg=audit(1416957442.025:93): item=1 name=(null) inode=393804 ... nametype=NORMAL type=PATH msg=audit(1416957442.025:93): item=2 name=(null) inode=393804 ... nametype=NORMAL While a patched kernel will show the following: type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch" type=CWD msg=audit(1416955786.566:89): cwd="/root/tmp" type=PATH msg=audit(1416955786.566:89): item=0 name="test/" inode=401409 ... nametype=PARENT type=PATH msg=audit(1416955786.566:89): item=1 name="test/567" inode=393804 ... nametype=NORMAL This issue was brought up by a number of people, but special credit should go to hujianyang@huawei.com for reporting the problem along with an explanation of the problem and a patch. While the original patch did have some problems (see the archive link below), it did demonstrate the problem and helped kickstart the fix presented here. * https://lkml.org/lkml/2014/9/5/66 Reported-by: hujianyang Signed-off-by: Paul Moore Acked-by: Richard Guy Briggs Signed-off-by: Sasha Levin commit 654484aa13c5a55879405b340148992ee1da3b56 Author: Dan Carpenter Date: Fri Jul 3 11:53:03 2015 +0300 mptfusion: prevent some memory corruption [ Upstream commit e819cdb198319cccf4af4fc12ac4d796109d8c23 ] These are signed values the come from the user, we put a cap on the upper bounds but not on the lower bounds. We use "karg.dataSgeOffset" to calculate "sz". We verify "sz" and proceed as if that means that "karg.dataSgeOffset" is correct but this fails to consider that the "sz" calculations can have integer overflows. Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit 7bb11a7b9027a87d9dcde4d4b16a8f208083154c Author: Charles Keepax Date: Tue Jul 7 15:28:13 2015 +0100 mfd: wm5110: Add register patch for rev E and above [ Upstream commit 81207880cef207cd89db863f9aa1d65f22b4f2a2 ] Add a register patch for rev E and above that configures the location of some write sequences to assist with the headphone enables. Signed-off-by: Charles Keepax Acked-by: Lee Jones Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 84107ed7c5fd0b03c3b4e5e4bc2fcb5713046b1f Author: Nicholas Mc Guire Date: Sun Jun 7 11:34:40 2015 -0300 [media] gscpa_m5602: use msecs_to_jiffies for conversions [ Upstream commit 63f2f417526fc54191f2b813f72dc1d5322bede8 ] API compliance scanning with coccinelle flagged: ./drivers/media/usb/gspca/m5602/m5602_s5k83a.c:180:9-25: WARNING: timeout (100) seems HZ dependent Numeric constants passed to schedule_timeout() make the effective timeout HZ dependent which makes little sense in a polling loop for the cameras rotation state. Fixed up by converting the constant to jiffies with msecs_to_jiffies() Signed-off-by: Nicholas Mc Guire Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7a278b4cf6ac127e76bb14746cf45015eefb6b69 Author: Nobuhiro Iwamatsu Date: Wed Jan 28 22:53:53 2015 -0200 [media] v4l: vsp1: Fix VI6_WPF_SZCLIP_SIZE_MASK macro [ Upstream commit 03b36e4dcf422a10da8b67bce2ed00b34ec58aac ] Clipping size bit of VI6_WPFn _HSZCLIP and VI6_WPFn _VSZCLIP register are from 0 bit to 11 bit. But VI6_WPF_SZCLIP_SIZE_MASK is set to 0x1FFF, this will mask until the reserve bits. This fixes size for VI6_WPF_SZCLIP_SIZE_MASK. Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 951213811ce656f5dcea686cbc0a36656fc3ffbb Author: Nobuhiro Iwamatsu Date: Wed Jan 28 22:53:54 2015 -0200 [media] v4l: vsp1: Fix VI6_DPR_ROUTE_FP_MASK macro [ Upstream commit 1aa7890324b497f96f07c20673fae58f26fabfe7 ] FP bit of VI6_DPR_mod_ROUTE register is 6bit. But VI6_DPR_ROUTE_FP_MASK is set to 0xFF, this will mask until the reserve bit. This fixes size for VI6_DPR_ROUTE_FP_MASK. Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6a661943b206ccd77e764b73d85dd67630276dad Author: Nobuhiro Iwamatsu Date: Wed Jan 28 22:53:55 2015 -0200 [media] v4l: vsp1: Fix VI6_DPR_ROUTE_FXA_MASK macro [ Upstream commit 45008ee9295b3ae96d7413ab91871907a671ca82 ] FXA bit of VI6_DPR_mod_ROUTE register starts from 16bit. But VI6_DPR_ROUTE_FXA_MASK is set to become start from 8bit. This fixes shift size for VI6_DPR_ROUTE_FXA_MASK. Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 925f239252af5aed32d174c0b6658a7bef854845 Author: Hans Verkuil Date: Mon Jul 20 09:59:35 2015 -0300 [media] usbvision: fix locking error [ Upstream commit e2c84ccb0fbe5e524d15bb09c042a6ca634adaed ] If remove_pending is non-zero, then the v4l2_lock is never unlocked. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ee289602d8ac1050e725d6899a73f7592c5668ad Author: Andrew Morton Date: Mon Sep 28 16:38:07 2015 -0700 Input: zhenhua - ensure we have BITREVERSE [ Upstream commit d3b367bc26ea2e07a83fe73f0ccbddd729cb1f9a ] It uses bitrev8(), so it must ensure that lib/bitrev.o gets included in vmlinux. Signed-off-by: Andrew Morton Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e871155e221dbb3397ab7e6ed5267c0958094636 Author: Sudip Mukherjee Date: Mon Sep 28 15:59:22 2015 -0700 Input: omap4-keypad - fix memory leak [ Upstream commit d79bdc7f004404204a6ac07785f8d6717070ecdb ] If omap4_keypad_parse_dt() fails we returned the error code but we missed releasing keypad_data. Signed-off-by: Sudip Mukherjee Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit bbdc0806b4a91db4bbb55c10be4889d7aa61e92b Author: Sudip Mukherjee Date: Sun Sep 27 17:13:55 2015 -0700 Input: serio - fix blocking of parport [ Upstream commit 1a5e251996e1b602f2ddc9261ee9de0ca1875bfa ] If parkbd_allocate_serio() fails to allocate memory we are releasing the parport but we missed unregistering the device. As a result this device with exclusive access to that parport remains registered. And no other device will be able to use that parport even though this driver has failed to load. Signed-off-by: Sudip Mukherjee Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit da498f694c231f6560dc84fd5b8cb5169b7607aa Author: Stefan Assmann Date: Wed Aug 26 13:11:49 2015 -0700 Input: psmouse - add small delay for IBM trackpoint pass-through mode [ Upstream commit 66bc2f51ef7deabc8b8f3baa98ae64b65e5e973a ] There are trackpoint devices that fail to respond to the PS2 command PSMOUSE_CMD_GETID if immediately queried after the parent device is deactivated. Add a small delay for the hardware to get in a sane state before sending any PS2 commands. One example of such a system is: Lenovo ThinkPad X120e, model 30515QG synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x121c00, board id: 1811, fw id: 797391 Signed-off-by: Stefan Assmann Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 67d9383a959c8979daec4f8d782550f4c9baac14 Author: Benjamin Tissoires Date: Fri Aug 21 10:18:08 2015 -0400 HID: quirks: add QUIRK_NOGET for an other TPV touchscreen [ Upstream commit c9b57724b38d4c1555ee49418be3d76801e3327c ] Looks like 0x8882 needs the same quirk than 0x8883. Given that both devices claim they are "TPV OpticalTouchScreen" rename the 0x8883 to add its PID in the #define. Reported-by: Blaine Lee Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 572a085cea021117ffc954a75192271561fd9e2e Author: Henrik Rydberg Date: Fri Jul 24 14:45:05 2015 -0700 HID: apple: Add support for the 2015 Macbook Pro [ Upstream commit a4a2c54560f2c57b88ba0283f141b44f594c2337 ] This patch adds keyboard support for MacbookPro12,1 as WELLSPRING9 (0x0272, 0x0273, 0x0274). The touchpad is handled in a separate bcm5974 patch, as usual. Tested-by: John Horan Tested-by: Jochen Radmacher Tested-by: Yang Hongyang Tested-by: Yen-Chin, Lee Tested-by: George Hilios Tested-by: Janez Urevc Signed-off-by: Henrik Rydberg Acked-by: Jiri Kosina Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 111bbf69b6dde18e07c82803012bcd798f21de06 Author: Bin Liu Date: Mon Aug 24 15:28:37 2015 -0500 usb: musb: fix cppi channel teardown for isoch transfer [ Upstream commit b431ba8803666e56c1d178a421b3cbc36e8d3d33 ] After a few iterations of start/stop UVC camera streaming, the streaming stops. This patch adds 250us delay in the cppi channel abort path to let cppi drain properly. Using 50us delay seems to be too aggressive, some webcams are still broken. 250us is the original value used in TI 3.2 kernel. Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 7059616548ef5443e3cf70fa3befdc3d4f9c2da1 Author: Bin Liu Date: Mon Jan 26 16:22:07 2015 -0600 usb: musb: cppi41: improve rx channel abort routine [ Upstream commit cb83df77f3ec151d68a1b6be957207e6fc7b7f50 ] 1. set AUTOREQ to NONE at the beginning of teardown; 2. add delay for dma pipeline to drain; 3. Do not set USB_TDOWN bit for RX teardown. The CPPI hw has an issue that when tearing down a RX channel, if another RX channel is receiving data, the CPPI will lockup. To workaround the issue, do not set the CPPI TD bit. The steps before this point ensures the CPPI channel will be torn down properly. Signed-off-by: Bin Liu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 44b87b60a34fbb3eb6a9da60fcc16547d2e05522 Author: Philipp Hachtmann Date: Mon Aug 17 17:31:47 2015 +0200 USB: symbolserial: Correct transferred data size [ Upstream commit 8ae25a355b5969e12f3185e8cb8eb08b871c9084 ] The scanner (here DS3508) always returns 64 bytes per urb buffer. The first byte indicates the data length used in the current buffer. There even was a comment describing this. But the comment also said that we'll send everything in the buffer to the tty layer. That means sending the actual barcode data and lots of trailing zeroes. This patch lets the driver only send the real data. Signed-off-by: Philipp Hachtmann Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0fa94e01118f0a7e82dbdf6f648c689231650560 Author: Li Jun Date: Wed Jul 29 13:11:11 2015 +0800 usb: chipidea: debug: add runtime pm for register access [ Upstream commit bc24937943d9f71a1e32b5dc4e2f0ef8fcc07b64 ] Add runtime pm operations for registers access to avoid system hang. Signed-off-by: Li Jun Signed-off-by: Sasha Levin commit 39a86be1c6616d5a273ca08c99c8cb885865df07 Author: Martin Schwidefsky Date: Wed Aug 19 16:50:10 2015 +0200 s390/3270: redraw screen on unsolicited device end [ Upstream commit 05bfd70bcdd3cd12c061cb77b73a11ba6f87379d ] If a 3270 terminal is disconnected and later reconnected again, it gets an unsolicited device end. This is currently ignored and you have to hit the clear key to get the screen redrawn. Add an automatic full redraw of the screen for this case. Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 465760c5415994f582b155059a1450f9e059cffd Author: Joerg Roedel Date: Wed May 27 09:26:09 2015 +0200 iommu/amd: Handle integer overflow in dma_ops_area_alloc [ Upstream commit e6aabee05f41c9d18e0b92194819edd84f352ac9 ] Handle this case to make sure boundary_size does not become 0 and trigger a BUG_ON later. Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e52b6c7f92fa5b46a0347efac1b8ecef19447633 Author: Noel Power Date: Wed May 27 09:22:10 2015 +0100 client MUST ignore EncryptionKeyLength if CAP_EXTENDED_SECURITY is set [ Upstream commit f291095f340db986271e951e3891bb95624a93ea ] [MS-SMB] 2.2.4.5.2.1 states: "ChallengeLength (1 byte): When the CAP_EXTENDED_SECURITY bit is set, the server MUST set this value to zero and clients MUST ignore this value." Signed-off-by: Noel Power Signed-off-by: Steve French Signed-off-by: Sasha Levin commit bb840a1d74f58487ffaeec6cf46cf40c702d0f40 Author: Teunis van Beelen Date: Sun May 31 09:36:22 2015 +0200 USB: usbtmc: add device quirk for Rigol DS6104 [ Upstream commit f50420223071b6ff4b586308f5c27eec54694a81 ] Recently we purchased the Rigol DS6104 and when I try to operate it from my Linux pc, everything works well with the default usbtmc driver, except when I want to download a big datachunk like a screenshot. This bitmapfile has a size of 1152054 bytes but I receive a smaller file and no new packets can be read. When I took a look at the driver source, I found this "Rigol quirk" and I added the id of the new DS series oscilloscopes to this list. I compiled it and loaded the new driver and now everything seems to work fine. Signed-off-by: Teunis van Beelen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 71dc6a353848a515e48ebe47a92e80a0be3411e5 Author: Jan H. Schönherr Date: Wed Aug 12 21:35:56 2015 +0200 sched: Fix cpu_active_mask/cpu_online_mask race [ Upstream commit dd9d3843755da95f63dd3a376f62b3e45c011210 ] There is a race condition in SMP bootup code, which may result in WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418 workqueue_cpu_up_callback() or kernel BUG at kernel/smpboot.c:135! It can be triggered with a bit of luck in Linux guests running on busy hosts. CPU0 CPUn ==== ==== _cpu_up() __cpu_up() start_secondary() set_cpu_online() cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits)); cpu_notify(CPU_ONLINE) cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits)); During the various CPU_ONLINE callbacks CPUn is online but not active. Several things can go wrong at that point, depending on the scheduling of tasks on CPU0. Variant 1: cpu_notify(CPU_ONLINE) workqueue_cpu_up_callback() rebind_workers() set_cpus_allowed_ptr() This call fails because it requires an active CPU; rebind_workers() ends with a warning: WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418 workqueue_cpu_up_callback() Variant 2: cpu_notify(CPU_ONLINE) smpboot_thread_call() smpboot_unpark_threads() .. __kthread_unpark() __kthread_bind() wake_up_state() .. select_task_rq() select_fallback_rq() The ->wake_cpu of the unparked thread is not allowed, making a call to select_fallback_rq() necessary. Then, select_fallback_rq() cannot find an allowed, active CPU and promptly resets the allowed CPUs, so that the task in question ends up on CPU0. When those unparked tasks are eventually executed, they run immediately into a BUG: kernel BUG at kernel/smpboot.c:135! Just changing the order in which the online/active bits are set (and adding some memory barriers), would solve the two issues above. However, it would change the order of operations back to the one before commit 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()"), thus, reintroducing that particular problem. Going further back into history, we have at least the following commits touching this topic: - commit 2baab4e90495 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online") - commit 5fbd036b552f ("sched: Cleanup cpu_active madness") Together, these give us the following non-working solutions: - secondary CPU sets active before online, because active is assumed to be a subset of online; - secondary CPU sets online before active, because the primary CPU assumes that an online CPU is also active; - secondary CPU sets online and waits for primary CPU to set active, because it might deadlock. Commit 875ebe940d77 ("powerpc/smp: Wait until secondaries are active & online") introduces an arch-specific solution to this arch-independent problem. Now, go for a more general solution without explicit waiting and simply set active twice: once on the secondary CPU after online was set and once on the primary CPU after online was seen. set_cpus_allowed_ptr()") Signed-off-by: Jan H. Schönherr Acked-by: Peter Zijlstra Cc: Cc: Anton Blanchard Cc: Borislav Petkov Cc: Joerg Roedel Cc: Linus Torvalds Cc: Matt Wilson Cc: Michael Ellerman Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()") Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit c17d13bdf627b629fc77f6efa680584f29715ee8 Author: Mark Rustad Date: Mon Jul 13 11:40:07 2015 -0700 PCI: Add VPD function 0 quirk for Intel Ethernet devices [ Upstream commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 ] Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device functions other than function 0, so that on multi-function devices, we will always read VPD from function 0 instead of from the other functions. [bhelgaas: changelog] Signed-off-by: Mark Rustad Signed-off-by: Bjorn Helgaas Acked-by: Alexander Duyck CC: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 619d6ccdd9467223f3a9d747168b4a543969fd77 Author: Mark Rustad Date: Mon Jul 13 11:40:02 2015 -0700 PCI: Add dev_flags bit to access VPD through function 0 [ Upstream commit 91a37c794cf2cf7ec1f9afc4cbf4a118df7e085e ] commit 932c435caba8a2ce473a91753bad0173269ef334 upstream. Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through function 0 to provide VPD access on other functions. This is for hardware devices that provide copies of the same VPD capability registers in multiple functions. Because the kernel expects that each function has its own registers, both the locking and the state tracking are affected by VPD accesses to different functions. On such devices for example, if a VPD write is performed on function 0, *any* later attempt to read VPD from any other function of that device will hang. This has to do with how the kernel tracks the expected value of the F bit per function. Concurrent accesses to different functions of the same device can not only hang but also corrupt both read and write VPD data. When hangs occur, typically the error message: vpd r/w failed. This is likely a firmware bug on this device. will be seen. Never set this bit on function 0 or there will be an infinite recursion. Signed-off-by: Mark Rustad Signed-off-by: Bjorn Helgaas Acked-by: Alexander Duyck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d51125d02727c945a25671960c8a9c0dcb7def2 Author: Alex Williamson Date: Fri Nov 21 11:24:08 2014 -0700 PCI: Add flag for devices that don't reset on D3hot->D0 transition [ Upstream commit 51e537387990dc1f00752103f314fd135cb94bc6 ] Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-") should perform an internal reset when transitioning from D3hot to D0 via software control. Configuration context is lost and the device requires a full reinitialization sequence. Unfortunately the definition of "internal reset", beyond the application of the configuration context, is largely left to the interpretation of the specific device. Some devices don't seem to perform an "internal reset" even if they report No_Soft_Reset == 0. We still need to honor the PCI specification and restore PCI config context in the event that we do a PM reset, so we don't cache and modify the PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the intention is to reset the device, like pci_reset_function(), we need a mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform any significant "internal reset" of the device. Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 16d8da6c17a7024180e3b9865eb9fad605a9b382 Author: David Howells Date: Thu Oct 15 17:21:37 2015 +0100 KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring [ Upstream commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 ] The following sequence of commands: i=`keyctl add user a a @s` keyctl request2 keyring foo bar @t keyctl unlink $i @s tries to invoke an upcall to instantiate a keyring if one doesn't already exist by that name within the user's keyring set. However, if the upcall fails, the code sets keyring->type_data.reject_error to -ENOKEY or some other error code. When the key is garbage collected, the key destroy function is called unconditionally and keyring_destroy() uses list_empty() on keyring->type_data.link - which is in a union with reject_error. Subsequently, the kernel tries to unlink the keyring from the keyring names list - which oopses like this: BUG: unable to handle kernel paging request at 00000000ffffff8a IP: [] keyring_destroy+0x3d/0x88 ... Workqueue: events key_garbage_collector ... RIP: 0010:[] keyring_destroy+0x3d/0x88 RSP: 0018:ffff88003e2f3d30 EFLAGS: 00010203 RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40 RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000 R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900 R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000 ... CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0 ... Call Trace: [] key_gc_unused_keys.constprop.1+0x5d/0x10f [] key_garbage_collector+0x1fa/0x351 [] process_one_work+0x28e/0x547 [] worker_thread+0x26e/0x361 [] ? rescuer_thread+0x2a8/0x2a8 [] kthread+0xf3/0xfb [] ? kthread_create_on_node+0x1c2/0x1c2 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x1c2/0x1c2 Note the value in RAX. This is a 32-bit representation of -ENOKEY. The solution is to only call ->destroy() if the key was successfully instantiated. Reported-by: Dmitry Vyukov Signed-off-by: David Howells Tested-by: Dmitry Vyukov Signed-off-by: Sasha Levin commit 1ee2c9bdaca944bf6796d8363224d386daec743f Author: David Howells Date: Fri Sep 25 16:30:08 2015 +0100 KEYS: Fix race between key destruction and finding a keyring by name [ Upstream commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 ] There appears to be a race between: (1) key_gc_unused_keys() which frees key->security and then calls keyring_destroy() to unlink the name from the name list (2) find_keyring_by_name() which calls key_permission(), thus accessing key->security, on a key before checking to see whether the key usage is 0 (ie. the key is dead and might be cleaned up). Fix this by calling ->destroy() before cleaning up the core key data - including key->security. Reported-by: Petr Matousek Signed-off-by: David Howells Signed-off-by: Sasha Levin commit b1e06008b17ecd099ab14e005a2909b40c8b6faa Author: Eric Whitney Date: Fri Apr 3 00:13:42 2015 -0400 ext4: fix loss of delalloc extent info in ext4_zero_range() [ Upstream commit 94426f4b9648154dc5a6760b59e6953e640ab3b1 ] In ext4_zero_range(), removing a file's entire block range from the extent status tree removes all records of that file's delalloc extents. The delalloc accounting code uses this information, and its loss can then lead to accounting errors and kernel warnings at writeback time and subsequent file system damage. This is most noticeable on bigalloc file systems where code in ext4_ext_map_blocks() handles cases where delalloc extents share clusters with a newly allocated extent. Because we're not deleting a block range and are correctly updating the status of its associated extent, there is no need to remove anything from the extent status tree. When this patch is combined with an unrelated bug fix for ext4_zero_range(), kernel warnings and e2fsck errors reported during xfstests runs on bigalloc filesystems are greatly reduced without introducing regressions on other xfstests-bld test scenarios. Signed-off-by: Eric Whitney Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b9fca5cb9ab94112bebd1e5db862962df9dfcec2 Author: Lukas Czerner Date: Fri Apr 3 00:09:13 2015 -0400 ext4: allocate entire range in zero range [ Upstream commit 0f2af21aae11972fa924374ddcf52e88347cf5a8 ] Currently there is a bug in zero range code which causes zero range calls to only allocate block aligned portion of the range, while ignoring the rest in some cases. In some cases, namely if the end of the range is past i_size, we do attempt to preallocate the last nonaligned block. However this might cause kernel to BUG() in some carefully designed zero range requests on setups where page size > block size. Fix this problem by first preallocating the entire range, including the nonaligned edges and converting the written extents to unwritten in the next step. This approach will also give us the advantage of having the range to be as linearly contiguous as possible. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0812542d8e5337822045c81695caff87ea4f5105 Author: Dan Carpenter Date: Thu Feb 5 10:37:33 2015 +0300 vhost/scsi: potential memory corruption [ Upstream commit 59c816c1f24df0204e01851431d3bab3eb76719c ] This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt" to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16. I looked at the context and it turns out that in vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into the vs_tpg[] array which has VHOST_SCSI_MAX_TARGET (256) elements so anything higher than 255 then it is invalid. I have made that the limit now. In vhost_scsi_send_evt() we mask away values higher than 255, but now that the limit has changed, we don't need the mask. Signed-off-by: Dan Carpenter Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 52e980501b7245b1e051a77342c1d5e14204b90d Author: Soeren Grunewald Date: Thu Jun 11 09:25:04 2015 +0200 serial: 8250_pci: Add support for 12 port Exar boards [ Upstream commit be32c0cf0462c36f482b5ddcff1d8371be1e183c ] The Exar XR17V358 can also be combined with a XR17V354 chip to act as a single 12 port chip. This works the same way as the combining two XR17V358 chips. But the reported device id then is 0x4358. Signed-off-by: Soeren Grunewald Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f1963e21768bf83aec1739f3e12d345a8452a0f1 Author: Soeren Grunewald Date: Tue Apr 28 16:29:49 2015 +0200 serial: 8250_pci: Add support for 16 port Exar boards [ Upstream commit 96a5d18bc1338786fecac73599f1681f59a59a8e ] The Exar XR17V358 chip usually provides only 8 ports. But two chips can be combined to act as a single 16 port chip. Therefor one chip is configured as master the second as slave by connecting the mode pin to VCC (master) or GND (slave). Then the master chip is reporting a different device-id depending on whether a slave is detected or not. The UARTs 8-15 are addressed from 0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to address all 16 ports as before. See: https://www.exar.com/common/content/document.ashx?id=1587 page 11 Signed-off-by: Soeren Grunewald Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ac9586cd0477c6ed1e4bb6c9b0b18503e25f6f5 Author: Roman Gushchin Date: Sat Oct 31 10:53:50 2015 +1100 md/raid5: fix locking in handle_stripe_clean_event() [ Upstream commit b8a9d66d043ffac116100775a469f05f5158c16f ] After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") __find_stripe() is called under conf->hash_locks + hash. But handle_stripe_clean_event() calls remove_hash() under conf->device_lock. Under some cirscumstances the hash chain can be circuited, and we get an infinite loop with disabled interrupts and locked hash lock in __find_stripe(). This leads to hard lockup on multiple CPUs and following system crash. I was able to reproduce this behavior on raid6 over 6 ssd disks. The devices_handle_discard_safely option should be set to enable trim support. The following script was used: for i in `seq 1 32`; do dd if=/dev/zero of=large$i bs=10M count=100 & done neilb: original was against a 3.x kernel. I forward-ported to 4.3-rc. This verison is suitable for any kernel since Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write") (v4.1+). I'll post a version for earlier kernels to stable. Signed-off-by: Roman Gushchin Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") Signed-off-by: NeilBrown Cc: Shaohua Li Cc: # 3.13 - 4.2 Signed-off-by: Sasha Levin commit 69a7ca06041ad6f3a7672db472ac26cdd2a3df83 Author: Doron Tsur Date: Sun Oct 11 15:58:17 2015 +0300 IB/cm: Fix rb-tree duplicate free and use-after-free [ Upstream commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 ] ib_send_cm_sidr_rep could sometimes erase the node from the sidr (depending on errors in the process). Since ib_send_cm_sidr_rep is called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv could be either erased from the rb_tree twice or not erased at all. Fixing that by making sure it's erased only once before freeing cm_id_priv. Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation') Signed-off-by: Doron Tsur Signed-off-by: Matan Barak Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit bcb7da0b05d0a255ffad962231e0b5a925d733ae Author: Dāvis Mosāns Date: Fri Aug 21 07:29:22 2015 +0300 mvsas: Fix NULL pointer dereference in mvs_slot_task_free [ Upstream commit 2280521719e81919283b82902ac24058f87dfc1b ] When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays NULL but it's later used in mvs_abort_task as slot which is passed to mvs_slot_task_free causing NULL pointer dereference. Just return from mvs_slot_task_free when passed with NULL slot. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891 Signed-off-by: Dāvis Mosāns Reviewed-by: Tomas Henzl Reviewed-by: Johannes Thumshirn Cc: stable@vger.kernel.org Signed-off-by: James Bottomley Signed-off-by: Sasha Levin commit f5fda0993ccdfd54e5f696f9e09e068baafe1ff8 Author: NeilBrown Date: Sat Oct 31 11:00:56 2015 +1100 Revert "md: allow a partially recovered device to be hot-added to an array." [ Upstream commit d01552a76d71f9879af448e9142389ee9be6e95b ] This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57. This commit is poorly justified, I can find not discusison in email, and it clearly causes a problem. If a device which is being recovered fails and is subsequently re-added to an array, there could easily have been changes to the array *before* the point where the recovery was up to. So the recovery must start again from the beginning. If a spare is being recovered and fails, then when it is re-added we really should do a bitmap-based recovery up to the recovery-offset, and then a full recovery from there. Before this reversion, we only did the "full recovery from there" which is not corect. After this reversion with will do a full recovery from the start, which is safer but not ideal. It will be left to a future patch to arrange the two different styles of recovery. Reported-and-tested-by: Nate Dailey Signed-off-by: NeilBrown Cc: stable@vger.kernel.org (3.14+) Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.") Signed-off-by: Sasha Levin commit e159f9c60a3feaec46dc5d3a83972e5cf2bde763 Author: Jes Sorensen Date: Tue Oct 20 12:09:13 2015 -0400 md/raid10: submit_bio_wait() returns 0 on success [ Upstream commit 681ab4696062f5aa939c9e04d058732306a97176 ] This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Cc: stable@vger.kernel.org (v3.10) Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Sasha Levin commit e9206476ace2064ae76e4d3c5d5b7cb9d81be007 Author: Jes Sorensen Date: Tue Oct 20 12:09:12 2015 -0400 md/raid1: submit_bio_wait() returns 0 on success [ Upstream commit 203d27b0226a05202438ddb39ef0ef1acb14a759 ] This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b which changed the return value of submit_bio_wait() to return != 0 on error, but didn't update the caller accordingly. Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md") Cc: stable@vger.kernel.org (v3.10) Reported-by: Bill Kuzeja Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Sasha Levin commit 90a7b3b32dcbe54a40eea29a8c1308475ac9d7ab Author: Herbert Xu Date: Mon Oct 19 18:23:57 2015 +0800 crypto: api - Only abort operations on fatal signal [ Upstream commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 ] Currently a number of Crypto API operations may fail when a signal occurs. This causes nasty problems as the caller of those operations are often not in a good position to restart the operation. In fact there is currently no need for those operations to be interrupted by user signals at all. All we need is for them to be killable. This patch replaces the relevant calls of signal_pending with fatal_signal_pending, and wait_for_completion_interruptible with wait_for_completion_killable, respectively. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c07366111728efd1260452ef094c0a64d9c40f93 Author: Peter Zijlstra Date: Thu Aug 20 10:34:59 2015 +0930 module: Fix locking in symbol_put_addr() [ Upstream commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 ] Poma (on the way to another bug) reported an assertion triggering: [] module_assert_mutex_or_preempt+0x49/0x90 [] __module_address+0x32/0x150 [] __module_text_address+0x16/0x70 [] symbol_put_addr+0x29/0x40 [] dvb_frontend_detach+0x7d/0x90 [dvb_core] Laura Abbott produced a patch which lead us to inspect symbol_put_addr(). This function has a comment claiming it doesn't need to disable preemption around the module lookup because it holds a reference to the module it wants to find, which therefore cannot go away. This is wrong (and a false optimization too, preempt_disable() is really rather cheap, and I doubt any of this is on uber critical paths, otherwise it would've retained a pointer to the actual module anyway and avoided the second lookup). While its true that the module cannot go away while we hold a reference on it, the data structure we do the lookup in very much _CAN_ change while we do the lookup. Therefore fix the comment and add the required preempt_disable(). Reported-by: poma Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Rusty Russell Fixes: a6e6abd575fc ("module: remove module_text_address()") Cc: stable@kernel.org Signed-off-by: Sasha Levin commit ff6f66f679e83d69c869de459dad3bc0f4783c63 Author: Cathy Avery Date: Fri Oct 2 09:35:01 2015 -0400 xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing) [ Upstream commit a54c8f0f2d7df525ff997e2afe71866a1a013064 ] xen-blkfront will crash if the check to talk_to_blkback() in blkback_changed()(XenbusStateInitWait) returns an error. The driver data is freed and info is set to NULL. Later during the close process via talk_to_blkback's call to xenbus_dev_fatal() the null pointer is passed to and dereference in blkfront_closing. CC: stable@vger.kernel.org Signed-off-by: Cathy Avery Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Sasha Levin commit 0b3fefd2408019fc37c9e9125fdea8d1220b7e7b Author: Laura Abbott Date: Mon Oct 12 11:30:13 2015 +0300 xhci: Add spurious wakeup quirk for LynxPoint-LP controllers [ Upstream commit fd7cd061adcf5f7503515ba52b6a724642a839c8 ] We received several reports of systems rebooting and powering on after an attempted shutdown. Testing showed that setting XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT quirk allowed the system to shutdown as expected for LynxPoint-LP xHCI controllers. Set the quirk back. Note that the quirk was originally introduced for LynxPoint and LynxPoint-LP just for this same reason. See: commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell") It was later limited to only concern HP machines as it caused regression on some machines, see both bug and commit: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines") Later it was discovered that the powering on after shutdown was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP machine suffered from spontaneous resume from S3 (which should not be related to the SPURIOUS_WAKEUP quirk at all). An attempt to fix this then removed the SPURIOUS_WAKEUP flag usage completely. commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell") Current understanding is that LynxPoint-LP (Haswell ULT) machines need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and plain Lynxpoint (Haswell) machines may _not_ have the quirk set otherwise they again will restart. Signed-off-by: Laura Abbott Cc: Takashi Iwai Cc: Oliver Neukum [Added more history to commit message -Mathias] Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c5c9eb0fbed3ce6f65aa0623ea7509dd7e83b50c Author: Mathias Nyman Date: Mon Oct 12 11:30:12 2015 +0300 xhci: handle no ping response error properly [ Upstream commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 ] If a host fails to wake up a isochronous SuperSpeed device from U1/U2 in time for a isoch transfer it will generate a "No ping response error" Host will then move to the next transfer descriptor. Handle this case in the same way as missed service errors, tag the current TD as skipped and handle it on the next transfer event. Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5b37f0716cdf2d63b6915331e3d3e4c87adb727c Author: Mike Snitzer Date: Thu Oct 22 10:56:40 2015 -0400 dm btree: fix leak of bufio-backed block in btree_split_beneath error path [ Upstream commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be ] btree_split_beneath()'s error path had an outstanding FIXME that speaks directly to the potential for _not_ cleaning up a previously allocated bufio-backed block. Fix this by releasing the previously allocated bufio block using unlock_block(). Reported-by: Mikulas Patocka Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 60be756487567007d78ec5b5f9c1e0af97f6c8bf Author: Joe Thornber Date: Wed Oct 21 18:36:49 2015 +0100 dm btree remove: fix a bug when rebalancing nodes after removal [ Upstream commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b ] Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't a complete fix for redistribute3(). The redistribute3 function takes 3 btree nodes and shares out the entries evenly between them. If the three nodes in total contained (MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in the center. Fix this issue by being more careful about calculating the target number of entries for the left and right nodes. Unit tested in userspace using this program: https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 5379564bbf799193bd1e1633d639e56e12c05417 Author: Will Deacon Date: Wed Oct 28 16:56:13 2015 +0000 Revert "ARM64: unwind: Fix PC calculation" [ Upstream commit 9702970c7bd3e2d6fecb642a190269131d4ac16c ] This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63. With this patch applied, we were the only architecture making this sort of adjustment to the PC calculation in the unwinder. This causes problems for ftrace, where the PC values are matched against the contents of the stack frames in the callchain and fail to match any records after the address adjustment. Whilst there has been some effort to change ftrace to workaround this, those patches are not yet ready for mainline and, since we're the odd architecture in this regard, let's just step in line with other architectures (like arch/arm/) for now. Cc: Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7b21a4743f2fd02d2bdccb614519375abe4fa267 Author: Ronny Hegewald Date: Thu Oct 15 18:50:46 2015 +0000 rbd: require stable pages if message data CRCs are enabled [ Upstream commit bae818ee1577c27356093901a0ea48f672eda514 ] rbd requires stable pages, as it performs a crc of the page data before they are send to the OSDs. But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0 "mm: only enforce stable page writes if the backing device requires it") it is not assumed anymore that block devices require stable pages. This patch sets the necessary flag to get stable pages back for rbd. In a ceph installation that provides multiple ext4 formatted rbd devices "bad crc" messages appeared regularly (ca 1 message every 1-2 minutes on every OSD that provided the data for the rbd) in the OSD-logs before this patch. After this patch this messages are pretty much gone (only ca 1-2 / month / OSD). Cc: stable@vger.kernel.org # 3.9+, needs backporting Signed-off-by: Ronny Hegewald [idryomov@gmail.com: require stable pages only in crc case, changelog] Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 5b5ca1505596fe6906587ba22d85881cd7c57725 Author: Alexandre Belloni Date: Wed Oct 7 13:10:54 2015 +0200 iio: mxs-lradc: Fix temperature offset [ Upstream commit b94e22805a2224061bb263a82b72e09544a5fbb3 ] 0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset. Also improve the comment explaining the calculation. Reported-by: Janusz Użycki Signed-off-by: Alexandre Belloni Acked-by: Stefan Wahren Acked-by: Marek Vasut Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0a1bf5fd80e14a2396c6991d78b544ece3edf488 Author: Alex Deucher Date: Fri Oct 23 10:38:52 2015 -0400 drm/radeon: don't try to recreate sysfs entries on resume [ Upstream commit 49abb26651167c892393cd9f2ad23df429645ed9 ] Fixes a harmless error message caused by: 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 84d503cd91797a48e0ccda9dc3cc3c378184149d Author: Ville Syrjälä Date: Wed Oct 7 22:08:24 2015 +0300 drm/i915: Restore lost DPLL register write on gen2-4 [ Upstream commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 ] We accidentally lost the initial DPLL register write in 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M The "three times for luck" hack probably saved us from a total disaster. But anyway, bring the initial write back so that the code actually makes some sense. Reported-and-tested-by: Nick Bowler References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com Cc: stable@vger.kernel.org Cc: Nick Bowler Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit ec99271dde0264d88c5b196782e35beaedff412a Author: Ilia Mirkin Date: Tue Oct 20 01:15:39 2015 -0400 drm/nouveau/gem: return only valid domain when there's only one [ Upstream commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 ] On nv50+, we restrict the valid domains to just the one where the buffer was originally created. However after the buffer is evicted to system memory, we might move it back to a different domain that was not originally valid. When sharing the buffer and retrieving its GEM_INFO data, we still want the domain that will be valid for this buffer in a pushbuf, not the one where it currently happens to be. This resolves fdo#92504 and several others. These are due to suspend evicting all buffers, making it more likely that they temporarily end up in the wrong place. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 88f95b28f97a31aa0350a28d1196d4f33fd58ca9 Author: Lad, Prabhakar Date: Thu Dec 4 14:56:04 2014 +0000 power: bq24190_charger: suppress build warning [ Upstream commit 31f50e48e3e4ea9d503285a389d6a1b5349d66c0 ] This patch fixes following build warning: In file included from include/linux/printk.h:261:0, from include/linux/kernel.h:13, from include/linux/list.h:8, from include/linux/module.h:9, from drivers/power/bq24190_charger.c:11: drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’: include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^ drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here u8 ss_reg, f_reg; ^ In file included from include/linux/printk.h:261:0, from include/linux/kernel.h:13, from include/linux/list.h:8, from include/linux/module.h:9, from drivers/power/bq24190_charger.c:11: include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^ drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here u8 ss_reg, f_reg; Signed-off-by: Lad, Prabhakar Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit cc61a4541cb99ae459b4e05f978643f17bb036be Author: David S. Miller Date: Fri Apr 17 15:15:40 2015 -0400 sfc: Fix memcpy() with const destination compiler warning. [ Upstream commit 1d20a16062e771b6e26b843c0cde3b17c1146e00 ] drivers/net/ethernet/sfc/selftest.c: In function ‘efx_iterate_state’: drivers/net/ethernet/sfc/selftest.c:388:9: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers] This is because the msg[] member of struct efx_loopback_payload is marked as 'const'. Remove that. Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f95cfc6a159ca8db816ac4cdb2ad52a0418a1db6 Author: Jan Kara Date: Thu Oct 22 13:32:21 2015 -0700 mm: make sendfile(2) killable [ Upstream commit 296291cdd1629c308114504b850dc343eabc2782 ] Currently a simple program below issues a sendfile(2) system call which takes about 62 days to complete in my test KVM instance. int fd; off_t off = 0; fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644); ftruncate(fd, 2); lseek(fd, 0, SEEK_END); sendfile(fd, fd, &off, 0xfffffff); Now you should not ask kernel to do a stupid stuff like copying 256MB in 2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin should have a way to stop you. We actually do have a check for fatal_signal_pending() in generic_perform_write() which triggers in this path however because we always succeed in writing something before the check is done, we return value > 0 from generic_perform_write() and thus the information about signal gets lost. Fix the problem by doing the signal check before writing anything. That way generic_perform_write() returns -EINTR, the error gets propagated up and the sendfile loop terminates early. Signed-off-by: Jan Kara Reported-by: Dmitry Vyukov Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a8b451d26cabcfac073b014feb89dfa23992295c Author: Charles Keepax Date: Tue Oct 20 10:25:58 2015 +0100 ASoC: wm8904: Correct number of EQ registers [ Upstream commit 97aff2c03a1e4d343266adadb52313613efb027f ] There are 24 EQ registers not 25, I suspect this bug came about because the registers start at EQ1 not zero. The bug is relatively harmless as the extra register written is an unused one. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit a17d7e441e6dae28978690aaca6b630e1f661e2e Author: Vasant Hegde Date: Fri Oct 16 15:53:29 2015 +0530 powerpc/rtas: Validate rtas.entry before calling enter_rtas() [ Upstream commit 8832317f662c06f5c06e638f57bfe89a71c9b266 ] Currently we do not validate rtas.entry before calling enter_rtas(). This leads to a kernel oops when user space calls rtas system call on a powernv platform (see below). This patch adds code to validate rtas.entry before making enter_rtas() call. Oops: Exception in kernel mode, sig: 4 [#1] SMP NR_CPUS=1024 NUMA PowerNV task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000 NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140 REGS: c0000007e1a7b920 TRAP: 0e40 Not tainted (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le) MSR: 1000000000081000 CR: 00000000 XER: 00000000 CFAR: c000000000009c0c SOFTE: 0 NIP [0000000000000000] (null) LR [0000000000009c14] 0x9c14 Call Trace: [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable) [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0 [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98 Cc: stable@vger.kernel.org # v3.2+ Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform") Reported-by: NAGESWARA R. SASTRY Signed-off-by: Vasant Hegde [mpe: Reword change log, trim oops, and add stable + fixes] Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b2a57546416ff2c312a9903ba4d9c200699d0c33 Author: Joerg Roedel Date: Tue Oct 20 14:59:36 2015 +0200 iommu/amd: Don't clear DTE flags when modifying it [ Upstream commit cbf3ccd09d683abf1cacd36e3640872ee912d99b ] During device assignment/deassignment the flags in the DTE get lost, which might cause spurious faults, for example when the device tries to access the system management range. Fix this by not clearing the flags with the rest of the DTE. Reported-by: G. Richard Bellamy Tested-by: G. Richard Bellamy Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3f17b603ca74c0580e897810d15c33a7e5314603 Author: Luca Coelho Date: Tue Sep 22 09:44:39 2015 +0300 iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series [ Upstream commit f08f625876476b6c4a87834dc86e3b927f4697d2 ] Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B device ID. Cc: [3.13+] Reported-by: Jeremy Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit d9a5f2f9c40247522c204aa142696694948cf0ce Author: Johannes Berg Date: Tue Sep 15 14:36:09 2015 +0200 iwlwifi: mvm: fix D3 firmware PN programming [ Upstream commit 2cf5eb3ab7bb7f2e3a70edcef236cd62c87db030 ] The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Cc: [3.1+] Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 8babe12bfba735a55fd42e3ba3d0178eb3383c37 Author: Johannes Berg Date: Tue Nov 18 15:39:51 2014 +0100 iwlwifi: pcie: support 7265-D devices [ Upstream commit 3fd0d3c170ad6ba8b64e16938f699d0b43cc782e ] Identify 7265-D devices using the hardware revision (they have the same PCI IDs as 7265) and change the configuration for them taking the differences (currently only the firmware image) into account. Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Sasha Levin commit f96fe7e5d9a8ccb376d706c35e405c78c268f83a Author: Johannes Berg Date: Tue Sep 22 10:47:27 2015 +0200 iwlwifi: fix firmware filename for 3160 [ Upstream commit b5a48134f8af08f5243328f8a0b05fc5ae7cf343 ] The MODULE_FIRMWARE() for 3160 should be using the 7260 version as it's done in the device configuration struct instead of referencing IWL3160_UCODE_API_OK which doesn't even exist. Cc: [3.8+] Reported-by: Hauke Mehrtens Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit e660411f12ffd775cba9d908c8d2aaaf77a9bb81 Author: Johannes Berg Date: Tue Sep 15 14:36:09 2015 +0200 iwlwifi: dvm: fix D3 firmware PN programming [ Upstream commit 5bd166872d8f99f156fac191299d24f828bb2348 ] The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Cc: [3.1+] Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 9eb61e6a6e9e64ec4426529adf64a40e8082f829 Author: Felix Fietkau Date: Thu Sep 24 16:59:46 2015 +0200 ath9k: declare required extra tx headroom [ Upstream commit 029cd0370241641eb70235d205aa0b90c84dce44 ] ath9k inserts padding between the 802.11 header and the data area (to align it). Since it didn't declare this extra required headroom, this led to some nasty issues like randomly dropped packets in some setups. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit c1128a8218b2e60e299944ce0b5c2e307ac2c7c9 Author: Rasmus Villemoes Date: Thu Feb 12 15:03:05 2015 -0800 lib/radix-tree.c: change to simpler include [ Upstream commit 886d3dfa85d5aa6f11813c319e50f5402c7cf4e4 ] The comment helpfully explains why hardirq.h is included, but since commit 2d4b84739f0a ("hardirq: Split preempt count mask definitions") in_interrupt() has been provided by preempt_mask.h. Use that instead, saving around 40 lines in the generated dependency file. Signed-off-by: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0f9d268d33632ff869d2ebaab2631fd23de7212e Author: Ilya Dryomov Date: Mon Aug 31 15:21:39 2015 +0300 rbd: fix double free on rbd_dev->header_name [ Upstream commit 3ebe138ac642a195c7f2efdb918f464734421fd6 ] If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name is freed twice: once in rbd_dev_probe_parent() and then in its caller rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to handle parent images). rbd_dev_probe_parent() is responsible for probing the parent, so it shouldn't muck with clone's fields. Signed-off-by: Ilya Dryomov Reviewed-by: Alex Elder Signed-off-by: Sasha Levin commit 587075664c04347cf92844d11a0463951ff4514d Author: Mike Snitzer Date: Tue Oct 13 12:04:28 2015 -0400 dm thin: fix missing pool reference count decrement in pool_ctr error path [ Upstream commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd ] Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed") Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Sasha Levin commit a2893d2865ff0c4dc5c2bf599746b64a8c6b5dc5 Author: Alex Deucher Date: Wed Sep 30 16:45:52 2015 -0400 drm/radeon: add pm sysfs files late [ Upstream commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 ] They were added relatively early in the driver init process which meant that in some cases the driver was not finished initializing before external tools tried to use them which could result in a crash depending on the timing. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit af26f0b37f10f06a2274956e8f645968976774ff Author: Ben Skeggs Date: Fri Oct 2 14:03:19 2015 +1000 drm/nouveau/fbcon: take runpm reference when userspace has an open fd [ Upstream commit f231976c2e8964ceaa9250e57d27c35ff03825c2 ] We need to do this in order to prevent accesses to the device while it's powered down. Userspace may have an mmap of the fb, and there's no good way (that I know of) to prevent it from touching the device otherwise. This fixes some nasty races between runpm and plymouth on some systems, which result in the GPU getting very upset and hanging the boot. Signed-off-by: Ben Skeggs Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1e7af294dd037af63e74fe13e2b6afb93105ed3f Author: Shaohua Li Date: Wed Sep 30 09:05:30 2015 -0700 workqueue: make sure delayed work run in local cpu [ Upstream commit 874bbfe600a660cba9c776b3957b1ce393151b76 ] My system keeps crashing with below message. vmstat_update() schedules a delayed work in current cpu and expects the work runs in the cpu. schedule_delayed_work() is expected to make delayed work run in local cpu. The problem is timer can be migrated with NO_HZ. __queue_work() queues work in timer handler, which could run in a different cpu other than where the delayed work is scheduled. The end result is the delayed work runs in different cpu. The patch makes __queue_delayed_work records local cpu earlier. Where the timer runs doesn't change where the work runs with the change. [ 28.010131] ------------[ cut here ]------------ [ 28.010609] kernel BUG at ../mm/vmstat.c:1392! [ 28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 28.011860] Modules linked in: [ 28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G W4.3.0-rc3+ #634 [ 28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014 [ 28.014160] Workqueue: events vmstat_update [ 28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000 [ 28.015445] RIP: 0010:[] []vmstat_update+0x31/0x80 [ 28.016282] RSP: 0018:ffff8800ba42fd80 EFLAGS: 00010297 [ 28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000 [ 28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d [ 28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000 [ 28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640 [ 28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000 [ 28.020071] FS: 0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000 [ 28.020071] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0 [ 28.020071] Stack: [ 28.020071] ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88 [ 28.020071] ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8 [ 28.020071] ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340 [ 28.020071] Call Trace: [ 28.020071] [] process_one_work+0x1c8/0x540 [ 28.020071] [] ? process_one_work+0x14b/0x540 [ 28.020071] [] worker_thread+0x114/0x460 [ 28.020071] [] ? process_one_work+0x540/0x540 [ 28.020071] [] kthread+0xf8/0x110 [ 28.020071] [] ?kthread_create_on_node+0x200/0x200 [ 28.020071] [] ret_from_fork+0x3f/0x70 [ 28.020071] [] ?kthread_create_on_node+0x200/0x200 Signed-off-by: Shaohua Li Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org # v2.6.31+ Signed-off-by: Sasha Levin commit a2a2d77c76d9efc4b5433fc5c924fcadba0b8fa1 Author: Mika Westerberg Date: Thu Sep 24 12:06:54 2015 +0300 i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348 [ Upstream commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 ] ACPI SSCN/FMCN methods were originally added because then the platform can provide the most accurate HCNT/LCNT values to the driver. However, this seems not to be true for Dell Inspiron 7348 where using these causes the touchpad to fail in boot: i2c_hid i2c-DLL0675:00: failed to retrieve report from device. i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0675:00: failed to retrieve report from device. i2c_designware INT3433:00: controller timed out The values received from ACPI are (in fast mode): HCNT: 72 LCNT: 160 this translates to following timings (input clock is 100MHz on Broadwell): tHIGH: 720 ns (spec min 600 ns) tLOW: 1600 ns (spec min 1300 ns) Bus period: 2920 ns (assuming 300 ns tf and tr) Bus speed: 342.5 kHz Both tHIGH and tLOW are within the I2C specification. The calculated values when ACPI parameters are not used are (in fast mode): HCNT: 87 LCNT: 159 which translates to: tHIGH: 870 ns (spec min 600 ns) tLOW: 1590 ns (spec min 1300 ns) Bus period 3060 ns (assuming 300 ns tf and tr) Bus speed 326.8 kHz These values are also within the I2C specification. Since both ACPI and calculated values meet the I2C specification timing requirements it is hard to say why the touchpad does not function properly with the ACPI values except that the bus speed is higher in this case (but still well below the max 400kHz). Solve this by adding DMI quirk to the driver that disables using ACPI parameters on this particulare machine. Reported-by: Pavel Roskin Signed-off-by: Mika Westerberg Tested-by: Pavel Roskin Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Sasha Levin commit 462fbcb8f833e25779cb9e9d5946992a4ac2c414 Author: Wolfram Sang Date: Sat Oct 10 08:24:23 2015 +0100 i2c: s3c2410: enable RuntimePM before registering to the core [ Upstream commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 ] The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Signed-off-by: Wolfram Sang Tested-by: Krzysztof Kozlowski Acked-by: Kukjin Kim Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Sasha Levin commit 35491413ee62ca02583a688fc30e758c11971c4f Author: Wolfram Sang Date: Fri Oct 9 10:39:25 2015 +0100 i2c: rcar: enable RuntimePM before registering to the core [ Upstream commit 4f7effddf4549d57114289f273710f077c4c330a ] The core may register clients attached to this master which may use funtionality from the master. So, RuntimePM must be enabled before, otherwise this will fail. While here, move drvdata, too. Reported-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Cc: stable@kernel.org Signed-off-by: Sasha Levin commit 3a92ba8d3117c99b3a14e898f31fe2bb6c30a9d8 Author: Will Deacon Date: Thu Oct 8 11:11:17 2015 +0100 arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419 [ Upstream commit b6dd8e0719c0d2d01429639a11b7bc2677de240c ] Commit df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") sets CFLAGS_MODULE to ensure that the large memory model is used by the compiler when building kernel modules. However, CFLAGS_MODULE is an environment variable and intended to be overridden on the command line, which appears to be the case with the Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead. Cc: Cc: Ard Biesheuvel Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") Reported-by: Dann Frazier Tested-by: Dann Frazier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 4e2dc9ce572650176e3ce3380ecaf7302547d610 Author: Chris Mason Date: Tue Oct 13 14:06:48 2015 -0400 btrfs: fix use after free iterating extrefs [ Upstream commit dc6c5fb3b514221f2e9d21ee626a9d95d3418dff ] The code for btrfs inode-resolve has never worked properly for files with enough hard links to trigger extrefs. It was trying to get the leaf out of a path after freeing the path: btrfs_release_path(path); leaf = path->nodes[0]; item_size = btrfs_item_size_nr(leaf, slot); The fix here is to use the extent buffer we cloned just a little higher up to avoid deadlocks caused by using the leaf in the path. Signed-off-by: Chris Mason cc: stable@vger.kernel.org # v3.7+ cc: Mark Fasheh Reviewed-by: Filipe Manana Reviewed-by: Mark Fasheh Signed-off-by: Sasha Levin commit e360fb086858344811bdc2f2b4c5ef6396e78179 Author: Russell King Date: Fri Oct 9 20:43:33 2015 +0100 crypto: ahash - ensure statesize is non-zero [ Upstream commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a ] Unlike shash algorithms, ahash drivers must implement export and import as their descriptors may contain hardware state and cannot be exported as is. Unfortunately some ahash drivers did not provide them and end up causing crashes with algif_hash. This patch adds a check to prevent these drivers from registering ahash algorithms until they are fixed. Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d9d554c9e98a9f63fdfa5c72049f0b126d58df76 Author: Dave Kleikamp Date: Mon Oct 5 10:08:51 2015 -0500 crypto: sparc - initialize blkcipher.ivsize [ Upstream commit a66d7f724a96d6fd279bfbd2ee488def6b081bea ] Some of the crypto algorithms write to the initialization vector, but no space has been allocated for it. This clobbers adjacent memory. Cc: stable@vger.kernel.org Signed-off-by: Dave Kleikamp Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e2fd4b16c7d495b1120dff97bb2de2a7079c53d0 Author: Joe Perches Date: Wed Oct 14 01:09:40 2015 -0700 ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings [ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ] It seems that kernel memory can leak into userspace by a kmalloc, ethtool_get_strings, then copy_to_user sequence. Avoid this by using kcalloc to zero fill the copied buffer. Signed-off-by: Joe Perches Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d2c7ba2960397cd255c66e57cf3e8ac2ab81b94d Author: Guillaume Nault Date: Wed Sep 30 11:45:33 2015 +0200 ppp: don't override sk->sk_state in pppoe_flush_dev() [ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ] Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"), pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the following oops: [ 570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0 [ 570.142931] IP: [] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0 [ 570.144601] Oops: 0000 [#1] SMP [ 570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio [ 570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1 [ 570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014 [ 570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000 [ 570.144601] RIP: 0010:[] [] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] RSP: 0018:ffff880036b63e08 EFLAGS: 00010202 [ 570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206 [ 570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20 [ 570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000 [ 570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780 [ 570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0 [ 570.144601] FS: 00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000 [ 570.144601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0 [ 570.144601] Stack: [ 570.144601] ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0 [ 570.144601] ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008 [ 570.144601] ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5 [ 570.144601] Call Trace: [ 570.144601] [] sock_release+0x1a/0x75 [ 570.144601] [] sock_close+0xd/0x11 [ 570.144601] [] __fput+0xff/0x1a5 [ 570.144601] [] ____fput+0x9/0xb [ 570.144601] [] task_work_run+0x66/0x90 [ 570.144601] [] prepare_exit_to_usermode+0x8c/0xa7 [ 570.144601] [] syscall_return_slowpath+0x16d/0x19b [ 570.144601] [] int_ret_from_sys_call+0x25/0x9f [ 570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00 [ 570.144601] RIP [] pppoe_release+0x50/0x101 [pppoe] [ 570.144601] RSP [ 570.144601] CR2: 00000000000004e0 [ 570.200518] ---[ end trace 46956baf17349563 ]--- pppoe_flush_dev() has no reason to override sk->sk_state with PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to PPPOX_DEAD, which is the correct state given that sk is unbound and po->pppoe_dev is NULL. Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Tested-by: Oleksii Berezhniak Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d48fa362803dafca999f5c336833b6e409065ecb Author: Eric Dumazet Date: Tue Sep 29 18:52:25 2015 -0700 net: add pfmemalloc check in sk_add_backlog() [ Upstream commit c7c49b8fde26b74277188bdc6c9dca38db6fa35b ] Greg reported crashes hitting the following check in __sk_backlog_rcv() BUG_ON(!sock_flag(sk, SOCK_MEMALLOC)); The pfmemalloc bit is currently checked in sk_filter(). This works correctly for TCP, because sk_filter() is ran in tcp_v[46]_rcv() before hitting the prequeue or backlog checks. For UDP or other protocols, this does not work, because the sk_filter() is ran from sock_queue_rcv_skb(), which might be called _after_ backlog queuing if socket is owned by user by the time packet is processed by softirq handler. Fixes: b4b9e35585089 ("netvm: set PF_MEMALLOC as appropriate during SKB processing") Signed-off-by: Eric Dumazet Reported-by: Greg Thelen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f688246d7ed827686f521e1625907c0ec602396e Author: Pravin B Shelar Date: Mon Sep 28 17:24:25 2015 -0700 skbuff: Fix skb checksum partial check. [ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ] Earlier patch 6ae459bda tried to detect void ckecksum partial skb by comparing pull length to checksum offset. But it does not work for all cases since checksum-offset depends on updates to skb->data. Following patch fixes it by validating checksum start offset after skb-data pointer is updated. Negative value of checksum offset start means there is no need to checksum. Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull") Reported-by: Andrew Vagin Signed-off-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6532c6b285c899bc2501ee0cb58eb78bf5c092ef Author: Pravin B Shelar Date: Tue Sep 22 12:57:53 2015 -0700 skbuff: Fix skb checksum flag on skb pull [ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ] VXLAN device can receive skb with checksum partial. But the checksum offset could be in outer header which is pulled on receive. This results in negative checksum offset for the skb. Such skb can cause the assert failure in skb_checksum_help(). Following patch fixes the bug by setting checksum-none while pulling outer header. Following is the kernel panic msg from old kernel hitting the bug. ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1906! RIP: 0010:[] skb_checksum_help+0x144/0x150 Call Trace: [] queue_userspace_packet+0x408/0x470 [openvswitch] [] ovs_dp_upcall+0x5d/0x60 [openvswitch] [] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch] [] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch] [] ovs_vport_receive+0x2a/0x30 [openvswitch] [] vxlan_rcv+0x53/0x60 [openvswitch] [] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch] [] udp_queue_rcv_skb+0x2dc/0x3b0 [] __udp4_lib_rcv+0x1cf/0x6c0 [] udp_rcv+0x1a/0x20 [] ip_local_deliver_finish+0xdd/0x280 [] ip_local_deliver+0x88/0x90 [] ip_rcv_finish+0x10d/0x370 [] ip_rcv+0x235/0x300 [] __netif_receive_skb+0x55d/0x620 [] netif_receive_skb+0x80/0x90 [] virtnet_poll+0x555/0x6f0 [] net_rx_action+0x134/0x290 [] __do_softirq+0xa8/0x210 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0x8e/0xb0 [] do_IRQ+0x63/0xe0 [] common_interrupt+0x6e/0x6e Reported-by: Anupam Chanda Signed-off-by: Pravin B Shelar Acked-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 74587138aebdfaa2a720e6479160f3590b87c01b Author: Andrey Vagin Date: Fri Oct 2 00:05:36 2015 +0300 net/unix: fix logic about sk_peek_offset [ Upstream commit e9193d60d363e4dff75ff6d43a48f22be26d59c7 ] Now send with MSG_PEEK can return data from multiple SKBs. Unfortunately we take into account the peek offset for each skb, that is wrong. We need to apply the peek offset only once. In addition, the peek offset should be used only if MSG_PEEK is set. Cc: "David S. Miller" (maintainer:NETWORKING Cc: Eric Dumazet (commit_signer:1/14=7%) Cc: Aaron Conole Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag") Signed-off-by: Andrey Vagin Tested-by: Aaron Conole Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3427bee1f57b6e1ebcc48411ecd60246c0ee1443 Author: Aaron Conole Date: Sat Sep 26 18:50:43 2015 -0400 af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag [ Upstream commit 9f389e35674f5b086edd70ed524ca0f287259725 ] AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag is set. This is referenced in kernel bugzilla #12323 @ https://bugzilla.kernel.org/show_bug.cgi?id=12323 As described both in the BZ and lkml thread @ http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an AF_UNIX socket only reads a single skb, where the desired effect is to return as much skb data has been queued, until hitting the recv buffer size (whichever comes first). The modified MSG_PEEK path will now move to the next skb in the tree and jump to the again: label, rather than following the natural loop structure. This requires duplicating some of the loop head actions. This was tested using the python socketpair python code attached to the bugzilla issue. Signed-off-by: Aaron Conole Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0a97833af00d0e7da580ea39a4551c2cf7439108 Author: Aaron Conole Date: Sat Sep 26 18:50:42 2015 -0400 af_unix: Convert the unix_sk macro to an inline function for type safety [ Upstream commit 4613012db1d911f80897f9446a49de817b2c4c47 ] As suggested by Eric Dumazet this change replaces the #define with a static inline function to enjoy complaints by the compiler when misusing the API. Signed-off-by: Aaron Conole Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3ebbc131d67cd4b513073c868d953436da430331 Author: Alexander Couzens Date: Mon Sep 28 11:32:42 2015 +0200 l2tp: protect tunnel->del_work by ref_count [ Upstream commit 06a15f51cf3618e32a73871ee6a547ef7fd902b5 ] There is a small chance that tunnel_free() is called before tunnel->del_work scheduled resulting in a zero pointer dereference. Signed-off-by: Alexander Couzens Acked-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ffb04e43c08ae23a4b3995ee77cc7fcc17a7afba Author: Jan Kara Date: Tue Jul 28 14:57:14 2015 -0400 jbd2: avoid infinite loop when destroying aborted journal [ Upstream commit 841df7df196237ea63233f0f9eaa41db53afd70f ] Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal superblock fails" changed jbd2_cleanup_journal_tail() to return EIO when the journal is aborted. That makes logic in jbd2_log_do_checkpoint() bail out which is fine, except that jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make a progress in cleaning the journal. Without it jbd2_journal_destroy() just loops in an infinite loop. Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of jbd2_log_do_checkpoint() fails with error. Reported-by: Eryu Guan Tested-by: Eryu Guan Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin