commit 311d0c83145730eede422215b346d257ca6c0869 Author: Greg Kroah-Hartman Date: Fri Aug 11 08:34:14 2017 -0700 Linux 4.12.6 commit e7672072192edc045b1abb7a61594834e6ce0032 Author: Sinclair Yeh Date: Mon Jul 17 23:26:21 2017 -0700 drm/vmwgfx: Fix cursor hotspot issue with Wayland on Fedora commit 14979adb0294f04cf6fbbb81555acff9ec1e7c9c upstream. Parts of commit <8fbf9d92a7bc> (“drm/vmwgfx: Implement the cursor_set2 callback v2”) were not moved over when we started atomic mode set development because at that time the DRM did not support cursor hotspots in the fb struct. This patch fixes what was not moved over. Signed-off-by: Sinclair Yeh Reviewed-by: Brian Paul Tested-by: Brian Paul Signed-off-by: Greg Kroah-Hartman commit c1fc78ea281efcff5879164f47d2b90535555398 Author: David S. Miller Date: Fri Aug 4 09:47:52 2017 -0700 sparc64: Fix exception handling in UltraSPARC-III memcpy. [ Upstream commit 0ede1c401332173ab0693121dc6cde04a4dbf131 ] Mikael Pettersson reported that some test programs in the strace-4.18 testsuite cause an OOPS. After some debugging it turns out that garbage values are returned when an exception occurs, causing the fixup memset() to be run with bogus arguments. The problem is that two of the exception handler stubs write the successfully copied length into the wrong register. Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.") Reported-by: Mikael Pettersson Tested-by: Mikael Pettersson Reviewed-by: Sam Ravnborg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1717ad2cdda5e5abbb03d6e6a5ea9029b94d50f1 Author: Nitin Gupta Date: Wed Jul 19 17:12:54 2017 -0700 sparc64: Register hugepages during arch init [ Upstream commit 8399e4b88a93fc7bc00fff3b8da9b2e718b7f45e ] Add hstate for each supported hugepage size using arch initcall. This change fixes some hugepage parameter parsing inconsistencies: case 1: no hugepage parameters Without hugepage parameters, only a hugepages-8192kB entry is visible in sysfs. It's different from x86_64 where both 2M and 1G hugepage sizes are available. case 2: default_hugepagesz=[64K|256M|2G] When specifying only a default_hugepagesz parameter, the default hugepage size isn't really changed and it stays at 8M. This is again different from x86_64. Orabug: 25869946 Reviewed-by: Bob Picco Signed-off-by: Nitin Gupta Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 18ba66c0be6617a5b2671dc3476927db77ee4de8 Author: Rob Gardner Date: Mon Jul 17 09:22:27 2017 -0600 sparc64: Prevent perf from running during super critical sections [ Upstream commit fc290a114fc6034b0f6a5a46e2fb7d54976cf87a ] This fixes another cause of random segfaults and bus errors that may occur while running perf with the callgraph option. Critical sections beginning with spin_lock_irqsave() raise the interrupt level to PIL_NORMAL_MAX (14) and intentionally do not block performance counter interrupts, which arrive at PIL_NMI (15). But some sections of code are "super critical" with respect to perf because the perf_callchain_user() path accesses user space and may cause TLB activity as well as faults as it unwinds the user stack. One particular critical section occurs in switch_mm: spin_lock_irqsave(&mm->context.lock, flags); ... load_secondary_context(mm); tsb_context_switch(mm); ... spin_unlock_irqrestore(&mm->context.lock, flags); If a perf interrupt arrives in between load_secondary_context() and tsb_context_switch(), then perf_callchain_user() could execute with the context ID of one process, but with an active TSB for a different process. When the user stack is accessed, it is very likely to incur a TLB miss, since the h/w context ID has been changed. The TLB will then be reloaded with a translation from the TSB for one process, but using a context ID for another process. This exposes memory from one process to another, and since it is a mapping for stack memory, this usually causes the new process to crash quickly. This super critical section needs more protection than is provided by spin_lock_irqsave() since perf interrupts must not be allowed in. Since __tsb_context_switch already goes through the trouble of disabling interrupts completely, we fix this by moving the secondary context load down into this better protected region. Orabug: 25577560 Signed-off-by: Dave Aldridge Signed-off-by: Rob Gardner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1dc14c2965cee78df9c5b9fd52412038805f3e37 Author: Jane Chu Date: Tue Jul 11 12:00:54 2017 -0600 sparc64: Measure receiver forward progress to avoid send mondo timeout [ Upstream commit 9d53caec84c7c5700e7c1ed744ea584fff55f9ac ] A large sun4v SPARC system may have moments of intensive xcall activities, usually caused by unmapping many pages on many CPUs concurrently. This can flood receivers with CPU mondo interrupts for an extended period, causing some unlucky senders to hit send-mondo timeout. This problem gets worse as cpu count increases because sometimes mappings must be invalidated on all CPUs, and sometimes all CPUs may gang up on a single CPU. But a busy system is not a broken system. In the above scenario, as long as the receiver is making forward progress processing mondo interrupts, the sender should continue to retry. This patch implements the receiver's forward progress meter by introducing a per cpu counter 'cpu_mondo_counter[cpu]' where 'cpu' is in the range of 0..NR_CPUS. The receiver increments its counter as soon as it receives a mondo and the sender tracks the receiver's counter. If the receiver has stopped making forward progress when the retry limit is reached, the sender declares send-mondo-timeout and panic; otherwise, the receiver is allowed to keep making forward progress. In addition, it's been observed that PCIe hotplug events generate Correctable Errors that are handled by hypervisor and then OS. Hypervisor 'borrows' a guest cpu strand briefly to provide the service. If the cpu strand is simultaneously the only cpu targeted by a mondo, it may not be available for the mondo in 20msec, causing SUN4V mondo timeout. It appears that 1 second is the agreed wait time between hypervisor and guest OS, this patch makes the adjustment. Orabug: 25476541 Orabug: 26417466 Signed-off-by: Jane Chu Reviewed-by: Steve Sistare Reviewed-by: Anthony Yznaga Reviewed-by: Rob Gardner Reviewed-by: Thomas Tai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7e9fdf3f652faed31dd8ba81f71f0c094397be14 Author: Michael S. Tsirkin Date: Mon Jul 31 21:49:49 2017 +0300 virtio_net: fix truesize for mergeable buffers [ Upstream commit 1daa8790d0280d2c719658e39bd59fce65efa909 ] Seth Forshee noticed a performance degradation with some workloads. This turns out to be due to packet drops. Euan Kemp noticed that this is because we drop all packets where length exceeds the truesize, but for some packets we add in extra memory without updating the truesize. This in turn was kept around unchanged from ab7db91705e95 ("virtio-net: auto-tune mergeable rx buffer size for improved performance"). That commit had an internal reason not to account for the extra space: not enough bits to do it. No longer true so let's account for the allocated length exactly. Many thanks to Seth Forshee for the report and bisecting and Euan Kemp for debugging the issue. Fixes: 680557cf79f8 ("virtio_net: rework mergeable buffer handling") Reported-by: Euan Kemp Tested-by: Euan Kemp Reported-by: Seth Forshee Tested-by: Seth Forshee Signed-off-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a0ed1f0346decfecb33afc77f333c3f38f1660dd Author: Ido Schimmel Date: Fri Jul 28 23:27:44 2017 +0300 ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev() [ Upstream commit 71ed7ee35ad2c5300f4b51634185a0193b4fb0fa ] Michał reported a NULL pointer deref during fib_sync_down_dev() when unregistering a netdevice. The problem is that we don't check for 'in_dev' being NULL, which can happen in very specific cases. Usually routes are flushed upon NETDEV_DOWN sent in either the netdev or the inetaddr notification chains. However, if an interface isn't configured with any IP address, then it's possible for host routes to be flushed following NETDEV_UNREGISTER, after NULLing dev->ip_ptr in inetdev_destroy(). To reproduce: $ ip link add type dummy $ ip route add local 1.1.1.0/24 dev dummy0 $ ip link del dev dummy0 Fix this by checking for the presence of 'in_dev' before referencing it. Fixes: 982acb97560c ("ipv4: fib: Notify about nexthop status changes") Signed-off-by: Ido Schimmel Reported-by: Michał Mirosław Tested-by: Michał Mirosław Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a799f35e52b5749b5fb7b4314b42dcd7315a908d Author: Tejun Heo Date: Sun Jul 23 08:36:15 2017 -0400 workqueue: implicit ordered attribute should be overridable commit 0a94efb5acbb6980d7c9ab604372d93cd507e4d8 upstream. 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") automatically enabled ordered attribute for unbound workqueues w/ max_active == 1. Because ordered workqueues reject max_active and some attribute changes, this implicit ordered mode broke cases where the user creates an unbound workqueue w/ max_active == 1 and later explicitly changes the related attributes. This patch distinguishes explicit and implicit ordered setting and overrides from attribute changes if implict. Signed-off-by: Tejun Heo Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") Cc: Holger Hoffstätte Signed-off-by: Greg Kroah-Hartman commit 644b39ef65ae7df632e0c0105ac2d4d2dd64a09f Author: Florian Fainelli Date: Fri Jul 28 11:58:36 2017 -0700 net: phy: Correctly process PHY_HALTED in phy_stop_machine() [ Upstream commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ] Marc reported that he was not getting the PHY library adjust_link() callback function to run when calling phy_stop() + phy_disconnect() which does not indeed happen because we set the state machine to PHY_HALTED but we don't get to run it to process this state past that point. Fix this with a synchronous call to phy_state_machine() in order to have the state machine actually act on PHY_HALTED, set the PHY device's link down, turn the network device's carrier off and finally call the adjust_link() function. Reported-by: Marc Gonzalez Fixes: a390d1f379cf ("phylib: convert state_queue work to delayed_work") Signed-off-by: Florian Fainelli Signed-off-by: Marc Gonzalez Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4ec6f731441c24e57dddce2a1bc337fe09e467f0 Author: Paolo Abeni Date: Thu Jul 27 14:45:09 2017 +0200 udp6: fix socket leak on early demux [ Upstream commit c9f2c1ae123a751d4e4f949144500219354d5ee1 ] When an early demuxed packet reaches __udp6_lib_lookup_skb(), the sk reference is retrieved and used, but the relevant reference count is leaked and the socket destructor is never called. Beyond leaking the sk memory, if there are pending UDP packets in the receive queue, even the related accounted memory is leaked. In the long run, this will cause persistent forward allocation errors and no UDP skbs (both ipv4 and ipv6) will be able to reach the user-space. Fix this by explicitly accessing the early demux reference before the lookup, and properly decreasing the socket reference count after usage. Also drop the skb_steal_sock() in __udp6_lib_lookup_skb(), and the now obsoleted comment about "socket cache". The newly added code is derived from the current ipv4 code for the similar path. v1 -> v2: fixed the __udp6_lib_rcv() return code for resubmission, as suggested by Eric Reported-by: Sam Edwards Reported-by: Marc Haber Fixes: 5425077d73e0 ("net: ipv6: Add early demux handler for UDP unicast") Signed-off-by: Paolo Abeni Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9d641966047bd45a71f78a365324c4b6b9730695 Author: Paul Blakey Date: Thu Jul 6 16:40:34 2017 +0300 net/mlx5: Fix mlx5_add_flow_rules call with correct num of dests [ Upstream commit bcec601f30fb41e9233674942fa4040a6e63657a ] When adding ethtool steering rule with action DISCARD we wrongly pass a NULL dest with dest_num 1 to mlx5_add_flow_rules(). What this error seems to have caused is sending VPORT 0 (MLX5_FLOW_DESTINATION_TYPE_VPORT) as the fte dest instead of no dests. We have fte action correctly set to DROP so it might been ignored anyways. To reproduce use: # sudo ethtool --config-nfc flow-type ether \ dst aa:bb:cc:dd:ee:ff action -1 Fixes: 74491de93712 ("net/mlx5: Add multi dest support") Signed-off-by: Paul Blakey Reviewed-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit b3829b15e644205df7bb643ba3dcc4d37005bcef Author: Eugenia Emantayev Date: Wed Jul 12 17:44:07 2017 +0300 net/mlx5e: Schedule overflow check work to mlx5e workqueue [ Upstream commit f08c39ed0bfb503c7b3e013cd40d036ce6a0941a ] This is done in order to ensure that work will not run after the cleanup. Fixes: ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit a26f9f29f107dbe5a58db8b8bc216f4a90e35fa2 Author: Eugenia Emantayev Date: Wed Jul 12 17:27:18 2017 +0300 net/mlx5e: Fix wrong delay calculation for overflow check scheduling [ Upstream commit d439c84509a510e864fdc6166c760482cd03fc57 ] The overflow_period is calculated in seconds. In order to use it for delayed work scheduling translation to jiffies is needed. Fixes: ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit f0287ec6c99486058652c0d95cabd686e4fb7a39 Author: Eugenia Emantayev Date: Sun May 28 14:27:02 2017 +0300 net/mlx5e: Add missing support for PTP_CLK_REQ_PPS request [ Upstream commit cf5033089b078303b102b65e3ccbbfa3ce0f4367 ] Add the missing option to enable the PTP_CLK_PPS function. In this case pin should be configured as 1PPS IN first and then it will be connected to PPS mechanism. Events will be reported as PTP_CLOCK_PPSUSR events to relevant sysfs. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit b2ded41c2cf38d4c48062c6a9d57403f52b3b539 Author: Eugenia Emantayev Date: Sun May 28 14:06:01 2017 +0300 net/mlx5e: Change 1PPS out scheme [ Upstream commit 4272f9b88db9223216cdf87314f570f6d81295b4 ] In order to fix the drift in 1PPS out need to adjust the next pulse. On each 1PPS out falling edge driver gets the event, then the event handler adjusts the next pulse starting time. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 7657fcff05bf1ae1e79287a11d53708d4edda756 Author: Eugenia Emantayev Date: Sun May 28 12:01:38 2017 +0300 net/mlx5e: Fix broken disable 1PPS flow [ Upstream commit 49c5031ca6f0628ef973a11b17e463e088bf859e ] Need to disable the MTPPS and unsubscribe from the pulse events when user disables the 1PPS functionality. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 1e4d8d62662831f702035f4d78768579ec3477cb Author: Eugenia Emantayev Date: Thu May 25 16:09:34 2017 +0300 net/mlx5e: Add field select to MTPPS register [ Upstream commit fa3676885e3b5be1edfa1b2cc775e20a45b34a19 ] In order to mark relevant fields while setting the MTPPS register add field select. Otherwise it can cause a misconfiguration in firmware. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 5a3f5e891ac38ae593e60adf66d59a6511c8aeb5 Author: Eugenia Emantayev Date: Thu May 25 15:11:26 2017 +0300 net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure size [ Upstream commit 0b794ffae7afa7c4e5accac8791c4b78e8d080ce ] Fix miscalculation in reserved_at_1a0 field. Fixes: ee7f12205abc ('net/mlx5e: Implement 1PPS support') Signed-off-by: Eugenia Emantayev Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 31d1e9e703dc03866e9fd5a2e0358be807390f3a Author: Ilan Tayari Date: Wed Jul 5 10:17:04 2017 +0300 net/mlx5e: Fix outer_header_zero() check size [ Upstream commit 0242f4a0bb03906010bbf80495512be00494a0ef ] outer_header_zero() routine checks if the outer_headers match of a flow-table entry are all zero. This function uses the size of whole fte_match_param, instead of just the outer_headers member, causing failure to detect all-zeros if any other members of the fte_match_param are non-zero. Use the correct size for zero check. Fixes: 6dc6071cfcde ("net/mlx5e: Add ethtool flow steering support") Signed-off-by: Ilan Tayari Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 76370f2953ccf59dc23e72defe0d38a83fe57c39 Author: Alex Vesker Date: Thu Jul 6 15:40:32 2017 +0300 net/mlx5e: IPoIB, Modify add/remove underlay QPN flows [ Upstream commit 58569ef8f619761548e7d198f59e8ebe3af91d04 ] On interface remove, the clean-up was done incorrectly causing an error in the log: "SET_FLOW_TABLE_ROOT(0x92f) op_mod(0x0) failed...syndrome (0x7e9f14)" This was caused by the following flow: -ndo_uninit: Move QP state to RST (this disconnects the QP from FT), the QP cannot be attached to any FT unless it is in RTS. -mlx5_rdma_netdev_free: cleanup_rx: Destroy FT cleanup_tx: Destroy QP and remove QPN from FT This caused a problem when destroying current FT we tried to re-attach the QP to the next FT which is not needed. The correct flow is: -mlx5_rdma_netdev_free: cleanup_rx: remove QPN from FT & Destroy FT cleanup_tx: Destroy QP Fixes: 508541146af1 ("net/mlx5: Use underlay QPN from the root name space") Signed-off-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 95e95e283656e5f2010c5e7ef4586f69a65cb262 Author: Xin Long Date: Wed Jul 26 16:24:59 2017 +0800 sctp: fix the check for _sctp_walk_params and _sctp_walk_errors [ Upstream commit 6b84202c946cd3da3a8daa92c682510e9ed80321 ] Commit b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()") tried to fix the issue that it may overstep the chunk end for _sctp_walk_{params, errors} with 'chunk_end > offset(length) + sizeof(length)'. But it introduced a side effect: When processing INIT, it verifies the chunks with 'param.v == chunk_end' after iterating all params by sctp_walk_params(). With the check 'chunk_end > offset(length) + sizeof(length)', it would return when the last param is not yet accessed. Because the last param usually is fwdtsn supported param whose size is 4 and 'chunk_end == offset(length) + sizeof(length)' This is a badly issue even causing sctp couldn't process 4-shakes. Client would always get abort when connecting to server, due to the failure of INIT chunk verification on server. The patch is to use 'chunk_end <= offset(length) + sizeof(length)' instead of 'chunk_end < offset(length) + sizeof(length)' for both _sctp_walk_params and _sctp_walk_errors. Fixes: b1f5bfc27a19 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()") Signed-off-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2e50111fedaff324f26d42c2cfa5504dd69279a8 Author: Alexander Potapenko Date: Fri Jul 14 18:32:45 2017 +0200 sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}() [ Upstream commit b1f5bfc27a19f214006b9b4db7b9126df2dfdf5a ] If the length field of the iterator (|pos.p| or |err|) is past the end of the chunk, we shouldn't access it. This bug has been detected by KMSAN. For the following pair of system calls: socket(PF_INET6, SOCK_STREAM, 0x84 /* IPPROTO_??? */) = 3 sendto(3, "A", 1, MSG_OOB, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 1 the tool has reported a use of uninitialized memory: ================================================================== BUG: KMSAN: use of uninitialized memory in sctp_rcv+0x17b8/0x43b0 CPU: 1 PID: 2940 Comm: probe Not tainted 4.11.0-rc5+ #2926 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x172/0x1c0 lib/dump_stack.c:52 kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:927 __msan_warning_32+0x61/0xb0 mm/kmsan/kmsan_instr.c:469 __sctp_rcv_init_lookup net/sctp/input.c:1074 __sctp_rcv_lookup_harder net/sctp/input.c:1233 __sctp_rcv_lookup net/sctp/input.c:1255 sctp_rcv+0x17b8/0x43b0 net/sctp/input.c:170 sctp6_rcv+0x32/0x70 net/sctp/ipv6.c:984 ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279 NF_HOOK ./include/linux/netfilter.h:257 ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322 dst_input ./include/net/dst.h:492 ip6_rcv_finish net/ipv6/ip6_input.c:69 NF_HOOK ./include/linux/netfilter.h:257 ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208 __netif_receive_skb net/core/dev.c:4246 process_backlog+0x667/0xba0 net/core/dev.c:4866 napi_poll net/core/dev.c:5268 net_rx_action+0xc95/0x1590 net/core/dev.c:5333 __do_softirq+0x485/0x942 kernel/softirq.c:284 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902 do_softirq kernel/softirq.c:328 __local_bh_enable_ip+0x25b/0x290 kernel/softirq.c:181 local_bh_enable+0x37/0x40 ./include/linux/bottom_half.h:31 rcu_read_unlock_bh ./include/linux/rcupdate.h:931 ip6_finish_output2+0x19b2/0x1cf0 net/ipv6/ip6_output.c:124 ip6_finish_output+0x764/0x970 net/ipv6/ip6_output.c:149 NF_HOOK_COND ./include/linux/netfilter.h:246 ip6_output+0x456/0x520 net/ipv6/ip6_output.c:163 dst_output ./include/net/dst.h:486 NF_HOOK ./include/linux/netfilter.h:257 ip6_xmit+0x1841/0x1c00 net/ipv6/ip6_output.c:261 sctp_v6_xmit+0x3b7/0x470 net/sctp/ipv6.c:225 sctp_packet_transmit+0x38cb/0x3a20 net/sctp/output.c:632 sctp_outq_flush+0xeb3/0x46e0 net/sctp/outqueue.c:885 sctp_outq_uncork+0xb2/0xd0 net/sctp/outqueue.c:750 sctp_side_effects net/sctp/sm_sideeffect.c:1773 sctp_do_sm+0x6962/0x6ec0 net/sctp/sm_sideeffect.c:1147 sctp_primitive_ASSOCIATE+0x12c/0x160 net/sctp/primitive.c:88 sctp_sendmsg+0x43e5/0x4f90 net/sctp/socket.c:1954 inet_sendmsg+0x498/0x670 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 sock_sendmsg net/socket.c:643 SYSC_sendto+0x608/0x710 net/socket.c:1696 SyS_sendto+0x8a/0xb0 net/socket.c:1664 do_syscall_64+0xe6/0x130 arch/x86/entry/common.c:285 entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:246 RIP: 0033:0x401133 RSP: 002b:00007fff6d99cd38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000401133 RDX: 0000000000000001 RSI: 0000000000494088 RDI: 0000000000000003 RBP: 00007fff6d99cd90 R08: 00007fff6d99cd50 R09: 000000000000001c R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00000000004063d0 R14: 0000000000406460 R15: 0000000000000000 origin: save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:198 kmsan_poison_shadow+0x6d/0xc0 mm/kmsan/kmsan.c:211 slab_alloc_node mm/slub.c:2743 __kmalloc_node_track_caller+0x200/0x360 mm/slub.c:4351 __kmalloc_reserve net/core/skbuff.c:138 __alloc_skb+0x26b/0x840 net/core/skbuff.c:231 alloc_skb ./include/linux/skbuff.h:933 sctp_packet_transmit+0x31e/0x3a20 net/sctp/output.c:570 sctp_outq_flush+0xeb3/0x46e0 net/sctp/outqueue.c:885 sctp_outq_uncork+0xb2/0xd0 net/sctp/outqueue.c:750 sctp_side_effects net/sctp/sm_sideeffect.c:1773 sctp_do_sm+0x6962/0x6ec0 net/sctp/sm_sideeffect.c:1147 sctp_primitive_ASSOCIATE+0x12c/0x160 net/sctp/primitive.c:88 sctp_sendmsg+0x43e5/0x4f90 net/sctp/socket.c:1954 inet_sendmsg+0x498/0x670 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 sock_sendmsg net/socket.c:643 SYSC_sendto+0x608/0x710 net/socket.c:1696 SyS_sendto+0x8a/0xb0 net/socket.c:1664 do_syscall_64+0xe6/0x130 arch/x86/entry/common.c:285 return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246 ================================================================== Signed-off-by: Alexander Potapenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22d79d2d63d65be500ad6f73beb7b47d87646438 Author: Moshe Shemesh Date: Sun Jun 25 18:45:32 2017 +0300 net/mlx5: Fix command bad flow on command entry allocation failure [ Upstream commit 219c81f7d1d5a89656cb3b53d3b4e11e93608d80 ] When driver fail to allocate an entry to send command to FW, it must notify the calling function and release the memory allocated for this command. Fixes: e126ba97dba9e ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Moshe Shemesh Cc: kernel-team@fb.com Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit b0220535a3b683487e2ff3204cca77faabf7d23e Author: Moshe Shemesh Date: Thu Jul 6 15:48:40 2017 +0300 net/mlx5: Fix command completion after timeout access invalid structure [ Upstream commit 061870800efb4e3d1ad4082a2569363629bdfcfc ] Completion on timeout should not free the driver command entry structure as it will need to access it again once real completion event from FW will occur. Fixes: 73dd3a4839c1 ('net/mlx5: Avoid using pending command interface slots') Signed-off-by: Moshe Shemesh Cc: kernel-team@fb.com Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit b79d0a855344682fb180ff570f9bc5b1ffd7e23e Author: Aviv Heller Date: Sun Jul 2 19:13:43 2017 +0300 net/mlx5: Consider tx_enabled in all modes on remap [ Upstream commit dc798b4cc0f2a06e7ad7d522403de274b86a0a6f ] The tx_enabled lag event field is used to determine whether a slave is active. Current logic uses this value only if the mode is active-backup. However, LACP mode, although considered a load balancing mode, can mark a slave as inactive in certain situations (e.g., LACP timeout). This fix takes the tx_enabled value into account when remapping, with no respect to the LAG mode (this should not affect the behavior in XOR mode, since in this mode both slaves are marked as active). Fixes: 7907f23adc18 (net/mlx5: Implement RoCE LAG feature) Signed-off-by: Aviv Heller Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 1f1ac346f3afd36663845a30b7dc8cf8f268b010 Author: Xin Long Date: Wed Jul 26 14:20:15 2017 +0800 dccp: fix a memleak for dccp_feat_init err process [ Upstream commit e90ce2fc27cad7e7b1e72b9e66201a7a4c124c2b ] In dccp_feat_init, when ccid_get_builtin_ccids failsto alloc memory for rx.val, it should free tx.val before returning an error. Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 240ad1a4f36005156b6a11af96bb0130ef2ad882 Author: Xin Long Date: Wed Jul 26 14:19:46 2017 +0800 dccp: fix a memleak that dccp_ipv4 doesn't put reqsk properly [ Upstream commit b7953d3c0e30a5fc944f6b7bd0bcceb0794bcd85 ] The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue exists on dccp_ipv4. This patch is to fix it for dccp_ipv4. Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 01c23dffbca03bc7e22fe292deaaf5e550900155 Author: Xin Long Date: Wed Jul 26 14:19:09 2017 +0800 dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly [ Upstream commit 0c2232b0a71db0ac1d22f751aa1ac0cadb950fd2 ] In dccp_v6_conn_request, after reqsk gets alloced and hashed into ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer, one is for hlist, and the other one is for current using. The problem is when dccp_v6_conn_request returns and finishes using reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and reqsk obj never gets freed. Jianlin found this issue when running dccp_memleak.c in a loop, the system memory would run out. dccp_memleak.c: int s1 = socket(PF_INET6, 6, IPPROTO_IP); bind(s1, &sa1, 0x20); listen(s1, 0x9); int s2 = socket(PF_INET6, 6, IPPROTO_IP); connect(s2, &sa1, 0x20); close(s1); close(s2); This patch is to put the reqsk before dccp_v6_conn_request returns, just as what tcp_conn_request does. Reported-by: Jianlin Shi Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9431dc55af35edba5f8a52de255f3a76c8fba7ff Author: WANG Cong Date: Tue Jul 25 09:44:25 2017 -0700 bonding: commit link status change after propose [ Upstream commit d94708a553022bf012fa95af10532a134eeb5a52 ] Commit de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring") moves link status commitment into bond_mii_monitor(), but it still relies on the return value of bond_miimon_inspect() as the hint. We need to return non-zero as long as we propose a link status change. Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring") Reported-by: Benjamin Gilbert Tested-by: Benjamin Gilbert Cc: Mahesh Bandewar Signed-off-by: Cong Wang Acked-by: Mahesh Bandewar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8f2da174249ecdcc885a8f88f02e221b45a94daa Author: Marc Gonzalez Date: Tue Jul 25 14:35:03 2017 +0200 net: ethernet: nb8800: Handle all 4 RGMII modes identically [ Upstream commit 4813497b537c6208c90d6cbecac5072d347de900 ] Before commit bf8f6952a233 ("Add blurb about RGMII") it was unclear whose responsibility it was to insert the required clock skew, and in hindsight, some PHY drivers got it wrong. The solution forward is to introduce a new property, explicitly requiring skew from the node to which it is attached. In the interim, this driver will handle all 4 RGMII modes identically (no skew). Fixes: 52dfc8301248 ("net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller") Signed-off-by: Marc Gonzalez Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 18e8c1b0498924ff472ab18268d7d68e47a72a84 Author: Stefano Brivio Date: Mon Jul 24 23:14:28 2017 +0200 ipv6: Don't increase IPSTATS_MIB_FRAGFAILS twice in ip6_fragment() [ Upstream commit afce615aaabfbaad02550e75c0bec106dafa1adf ] RFC 2465 defines ipv6IfStatsOutFragFails as: "The number of IPv6 datagrams that have been discarded because they needed to be fragmented at this output interface but could not be." The existing implementation, instead, would increase the counter twice in case we fail to allocate room for single fragments: once for the fragment, once for the datagram. This didn't look intentional though. In one of the two affected affected failure paths, the double increase was simply a result of a new 'goto fail' statement, introduced to avoid a skb leak. The other path appears to be affected since at least 2.6.12-rc2. Reported-by: Sabrina Dubroca Fixes: 1d325d217c7f ("ipv6: ip6_fragment: fix headroom tests and skb leak") Signed-off-by: Stefano Brivio Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit efb5ce567529648bb9a203d77e069f066096d943 Author: WANG Cong Date: Mon Jul 24 10:07:32 2017 -0700 packet: fix use-after-free in prb_retire_rx_blk_timer_expired() [ Upstream commit c800aaf8d869f2b9b47b10c5c312fe19f0a94042 ] There are multiple reports showing we have a use-after-free in the timer prb_retire_rx_blk_timer_expired(), where we use struct tpacket_kbdq_core::pkbdq, a pg_vec, after it gets freed by free_pg_vec(). The interesting part is it is not freed via packet_release() but via packet_setsockopt(), which means we are not closing the socket. Looking into the big and fat function packet_set_ring(), this could happen if we satisfy the following conditions: 1. closing == 0, not on packet_release() path 2. req->tp_block_nr == 0, we don't allocate a new pg_vec 3. rx_ring->pg_vec is already set as V3, which means we already called packet_set_ring() wtih req->tp_block_nr > 0 previously 4. req->tp_frame_nr == 0, pass sanity check 5. po->mapped == 0, never called mmap() In this scenario we are clearing the old rx_ring->pg_vec, so we need to free this pg_vec, but we don't stop the timer on this path because of closing==0. The timer has to be stopped as long as we need to free pg_vec, therefore the check on closing!=0 is wrong, we should check pg_vec!=NULL instead. Thanks to liujian for testing different fixes. Reported-by: alexander.levin@verizon.com Reported-by: Dave Jones Reported-by: liujian (CE) Tested-by: liujian (CE) Cc: Ding Tianhong Cc: Willem de Bruijn Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9bb104937bba459bba907663e7a644f987b849d3 Author: Liping Zhang Date: Sun Jul 23 17:52:23 2017 +0800 openvswitch: fix potential out of bound access in parse_ct [ Upstream commit 69ec932e364b1ba9c3a2085fe96b76c8a3f71e7c ] Before the 'type' is validated, we shouldn't use it to fetch the ovs_ct_attr_lens's minlen and maxlen, else, out of bound access may happen. Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action") Signed-off-by: Liping Zhang Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 98a729f5902205ec83d3b0911acb60385dbc84c8 Author: Thomas Jarosch Date: Sat Jul 22 17:14:34 2017 +0200 mcs7780: Fix initialization when CONFIG_VMAP_STACK is enabled [ Upstream commit 9476d393667968b4a02afbe9d35a3558482b943e ] DMA transfers are not allowed to buffers that are on the stack. Therefore allocate a buffer to store the result of usb_control_message(). Fixes these bugreports: https://bugzilla.kernel.org/show_bug.cgi?id=195217 https://bugzilla.redhat.com/show_bug.cgi?id=1421387 https://bugzilla.redhat.com/show_bug.cgi?id=1427398 Shortened kernel backtrace from 4.11.9-200.fc25.x86_64: kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 3 PID: 2957 at drivers/usb/core/hcd.c:1587 kernel: transfer buffer not dma capable kernel: Call Trace: kernel: dump_stack+0x63/0x86 kernel: __warn+0xcb/0xf0 kernel: warn_slowpath_fmt+0x5a/0x80 kernel: usb_hcd_map_urb_for_dma+0x37f/0x570 kernel: ? try_to_del_timer_sync+0x53/0x80 kernel: usb_hcd_submit_urb+0x34e/0xb90 kernel: ? schedule_timeout+0x17e/0x300 kernel: ? del_timer_sync+0x50/0x50 kernel: ? __slab_free+0xa9/0x300 kernel: usb_submit_urb+0x2f4/0x560 kernel: ? urb_destroy+0x24/0x30 kernel: usb_start_wait_urb+0x6e/0x170 kernel: usb_control_msg+0xdc/0x120 kernel: mcs_get_reg+0x36/0x40 [mcs7780] kernel: mcs_net_open+0xb5/0x5c0 [mcs7780] ... Regression goes back to 4.9, so it's a good candidate for -stable. Though it's the decision of the maintainer. Thanks to Dan Williams for adding the "transfer buffer not dma capable" warning in the first place. It instantly pointed me in the right direction. Patch has been tested with transferring data from a Polar watch. Signed-off-by: Thomas Jarosch Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dbefa93ede5bfc5678edc66c30c25614f7c10e78 Author: Kosuke Tatsukawa Date: Thu Jul 20 05:20:40 2017 +0000 net: bonding: Fix transmit load balancing in balance-alb mode [ Upstream commit cbf5ecb305601d063dc94a57680dfbc3f96c188d ] balance-alb mode used to have transmit dynamic load balancing feature enabled by default. However, transmit dynamic load balancing no longer works in balance-alb after commit 8b426dc54cf4 ("bonding: remove hardcoded value"). Both balance-tlb and balance-alb use the function bond_do_alb_xmit() to send packets. This function uses the parameter tlb_dynamic_lb. tlb_dynamic_lb used to have the default value of 1 for balance-alb, but now the value is set to 0 except in balance-tlb. Re-enable transmit dyanmic load balancing by initializing tlb_dynamic_lb for balance-alb similar to balance-tlb. Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value") Signed-off-by: Kosuke Tatsukawa Acked-by: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 747635d31fcc740eb4f32412bb66a821584ba699 Author: WANG Cong Date: Thu Jul 20 11:27:57 2017 -0700 rtnetlink: allocate more memory for dev_set_mac_address() [ Upstream commit 153711f9421be5dbc973dc57a4109dc9d54c89b1 ] virtnet_set_mac_address() interprets mac address as struct sockaddr, but upper layer only allocates dev->addr_len which is ETH_ALEN + sizeof(sa_family_t) in this case. We lack a unified definition for mac address, so just fix the upper layer, this also allows drivers to interpret it to struct sockaddr freely. Reported-by: David Ahern Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fff61731243f6bb04005352b5723c0c74bb4fa9d Author: Mahesh Bandewar Date: Wed Jul 19 15:41:33 2017 -0700 ipv4: initialize fib_trie prior to register_netdev_notifier call. [ Upstream commit 8799a221f5944a7d74516ecf46d58c28ec1d1f75 ] Net stack initialization currently initializes fib-trie after the first call to netdevice_notifier() call. In fact fib_trie initialization needs to happen before first rtnl_register(). It does not cause any problem since there are no devices UP at this moment, but trying to bring 'lo' UP at initialization would make this assumption wrong and exposes the issue. Fixes following crash Call Trace: ? alternate_node_alloc+0x76/0xa0 fib_table_insert+0x1b7/0x4b0 fib_magic.isra.17+0xea/0x120 fib_add_ifaddr+0x7b/0x190 fib_netdev_event+0xc0/0x130 register_netdevice_notifier+0x1c1/0x1d0 ip_fib_init+0x72/0x85 ip_rt_init+0x187/0x1e9 ip_init+0xe/0x1a inet_init+0x171/0x26c ? ipv4_offload_init+0x66/0x66 do_one_initcall+0x43/0x160 kernel_init_freeable+0x191/0x219 ? rest_init+0x80/0x80 kernel_init+0xe/0x150 ret_from_fork+0x22/0x30 Code: f6 46 23 04 74 86 4c 89 f7 e8 ae 45 01 00 49 89 c7 4d 85 ff 0f 85 7b ff ff ff 31 db eb 08 4c 89 ff e8 16 47 01 00 48 8b 44 24 38 <45> 8b 6e 14 4d 63 76 74 48 89 04 24 0f 1f 44 00 00 48 83 c4 08 RIP: kmem_cache_alloc+0xcf/0x1c0 RSP: ffff9b1500017c28 CR2: 0000000000000014 Fixes: 7b1a74fdbb9e ("[NETNS]: Refactor fib initialization so it can handle multiple namespaces.") Fixes: 7f9b80529b8a ("[IPV4]: fib hash|trie initialization") Signed-off-by: Mahesh Bandewar Acked-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c141ec8071f00ff86541de66cf4449f26812642d Author: Florian Fainelli Date: Thu Jul 20 12:25:22 2017 -0700 net: dsa: b53: Add missing ARL entries for BCM53125 [ Upstream commit be35e8c516c1915a3035d266a2015b41f73ba3f9 ] The BCM53125 entry was missing an arl_entries member which would basically prevent the ARL search from terminating properly. This switch has 4 ARL entries, so add that. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Florian Fainelli Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 663f828a08af6f54c4f11c1eb16e68ad7a93c34c Author: Sabrina Dubroca Date: Wed Jul 19 22:28:55 2017 +0200 ipv6: avoid overflow of offset in ip6_find_1stfragopt [ Upstream commit 6399f1fae4ec29fab5ec76070435555e256ca3a6 ] In some cases, offset can overflow and can cause an infinite loop in ip6_find_1stfragopt(). Make it unsigned int to prevent the overflow, and cap it at IPV6_MAXPLEN, since packets larger than that should be invalid. This problem has been here since before the beginning of git history. Signed-off-by: Sabrina Dubroca Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5d5374b2640a154791a2e3972cf3a247eba1ea2e Author: David Ahern Date: Wed Jul 19 10:22:40 2017 -0700 Revert "rtnetlink: Do not generate notifications for CHANGEADDR event" [ Upstream commit 3753654e541938717b13f2b25791c3171a3a06aa ] This reverts commit cd8966e75ed3c6b41a37047a904617bc44fa481f. The duplicate CHANGEADDR event message is sent regardless of link status whereas the setlink changes only generate a notification when the link is up. Not sending a notification when the link is down breaks dhcpcd which only processes hwaddr changes when the link is down. Fixes reported regression: https://bugzilla.kernel.org/show_bug.cgi?id=196355 Reported-by: Yaroslav Isakov Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22bd5eb059ddcfdaac67305c96602be9268893d8 Author: Martin Hundebøll Date: Wed Jul 19 08:17:02 2017 +0200 net: dsa: mv88e6xxx: Enable CMODE config support for 6390X [ Upstream commit bb0a2675f72b458e64f47071e8aabdb225a6af4d ] Commit f39908d3b1c45 ('net: dsa: mv88e6xxx: Set the CMODE for mv88e6390 ports 9 & 10') added support for setting the CMODE for the 6390X family, but only enabled it for 9290 and 6390 - and left out 6390X. Fix support for setting the CMODE on 6390X also by assigning mv88e6390x_port_set_cmode() to the .port_set_cmode function pointer in mv88e6390x_ops too. Fixes: f39908d3b1c4 ("net: dsa: mv88e6xxx: Set the CMODE for mv88e6390 ports 9 & 10") Signed-off-by: Martin Hundebøll Reviewed-by: Andrew Lunn Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f236da93df5be85409c24f03683e3d8c54fac72b Author: David S. Miller Date: Wed Jul 19 13:33:24 2017 -0700 net: Zero terminate ifr_name in dev_ifname(). [ Upstream commit 63679112c536289826fec61c917621de95ba2ade ] The ifr.ifr_name is passed around and assumed to be NULL terminated. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c42851f218cc1a82494bd4263952f9b7a8673fcd Author: Levin, Alexander Date: Tue Jul 18 04:23:16 2017 +0000 wireless: wext: terminate ifr name coming from userspace [ Upstream commit 98de4e0ea47d106846fc0e30ce4e644283fa7fc2 ] ifr name is assumed to be a valid string by the kernel, but nothing was forcing username to pass a valid string. In turn, this would cause panics as we tried to access the string past it's valid memory. Signed-off-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d07247418f167086ac09759ff5f07dd1e4cf3dc8 Author: Alexander Potapenko Date: Mon Jul 17 12:35:58 2017 +0200 ipv4: ipv6: initialize treq->txhash in cookie_v[46]_check() [ Upstream commit 18bcf2907df935981266532e1e0d052aff2e6fae ] KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(), which originated from the TCP request socket created in cookie_v6_check(): ================================================================== BUG: KMSAN: use of uninitialized memory in tcp_transmit_skb+0xf77/0x3ec0 CPU: 1 PID: 2949 Comm: syz-execprog Not tainted 4.11.0-rc5+ #2931 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 TCP: request_sock_TCPv6: Possible SYN flooding on port 20028. Sending cookies. Check SNMP counters. Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x172/0x1c0 lib/dump_stack.c:52 kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:927 __msan_warning_32+0x61/0xb0 mm/kmsan/kmsan_instr.c:469 skb_set_hash_from_sk ./include/net/sock.h:2011 tcp_transmit_skb+0xf77/0x3ec0 net/ipv4/tcp_output.c:983 tcp_send_ack+0x75b/0x830 net/ipv4/tcp_output.c:3493 tcp_delack_timer_handler+0x9a6/0xb90 net/ipv4/tcp_timer.c:284 tcp_delack_timer+0x1b0/0x310 net/ipv4/tcp_timer.c:309 call_timer_fn+0x240/0x520 kernel/time/timer.c:1268 expire_timers kernel/time/timer.c:1307 __run_timers+0xc13/0xf10 kernel/time/timer.c:1601 run_timer_softirq+0x36/0xa0 kernel/time/timer.c:1614 __do_softirq+0x485/0x942 kernel/softirq.c:284 invoke_softirq kernel/softirq.c:364 irq_exit+0x1fa/0x230 kernel/softirq.c:405 exiting_irq+0xe/0x10 ./arch/x86/include/asm/apic.h:657 smp_apic_timer_interrupt+0x5a/0x80 arch/x86/kernel/apic/apic.c:966 apic_timer_interrupt+0x86/0x90 arch/x86/entry/entry_64.S:489 RIP: 0010:native_restore_fl ./arch/x86/include/asm/irqflags.h:36 RIP: 0010:arch_local_irq_restore ./arch/x86/include/asm/irqflags.h:77 RIP: 0010:__msan_poison_alloca+0xed/0x120 mm/kmsan/kmsan_instr.c:440 RSP: 0018:ffff880024917cd8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10 RAX: 0000000000000246 RBX: ffff8800224c0000 RCX: 0000000000000005 RDX: 0000000000000004 RSI: ffff880000000000 RDI: ffffea0000b6d770 RBP: ffff880024917d58 R08: 0000000000000dd8 R09: 0000000000000004 R10: 0000160000000000 R11: 0000000000000000 R12: ffffffff85abf810 R13: ffff880024917dd8 R14: 0000000000000010 R15: ffffffff81cabde4 poll_select_copy_remaining+0xac/0x6b0 fs/select.c:293 SYSC_select+0x4b4/0x4e0 fs/select.c:653 SyS_select+0x76/0xa0 fs/select.c:634 entry_SYSCALL_64_fastpath+0x13/0x94 arch/x86/entry/entry_64.S:204 RIP: 0033:0x4597e7 RSP: 002b:000000c420037ee0 EFLAGS: 00000246 ORIG_RAX: 0000000000000017 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004597e7 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 000000c420037ef0 R08: 000000c420037ee0 R09: 0000000000000059 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000042dc20 R13: 00000000000000f3 R14: 0000000000000030 R15: 0000000000000003 chained origin: save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 kmsan_save_stack mm/kmsan/kmsan.c:317 kmsan_internal_chain_origin+0x12a/0x1f0 mm/kmsan/kmsan.c:547 __msan_store_shadow_origin_4+0xac/0x110 mm/kmsan/kmsan_instr.c:259 tcp_create_openreq_child+0x709/0x1ae0 net/ipv4/tcp_minisocks.c:472 tcp_v6_syn_recv_sock+0x7eb/0x2a30 net/ipv6/tcp_ipv6.c:1103 tcp_get_cookie_sock+0x136/0x5f0 net/ipv4/syncookies.c:212 cookie_v6_check+0x17a9/0x1b50 net/ipv6/syncookies.c:245 tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:989 tcp_v6_do_rcv+0xdd8/0x1c60 net/ipv6/tcp_ipv6.c:1298 tcp_v6_rcv+0x41a3/0x4f00 net/ipv6/tcp_ipv6.c:1487 ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279 NF_HOOK ./include/linux/netfilter.h:257 ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322 dst_input ./include/net/dst.h:492 ip6_rcv_finish net/ipv6/ip6_input.c:69 NF_HOOK ./include/linux/netfilter.h:257 ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208 __netif_receive_skb net/core/dev.c:4246 process_backlog+0x667/0xba0 net/core/dev.c:4866 napi_poll net/core/dev.c:5268 net_rx_action+0xc95/0x1590 net/core/dev.c:5333 __do_softirq+0x485/0x942 kernel/softirq.c:284 origin: save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:198 kmsan_kmalloc+0x7f/0xe0 mm/kmsan/kmsan.c:337 kmem_cache_alloc+0x1c2/0x1e0 mm/slub.c:2766 reqsk_alloc ./include/net/request_sock.h:87 inet_reqsk_alloc+0xa4/0x5b0 net/ipv4/tcp_input.c:6200 cookie_v6_check+0x4f4/0x1b50 net/ipv6/syncookies.c:169 tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:989 tcp_v6_do_rcv+0xdd8/0x1c60 net/ipv6/tcp_ipv6.c:1298 tcp_v6_rcv+0x41a3/0x4f00 net/ipv6/tcp_ipv6.c:1487 ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279 NF_HOOK ./include/linux/netfilter.h:257 ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322 dst_input ./include/net/dst.h:492 ip6_rcv_finish net/ipv6/ip6_input.c:69 NF_HOOK ./include/linux/netfilter.h:257 ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208 __netif_receive_skb net/core/dev.c:4246 process_backlog+0x667/0xba0 net/core/dev.c:4866 napi_poll net/core/dev.c:5268 net_rx_action+0xc95/0x1590 net/core/dev.c:5333 __do_softirq+0x485/0x942 kernel/softirq.c:284 ================================================================== Similar error is reported for cookie_v4_check(). Fixes: 58d607d3e52f ("tcp: provide skb->hash to synack packets") Signed-off-by: Alexander Potapenko Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 36076d6798b6fbea495f0461c1fa80ff2498246f Author: Neal Cardwell Date: Fri Jul 14 17:49:25 2017 -0400 tcp_bbr: init pacing rate on first RTT sample [ Upstream commit 32984565574da7ed3afa10647bb4020d7a9e6c93 ] Fixes the following behavior: for connections that had no RTT sample at the time of initializing congestion control, BBR was initializing the pacing rate to a high nominal rate (based an a guess of RTT=1ms, in case this is LAN traffic). Then BBR never adjusted the pacing rate downward upon obtaining an actual RTT sample, if the connection never filled the pipe (e.g. all sends were small app-limited writes()). This fix adjusts the pacing rate upon obtaining the first RTT sample. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cfd5740133bc6b6d4c07fb65eb4ccf8052533bfe Author: Neal Cardwell Date: Fri Jul 14 17:49:24 2017 -0400 tcp_bbr: remove sk_pacing_rate=0 transient during init [ Upstream commit 1d3648eb5d1fe9ed3d095ed8fa19ad11ca4c8bc0 ] Fix a corner case noticed by Eric Dumazet, where BBR's setting sk->sk_pacing_rate to 0 during initialization could theoretically cause packets in the sending host to hang if there were packets "in flight" in the pacing infrastructure at the time the BBR congestion control state is initialized. This could occur if the pacing infrastructure happened to race with bbr_init() in a way such that the pacer read the 0 rather than the immediately following non-zero pacing rate. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Reported-by: Eric Dumazet Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6d7b91fccff92e55d2dae3b115af6fb5bc177504 Author: Neal Cardwell Date: Fri Jul 14 17:49:23 2017 -0400 tcp_bbr: introduce bbr_init_pacing_rate_from_rtt() helper [ Upstream commit 79135b89b8af304456bd67916b80116ddf03d7b6 ] Introduce a helper to initialize the BBR pacing rate unconditionally, based on the current cwnd and RTT estimate. This is a pure refactor, but is needed for two following fixes. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b670ddb7174ce9e47fccd110d097bf841170f61d Author: Neal Cardwell Date: Fri Jul 14 17:49:22 2017 -0400 tcp_bbr: introduce bbr_bw_to_pacing_rate() helper [ Upstream commit f19fd62dafaf1ed6cf615dba655b82fa9df59074 ] Introduce a helper to convert a BBR bandwidth and gain factor to a pacing rate in bytes per second. This is a pure refactor, but is needed for two following fixes. Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6353e19d0caac2e1188ddde5a9b0a5b88da1469a Author: Neal Cardwell Date: Fri Jul 14 17:49:21 2017 -0400 tcp_bbr: cut pacing rate only if filled pipe [ Upstream commit 4aea287e90dd61a48268ff2994b56f9799441b62 ] In bbr_set_pacing_rate(), which decides whether to cut the pacing rate, there was some code that considered exiting STARTUP to be equivalent to the notion of filling the pipe (i.e., bbr_full_bw_reached()). Specifically, as the code was structured, exiting STARTUP and going into PROBE_RTT could cause us to cut the pacing rate down to something silly and low, based on whatever bandwidth samples we've had so far, when it's possible that all of them have been small app-limited bandwidth samples that are not representative of the bandwidth available in the path. (The code was correct at the time it was written, but the state machine changed without this spot being adjusted correspondingly.) Fixes: 0f8782ea1497 ("tcp_bbr: add BBR congestion control") Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c52b446b4921efcf58d75b0f59641ec7e78662d7 Author: Xin Long Date: Fri Jul 14 22:07:33 2017 +0800 sctp: fix an array overflow when all ext chunks are set [ Upstream commit 10b3bf54406bb7f4e78da9bb2a485c5c986678ad ] Marcelo noticed an array overflow caused by commit c28445c3cb07 ("sctp: add reconf_enable in asoc ep and netns"), in which sctp would add SCTP_CID_RECONF into extensions when reconf_enable is set in sctp_make_init and sctp_make_init_ack. Then now when all ext chunks are set, 4 ext chunk ids can be put into extensions array while extensions array size is 3. It would cause a kernel panic because of this overflow. This patch is to fix it by defining extensions array size is 4 in both sctp_make_init and sctp_make_init_ack. Fixes: c28445c3cb07 ("sctp: add reconf_enable in asoc ep and netns") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 52bc1dfd016e7a1859138d986670408fc3d830a0 Author: Steven Toth Date: Tue Jun 6 09:30:27 2017 -0300 saa7164: fix double fetch PCIe access condition commit 6fb05e0dd32e566facb96ea61a48c7488daa5ac3 upstream. Avoid a double fetch by reusing the values from the prior transfer. Originally reported via https://bugzilla.kernel.org/show_bug.cgi?id=195559 Thanks to Pengfei Wang for reporting. Signed-off-by: Steven Toth Reported-by: Pengfei Wang Signed-off-by: Mauro Carvalho Chehab Cc: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit 3c6a05484d0daca74f880d9559e28236330525cf Author: Christoph Hellwig Date: Fri Jul 21 13:46:10 2017 +0200 block: disable runtime-pm for blk-mq commit 765e40b675a9566459ddcb8358ad16f3b8344bbe upstream. The blk-mq code lacks support for looking at the rpm_status field, tracking active requests and the RQF_PM flag. Due to the default switch to blk-mq for scsi people start to run into suspend / resume issue due to this fact, so make sure we disable the runtime PM functionality until it is properly implemented. Signed-off-by: Christoph Hellwig Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Cc: Oleksandr Natalenko Signed-off-by: Greg Kroah-Hartman commit 1b5a7455d345b223d3a4658a9e5fce985b7998c1 Author: Christoph Hellwig Date: Mon Jun 26 12:20:57 2017 +0200 blk-mq: Create hctx for each present CPU commit 4b855ad37194f7bdbb200ce7a1c7051fecb56a08 upstream. Currently we only create hctx for online CPUs, which can lead to a lot of churn due to frequent soft offline / online operations. Instead allocate one for each present CPU to avoid this and dramatically simplify the code. Signed-off-by: Christoph Hellwig Reviewed-by: Jens Axboe Cc: Keith Busch Cc: linux-block@vger.kernel.org Cc: linux-nvme@lists.infradead.org Link: http://lkml.kernel.org/r/20170626102058.10200-3-hch@lst.de Signed-off-by: Thomas Gleixner Cc: Oleksandr Natalenko Cc: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 19da5f4ffee6358b396fc7f609eae0e02e1ded97 Author: Christoph Hellwig Date: Mon Jun 26 12:20:56 2017 +0200 blk-mq: Include all present CPUs in the default queue mapping commit 5f042e7cbd9ebd3580077dcdc21f35e68c2adf5f upstream. This way we get a nice distribution independent of the current cpu online / offline state. Signed-off-by: Christoph Hellwig Reviewed-by: Jens Axboe Cc: Keith Busch Cc: linux-block@vger.kernel.org Cc: linux-nvme@lists.infradead.org Link: http://lkml.kernel.org/r/20170626102058.10200-2-hch@lst.de Signed-off-by: Thomas Gleixner Cc: Oleksandr Natalenko Cc: Mike Galbraith Signed-off-by: Greg Kroah-Hartman commit 4a309747aca08707cdced0d36f66d040f9977bb3 Author: Omar Sandoval Date: Thu Jul 20 15:10:35 2017 -0700 Btrfs: fix early ENOSPC due to delalloc commit 17024ad0a0fdfcfe53043afb969b813d3e020c21 upstream. If a lot of metadata is reserved for outstanding delayed allocations, we rely on shrink_delalloc() to reclaim metadata space in order to fulfill reservation tickets. However, shrink_delalloc() has a shortcut where if it determines that space can be overcommitted, it will stop early. This made sense before the ticketed enospc system, but now it means that shrink_delalloc() will often not reclaim enough space to fulfill any tickets, leading to an early ENOSPC. (Reservation tickets don't care about being able to overcommit, they need every byte accounted for.) Fix it by getting rid of the shortcut so that shrink_delalloc() reclaims all of the metadata it is supposed to. This fixes early ENOSPCs we were seeing when doing a btrfs receive to populate a new filesystem, as well as early ENOSPCs Christoph saw when doing a big cp -r onto Btrfs. Fixes: 957780eb2788 ("Btrfs: introduce ticketed enospc infrastructure") Tested-by: Christoph Anton Mitterer Reviewed-by: Josef Bacik Signed-off-by: Omar Sandoval Signed-off-by: David Sterba Signed-off-by: Nikolay Borisov Signed-off-by: Greg Kroah-Hartman commit 0965d89ebda3d71338ab2573c1a4d784c1e79611 Author: Jan Kara Date: Sun Jul 30 23:33:01 2017 -0400 ext4: Don't clear SGID when inheriting ACLs commit a3bb2d5587521eea6dab2d05326abb0afb460abd upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __ext4_set_acl() into ext4_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 073931017b49d9458aa351605b43a7e34598caef Signed-off-by: Theodore Ts'o Signed-off-by: Jan Kara Reviewed-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 8189a56bf6f2cceba2ad66e01560fc286f5d269e Author: Ernesto A. Fernández Date: Sun Jul 30 22:43:41 2017 -0400 ext4: preserve i_mode if __ext4_set_acl() fails commit 397e434176bb62bc6068d2210af1d876c6212a7e upstream. When changing a file's acl mask, __ext4_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. Signed-off-by: Ernesto A. Fernández Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit aaab6465ed73cd0fdc7f5b2d7358212df9241fc9 Author: Xiubo Li Date: Tue Jul 11 17:59:43 2017 +0800 tcmu: Fix possbile memory leak / OOPs when recalculating cmd base size commit b3743c71b7c33a126d6d8942bb268775987400ec upstream. For all the entries allocated from the ring cmd area, the memory is something like the stack memory, which will always reserve the old data, so the entry->req.iov_bidi_cnt maybe none zero. On some environments, the crash could be reproduce very easy and some not. The following is the crash core trace as reported by Damien: [ 240.143969] CPU: 0 PID: 1285 Comm: iscsi_trx Not tainted 4.12.0-rc1+ #3 [ 240.150607] Hardware name: ASUS All Series/H87-PRO, BIOS 2104 10/28/2014 [ 240.157331] task: ffff8807de4f5800 task.stack: ffffc900047dc000 [ 240.163270] RIP: 0010:memcpy_erms+0x6/0x10 [ 240.167377] RSP: 0018:ffffc900047dfc68 EFLAGS: 00010202 [ 240.172621] RAX: ffffc9065db85540 RBX: ffff8807f7980000 RCX: 0000000000000010 [ 240.179771] RDX: 0000000000000010 RSI: ffff8807de574fe0 RDI: ffffc9065db85540 [ 240.186930] RBP: ffffc900047dfd30 R08: ffff8807de41b000 R09: 0000000000000000 [ 240.194088] R10: 0000000000000040 R11: ffff8807e9b726f0 R12: 00000006565726b0 [ 240.201246] R13: ffffc90007612ea0 R14: 000000065657d540 R15: 0000000000000000 [ 240.208397] FS: 0000000000000000(0000) GS:ffff88081fa00000(0000) knlGS:0000000000000000 [ 240.216510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.222280] CR2: ffffc9065db85540 CR3: 0000000001c0f000 CR4: 00000000001406f0 [ 240.229430] Call Trace: [ 240.231887] ? tcmu_queue_cmd+0x83c/0xa80 [ 240.235916] ? target_check_reservation+0xcd/0x6f0 [ 240.240725] __target_execute_cmd+0x27/0xa0 [ 240.244918] target_execute_cmd+0x232/0x2c0 [ 240.249124] ? __local_bh_enable_ip+0x64/0xa0 [ 240.253499] iscsit_execute_cmd+0x20d/0x270 [ 240.257693] iscsit_sequence_cmd+0x110/0x190 [ 240.261985] iscsit_get_rx_pdu+0x360/0xc80 [ 240.267565] ? iscsi_target_rx_thread+0x54/0xd0 [ 240.273571] iscsi_target_rx_thread+0x9a/0xd0 [ 240.279413] kthread+0x113/0x150 [ 240.284120] ? iscsi_target_tx_thread+0x1e0/0x1e0 [ 240.290297] ? kthread_create_on_node+0x40/0x40 [ 240.296297] ret_from_fork+0x2e/0x40 [ 240.301332] Code: 90 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 [ 240.321751] RIP: memcpy_erms+0x6/0x10 RSP: ffffc900047dfc68 [ 240.328838] CR2: ffffc9065db85540 [ 240.333667] ---[ end trace b7e5354cfb54d08b ]--- To fix this, just memset all the entry memory before using it, and also to be more readable we adjust the bidi code. Fixed: fe25cc34795(tcmu: Recalculate the tcmu_cmd size to save cmd area memories) Reported-by: Bryant G. Ly Tested-by: Bryant G. Ly Reported-by: Damien Le Moal Tested-by: Damien Le Moal Reviewed-by: Mike Christie Signed-off-by: Xiubo Li Cc: # 4.12+ Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 35596a1869c0eb7a5538622c0cd704718e0d8db5 Author: Xiubo Li Date: Fri Jun 30 16:14:16 2017 +0800 tcmu: Fix flushing cmd entry dcache page commit 9d62bc0e6d79b11e3298e831358155930fb8f5e3 upstream. When feeding the tcmu's cmd ring, we need to flush the dcache page for the cmd entry to make sure these kernel stores are visible to user space mappings of that page. For the none PAD cmd entry, this will be flushed at the end of the tcmu_queue_cmd_ring(). Signed-off-by: Xiubo Li Reviewed-by: Mike Christie Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 7ddb4a594d340e20c1b5f2b00233e472de8d8a2d Author: Anton Blanchard Date: Sat May 6 22:00:11 2017 -0300 ir-spi: Fix issues with lirc API commit cc20ba4ed8576abfa10a17e81cb4521f474624f0 upstream. The ir-spi driver has 2 issues which prevents it from working with lirc: 1. The ir-spi driver uses 16 bits of SPI data to create one cycle of the waveform. As such our SPI clock needs to be 16x faster than the carrier frequency. The driver is inconsistent in how it currently handles this. It initializes it to the carrier frequency: But the commit message has some example code which initialises it to 16x the carrier frequency: val = 608000; ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val); To maintain compatibility with lirc, always do the frequency adjustment in the driver. 2. lirc presents pulses in microseconds, but the ir-spi driver treats them as cycles of the carrier. Similar to other lirc drivers, do the conversion with DIV_ROUND_CLOSEST(). Fixes: fe052da49201 ("[media] rc: add support for IR LEDs driven through SPI") Signed-off-by: Anton Blanchard Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 791bfcf604a515991512c5867f2006ecc85d420b Author: Prabhakar Lad Date: Thu Jul 20 08:02:09 2017 -0400 media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl commit da05d52d2f0f6bd61094a0cd045fed94bf7d673a upstream. this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works for vpfe_capture driver with a minimal patch suitable for backporting. - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Due to these reasons we make sure this ioctl now returns -EINVAL and backport this patch as far as possible. Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver") Signed-off-by: Lad, Prabhakar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 16823f169452ddc8a5e0c583329d288fc66c6067 Author: Sean Young Date: Fri Jul 7 18:49:18 2017 -0300 media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds commit 9f5039ba440e499d85c29b1ddbc3cbc9dc90e44b upstream. Since commit e8f4818895b3 ("[media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that the hardware can detect. This breaks decoding in lirc because lircd expects the answer in microseconds, but nanoseconds is returned. Reported-by: Derek Tested-by: Derek Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 70ff1cb3d53c908423100e4842a048505e20a537 Author: Hans Verkuil Date: Sun Jul 16 05:15:47 2017 -0300 media: pulse8-cec: persistent_config should be off by default commit 9b7c0c476f66ee212925c801c4141fdd83b7336d upstream. The persistent_config option is used to make the CEC settings persistent by using the eeprom inside the device to store this information. This was on by default, which caused confusion since this device now behaves differently from other CEC devices which all come up unconfigured. Another reason for doing this now is that I hope a more standard way of selecting persistent configuration will be created in the future. And for that to work all CEC drivers should behave the same and come up unconfigured by default. None of the open source CEC applications are using this CEC framework at the moment so change this behavior before it is too late. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 44551929e06f2daf4ed0f062e9b79ef1a6aa3cf9 Author: Marc Gonzalez Date: Fri Jul 28 15:27:49 2017 +0200 ARM: dts: tango4: Request RGMII RX and TX clock delays commit 985333b0eef8603b02181c4ec0a722b82be9642d upstream. RX and TX clock delays are required. Request them explicitly. Fixes: cad008b8a77e6 ("ARM: dts: tango4: Initial device trees") Signed-off-by: Marc Gonzalez Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 67b9a4f39279930b7105ef2b427bc36e44fd29b5 Author: Gregory CLEMENT Date: Wed Jul 12 13:23:11 2017 +0200 ARM: dts: armada-38x: Fix irq type for pca955 commit 8d4514173211586c6238629b1ef1e071927735f5 upstream. As written in the datasheet the PCA955 can only handle low level irq and not edge irq. Without this fix the interrupt is not usable for pca955: the gpio-pca953x driver already set the irq type as low level which is incompatible with edge type, then the kernel prevents using the interrupt: "irq: type mismatch, failed to map hwirq-18 for /soc/internal-regs/gpio@18100!" Fixes: 928413bd859c ("ARM: mvebu: Add Armada 388 General Purpose Development Board support") Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 8c5f902853fcece5b444c83027fe11045d372f27 Author: Gregory CLEMENT Date: Fri Jul 7 09:59:28 2017 +0200 ARM: mvebu: use __pa_symbol in the mv98dx3236 platform SMP code commit 76127d6fe00062bddb25515d8a4f44633c41fe14 upstream. As we already did for Armada XP switch from virt_to_phys() to __pa_symbol(). The reason for it was well explained by Mark Rutland so let's quote him: "virt_to_phys() is intended to operate on the linear/direct mapping of RAM. __pa_symbol() is intended to operate on the kernel mapping, which may not be in the linear/direct mapping on all architectures. e.g. arm64 and x86_64 map the kernel image and RAM separately. On 32-bit ARM the kernel image mapping is tied to the linear/direct mapping, so that works, but as it's semantically wrong (and broken for generic code), the DEBUG_VIRTUAL checks complain." Fixes: db88977894ab ("arm: mvebu: support for SMP on 98DX3336 SoC") Reviewed-by: Florian Fainelli Tested-by: Chris Packham Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit d74355838d88f692b04a18de0ed4d195af750fa9 Author: Maxime Ripard Date: Fri Jul 21 18:19:35 2017 +0200 clk: sunxi-ng: sun5i: Add clk_set_rate_parent to the CPU clock commit 9735ee9e3cc3ba113ac96b0368ef3f1a73092a23 upstream. The current CPU clock is missing the option to change the rate of its parents, leading to improper rates calculated by cpufreq, and eventually crashes. Fixes: 5e73761786d6 ("clk: sunxi-ng: Add sun5i CCU driver") Reported-by: Kevin Hilman Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Signed-off-by: Greg Kroah-Hartman commit eb6669b193cb439eba601ac3521c76891b2c39e8 Author: Harvey Hunt Date: Tue Jul 18 14:25:45 2017 +0100 MIPS: ralink: Fix build error due to missing header commit e3ccf1d1dee5129beb839fe05c61eb134131bdd6 upstream. Previously, was included before ralink_regs.h in all ralink files - leading to being implicitly included. After commit 26dd3e4ff9ac ("MIPS: Audit and remove any unnecessary uses of module.h") removed the inclusion of module.h from multiple places, some ralink platforms failed to build with the following error: In file included from arch/mips/ralink/mt7620.c:17:0: ./arch/mips/include/asm/mach-ralink/ralink_regs.h: In function ‘rt_sysc_w32’: ./arch/mips/include/asm/mach-ralink/ralink_regs.h:38:2: error: implicit declaration of function ‘__raw_writel’ [-Werror=implicit-function-declaration] __raw_writel(val, rt_sysc_membase + reg); ^ ./arch/mips/include/asm/mach-ralink/ralink_regs.h: In function ‘rt_sysc_r32’: ./arch/mips/include/asm/mach-ralink/ralink_regs.h:43:2: error: implicit declaration of function ‘__raw_readl’ [-Werror=implicit-function-declaration] return __raw_readl(rt_sysc_membase + reg); Fix this by including . Signed-off-by: Harvey Hunt Fixes: 26dd3e4ff9ac ("MIPS: Audit and remove any unnecessary uses of module.h") Cc: John Crispin Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/16780/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 038b5bff7c9ac105af87cabc4a95933a0b606a5b Author: Jerry Lee Date: Sun Aug 6 01:18:31 2017 -0400 ext4: fix overflow caused by missing cast in ext4_resize_fs() commit aec51758ce10a9c847a62a48a168f8c804c6e053 upstream. On a 32-bit platform, the value of n_blcoks_count may be wrong during the file system is resized to size larger than 2^32 blocks. This may caused the superblock being corrupted with zero blocks count. Fixes: 1c6bd7173d66 Signed-off-by: Jerry Lee Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 102106c91f1b04990230a5711964c356b5e513a0 Author: Jan Kara Date: Sat Aug 5 17:43:24 2017 -0400 ext4: fix SEEK_HOLE/SEEK_DATA for blocksize < pagesize commit fcf5ea10992fbac3c7473a1db33d56a139333cd1 upstream. ext4_find_unwritten_pgoff() does not properly handle a situation when starting index is in the middle of a page and blocksize < pagesize. The following command shows the bug on filesystem with 1k blocksize: xfs_io -f -c "falloc 0 4k" \ -c "pwrite 1k 1k" \ -c "pwrite 3k 1k" \ -c "seek -a -r 0" foo In this example, neither lseek(fd, 1024, SEEK_HOLE) nor lseek(fd, 2048, SEEK_DATA) will return the correct result. Fix the problem by neglecting buffers in a page before starting offset. Reported-by: Andreas Gruenbacher Signed-off-by: Theodore Ts'o Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 36af36b8ddf0cfa9291cacb7d52c0ab09ce7cef5 Author: Bartosz Golaszewski Date: Mon Jul 3 11:12:03 2017 +0200 gpiolib: skip unwanted events, don't convert them to opposite edge commit df1e76f28ffe87d1b065eecab2d0fbb89e6bdee5 upstream. The previous fix for filtering out of unwatched events was not entirely correct. Instead of skipping the events we don't want, they are now interpreted as events with opposing edge. In order to fix it: always read the GPIO line value on interrupt and only emit the event if it corresponds with the event type we requested. Fixes: ad537b822577 ("gpiolib: fix filtering out unwanted events") Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 9c944d1090651c6f75010574cfbbe03e045990f8 Author: Gregory CLEMENT Date: Tue Aug 1 18:01:35 2017 +0200 ARM64: dts: marvell: armada-37xx: Fix the number of GPIO on south bridge commit d7a65c4905bc9c304ecf3d8aa566802f6119480f upstream. The number of pins in South Bridge is 30 and not 29. There is a fix for the driver for the pinctrl, but a fix is also need at device tree level for the GPIO. Fixes: afda007feda5 ("ARM64: dts: marvell: Add pinctrl nodes for Armada 3700") Signed-off-by: Gregory CLEMENT Signed-off-by: Greg Kroah-Hartman commit 0cd0fb38780b3d068c1b2fd2c832f6bb5f4aae6c Author: Suravee Suthikulpanit Date: Wed Jul 5 21:29:59 2017 -0500 iommu/amd: Enable ga_log_intr when enabling guest_mode commit efe6f241602cb61466895f6816b8ea6b90f04d4e upstream. IRTE[GALogIntr] bit should set when enabling guest_mode, which enables IOMMU to generate entry in GALog when IRTE[IsRun] is not set, and send an interrupt to notify IOMMU driver. Signed-off-by: Suravee Suthikulpanit Cc: Joerg Roedel Fixes: d98de49a53e48 ('iommu/amd: Enable vAPIC interrupt remapping mode by default') Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit fe8cfa55ebc6778d52bf9c8ca58af0725da31bf6 Author: Nicholas Piggin Date: Tue Aug 1 23:59:28 2017 +1000 powerpc/64: Fix __check_irq_replay missing decrementer interrupt commit 3db40c312c2c1eb2187c5731102fa8ff380e6e40 upstream. If the decrementer wraps again and de-asserts the decrementer exception while hard-disabled, __check_irq_replay() has a test to notice the wrap when interrupts are re-enabled. The decrementer check must be done when clearing the PACA_IRQ_HARD_DIS flag, not when the PACA_IRQ_DEC flag is tested. Previously this worked because the decrementer interrupt was always the first one checked after clearing the hard disable flag, but HMI check was moved ahead of that, which introduced this bug. This can cause a missed decrementer interrupt if we soft-disable interrupts then take an HMI which is recorded in irq_happened, then hard-disable interrupts for > 4s to wrap the decrementer. Fixes: e0e0d6b7390b ("powerpc/64: Replay hypervisor maintenance interrupt first") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 16c05453c98a028974920088b2e406a9289d1789 Author: Gustavo Romero Date: Wed Jul 19 01:44:13 2017 -0400 powerpc/tm: Fix saving of TM SPRs in core dump commit cd63f3cf1d59b7ad8419eba1cac8f9126e79cc43 upstream. Currently flush_tmregs_to_thread() does not save the TM SPRs (TFHAR, TFIAR, TEXASR) to the thread struct, unless the process is currently inside a suspended transaction. If the process is core dumping, and the TM SPRs have changed since the last time the process was context switched, then we will save stale values of the TM SPRs to the core dump. Fix it by saving the live register state to the thread struct in that case. Fixes: 08e1c01d6aed ("powerpc/ptrace: Enable support for TM SPR state") Signed-off-by: Gustavo Romero Reviewed-by: Cyril Bur Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f38791c88526ba27f25f5c4aa932c0bcfad8cae7 Author: Matija Glavinic Pecotic Date: Tue Aug 1 09:11:52 2017 +0200 timers: Fix overflow in get_next_timer_interrupt commit 34f41c0316ed52b0b44542491d89278efdaa70e4 upstream. For e.g. HZ=100, timer being 430 jiffies in the future, and 32 bit unsigned int, there is an overflow on unsigned int right-hand side of the expression which results with wrong values being returned. Type cast the multiplier to 64bit to avoid that issue. Fixes: 46c8f0b077a8 ("timers: Fix get_next_timer_interrupt() computation") Signed-off-by: Matija Glavinic Pecotic Signed-off-by: Thomas Gleixner Reviewed-by: Alexander Sverdlin Cc: khilman@baylibre.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/a7900f04-2a21-c9fd-67be-ab334d459ee5@nokia.com Signed-off-by: Greg Kroah-Hartman commit c8ba45bfa68160d4c5de57cbb209ec87963757dc Author: Wanpeng Li Date: Tue Aug 1 05:20:03 2017 -0700 KVM: async_pf: make rcu irq exit if not triggered from idle task commit 337c017ccdf2653d0040099433fc1a2b1beb5926 upstream. WARNING: CPU: 5 PID: 1242 at kernel/rcu/tree_plugin.h:323 rcu_note_context_switch+0x207/0x6b0 CPU: 5 PID: 1242 Comm: unity-settings- Not tainted 4.13.0-rc2+ #1 RIP: 0010:rcu_note_context_switch+0x207/0x6b0 Call Trace: __schedule+0xda/0xba0 ? kvm_async_pf_task_wait+0x1b2/0x270 schedule+0x40/0x90 kvm_async_pf_task_wait+0x1cc/0x270 ? prepare_to_swait+0x22/0x70 do_async_page_fault+0x77/0xb0 ? do_async_page_fault+0x77/0xb0 async_page_fault+0x28/0x30 RIP: 0010:__d_lookup_rcu+0x90/0x1e0 I encounter this when trying to stress the async page fault in L1 guest w/ L2 guests running. Commit 9b132fbe5419 (Add rcu user eqs exception hooks for async page fault) adds rcu_irq_enter/exit() to kvm_async_pf_task_wait() to exit cpu idle eqs when needed, to protect the code that needs use rcu. However, we need to call the pair even if the function calls schedule(), as seen from the above backtrace. This patch fixes it by informing the RCU subsystem exit/enter the irq towards/away from idle for both n.halted and !n.halted. Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Paul E. McKenney Signed-off-by: Wanpeng Li Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit 0536ef5ee9650cec26bb3aeac9500dec04b0c01f Author: Suzuki K Poulose Date: Wed Jul 5 09:57:00 2017 +0100 KVM: arm/arm64: Handle hva aging while destroying the vm commit 7e5a672289c9754d07e1c3b33649786d3d70f5e4 upstream. The mmu_notifier_release() callback of KVM triggers cleaning up the stage2 page table on kvm-arm. However there could be other notifier callbacks in parallel with the mmu_notifier_release(), which could cause the call backs ending up in an empty stage2 page table. Make sure we check it for all the notifier callbacks. Fixes: commit 293f29363 ("kvm-arm: Unmap shadow pagetables properly") Reported-by: Alex Graf Reviewed-by: Christoffer Dall Signed-off-by: Suzuki K Poulose Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 908082f6bb1d2983a9a0d846e327da27c796bc7c Author: Banajit Goswami Date: Fri Jul 14 23:15:05 2017 -0700 ASoC: do not close shared backend dailink commit b1cd2e34c69a2f3988786af451b6e17967c293a0 upstream. Multiple frontend dailinks may be connected to a backend dailink at the same time. When one of frontend dailinks is closed, the associated backend dailink should not be closed if it is connected to other active frontend dailinks. Change ensures that backend dailink is closed only after all connected frontend dailinks are closed. Signed-off-by: Gopikrishnaiah Anandan Signed-off-by: Banajit Goswami Signed-off-by: Patrick Lai Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6c0bc495b2ac07ab42c02a92e7634ca1c6012ab0 Author: Johan Hovold Date: Wed Jul 12 17:55:30 2017 +0200 ASoC: ux500: Restore platform DAI assignments commit 651e9268fb9b9944e063d731b09c0d2ad339bedb upstream. This reverts commit f1013cdeeeb9 ("ASoC: ux500: drop platform DAI assignments"), which seems to have been based on a misunderstanding and prevents the platform driver callbacks from being made (e.g. to preallocate DMA memory). The real culprit for the warnings about attempts to create duplicate procfs entries was commit 99b04f4c4051 ("ASoC: add Component level pcm_new/pcm_free" that broke PCM creation on systems that use more than one platform component. Fixes: f1013cdeeeb9 ("ASoC: ux500: drop platform DAI assignments") Signed-off-by: Johan Hovold Reviewed-by: Linus Walleij Tested-by: Linus Walleij Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 045f833f265761e023c44e5f1951954a0ad531de Author: Johan Hovold Date: Wed Jul 12 17:55:29 2017 +0200 ASoC: fix pcm-creation regression commit c641e5b207ed7dfaa692820aeb5b6dde3de3e9b0 upstream. This reverts commit 99b04f4c4051 ("ASoC: add Component level pcm_new/pcm_free"), which started calling the pcm_new callback for every component in a *card* when creating a new pcm, something which does not seem to make any sense. This specifically led to memory leaks in systems with more than one platform component and where DMA memory is allocated in the platform-driver callback. For example, when both mcasp devices are being used on an am335x board, DMA memory would be allocated twice for every DAI link during probe. When CONFIG_SND_VERBOSE_PROCFS was set this fortunately also led to warnings such as: WARNING: CPU: 0 PID: 565 at ../fs/proc/generic.c:346 proc_register+0x110/0x154 proc_dir_entry 'sub0/prealloc' already registered Since there seems to be no users of the new component callbacks, and the current implementation introduced a regression, let's revert the offending commit for now. Fixes: 99b04f4c4051 ("ASoC: add Component level pcm_new/pcm_free") Signed-off-by: Johan Hovold Reviewed-by: Linus Walleij Tested-by: Linus Walleij Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit aff854f4e125b7db9c0583ebc1bbd02ec132669b Author: Jean Delvare Date: Sun Jul 30 10:18:25 2017 +0200 drm/amdgpu: Fix undue fallthroughs in golden registers initialization commit 5694785cf09bf0e7bd8e5f62361ea34fa162a4a0 upstream. As I was staring at the si_init_golden_registers code, I noticed that the Pitcairn initialization silently falls through the Cape Verde initialization, and the Oland initialization falls through the Hainan initialization. However there is no comment stating that this is intentional, and the radeon driver doesn't have any such fallthrough, so I suspect this is not supposed to happen. Signed-off-by: Jean Delvare Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Cc: Ken Wang Cc: Alex Deucher Cc: "Marek Olšák" Cc: "Christian König" Cc: Flora Cui Reviewed-by: Marek Olšák Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit bf8afa46d7014f1a0c0afa9ad49bd37bbfff948c Author: Alex Deucher Date: Wed Jul 26 22:10:53 2017 -0400 drm/amdgpu: fix header on gfx9 clear state commit c471e70b187e62efc77bcdf6f58795907f8f4851 upstream. This got missed when we open sourced this. Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c92f6a0ef97b2430a31f4311027f3f53fc2bd96e Author: Sergei A. Trusov Date: Wed Aug 2 20:23:48 2017 +1000 ALSA: hda - Fix speaker output from VAIO VPCL14M1R commit 3f3c371421e601fa93b6cb7fb52da9ad59ec90b4 upstream. Sony VAIO VPCL14M1R needs the quirk to make the speaker working properly. Tested-by: Dmitriy Signed-off-by: Sergei A. Trusov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c809d5e806fed18798a3a7f95bdc58acc3d700de Author: Jan Kara Date: Wed Aug 2 13:32:30 2017 -0700 ocfs2: don't clear SGID when inheriting ACLs commit 19ec8e48582670c021e998b9deb88e39a842ff45 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of ocfs2_set_acl() into ocfs2_iop_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Also posix_acl_chmod() that is calling ocfs2_set_acl() takes care of updating mode itself. Fixes: 073931017b4 ("posix_acl: Clear SGID bit when setting file permissions") Link: http://lkml.kernel.org/r/20170801141252.19675-3-jack@suse.cz Signed-off-by: Jan Kara Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 05d723c96d2a41c980b2ac00356f2faab32b0b63 Author: Dima Zavin Date: Wed Aug 2 13:32:18 2017 -0700 cpuset: fix a deadlock due to incomplete patching of cpusets_enabled() commit 89affbf5d9ebb15c6460596822e8857ea2f9e735 upstream. In codepaths that use the begin/retry interface for reading mems_allowed_seq with irqs disabled, there exists a race condition that stalls the patch process after only modifying a subset of the static_branch call sites. This problem manifested itself as a deadlock in the slub allocator, inside get_any_partial. The loop reads mems_allowed_seq value (via read_mems_allowed_begin), performs the defrag operation, and then verifies the consistency of mem_allowed via the read_mems_allowed_retry and the cookie returned by xxx_begin. The issue here is that both begin and retry first check if cpusets are enabled via cpusets_enabled() static branch. This branch can be rewritted dynamically (via cpuset_inc) if a new cpuset is created. The x86 jump label code fully synchronizes across all CPUs for every entry it rewrites. If it rewrites only one of the callsites (specifically the one in read_mems_allowed_retry) and then waits for the smp_call_function(do_sync_core) to complete while a CPU is inside the begin/retry section with IRQs off and the mems_allowed value is changed, we can hang. This is because begin() will always return 0 (since it wasn't patched yet) while retry() will test the 0 against the actual value of the seq counter. The fix is to use two different static keys: one for begin (pre_enable_key) and one for retry (enable_key). In cpuset_inc(), we first bump the pre_enable key to ensure that cpuset_mems_allowed_begin() always return a valid seqcount if are enabling cpusets. Similarly, when disabling cpusets via cpuset_dec(), we first ensure that callers of cpuset_mems_allowed_retry() will start ignoring the seqcount value before we let cpuset_mems_allowed_begin() return 0. The relevant stack traces of the two stuck threads: CPU: 1 PID: 1415 Comm: mkdir Tainted: G L 4.9.36-00104-g540c51286237 #4 Hardware name: Default string Default string/Hardware, BIOS 4.29.1-20170526215256 05/26/2017 task: ffff8817f9c28000 task.stack: ffffc9000ffa4000 RIP: smp_call_function_many+0x1f9/0x260 Call Trace: smp_call_function+0x3b/0x70 on_each_cpu+0x2f/0x90 text_poke_bp+0x87/0xd0 arch_jump_label_transform+0x93/0x100 __jump_label_update+0x77/0x90 jump_label_update+0xaa/0xc0 static_key_slow_inc+0x9e/0xb0 cpuset_css_online+0x70/0x2e0 online_css+0x2c/0xa0 cgroup_apply_control_enable+0x27f/0x3d0 cgroup_mkdir+0x2b7/0x420 kernfs_iop_mkdir+0x5a/0x80 vfs_mkdir+0xf6/0x1a0 SyS_mkdir+0xb7/0xe0 entry_SYSCALL_64_fastpath+0x18/0xad ... CPU: 2 PID: 1 Comm: init Tainted: G L 4.9.36-00104-g540c51286237 #4 Hardware name: Default string Default string/Hardware, BIOS 4.29.1-20170526215256 05/26/2017 task: ffff8818087c0000 task.stack: ffffc90000030000 RIP: int3+0x39/0x70 Call Trace: <#DB> ? ___slab_alloc+0x28b/0x5a0 ? copy_process.part.40+0xf7/0x1de0 __slab_alloc.isra.80+0x54/0x90 copy_process.part.40+0xf7/0x1de0 copy_process.part.40+0xf7/0x1de0 kmem_cache_alloc_node+0x8a/0x280 copy_process.part.40+0xf7/0x1de0 _do_fork+0xe7/0x6c0 _raw_spin_unlock_irq+0x2d/0x60 trace_hardirqs_on_caller+0x136/0x1d0 entry_SYSCALL_64_fastpath+0x5/0xad do_syscall_64+0x27/0x350 SyS_clone+0x19/0x20 do_syscall_64+0x60/0x350 entry_SYSCALL64_slow_path+0x25/0x25 Link: http://lkml.kernel.org/r/20170731040113.14197-1-dmitriyz@waymo.com Fixes: 46e700abc44c ("mm, page_alloc: remove unnecessary taking of a seqlock when cpusets are disabled") Signed-off-by: Dima Zavin Reported-by: Cliff Spradlin Acked-by: Vlastimil Babka Cc: Peter Zijlstra Cc: Christopher Lameter Cc: Li Zefan Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d632c44dc720d6a3b0ad7c66d0c486e9ea300d2c Author: Mike Rapoport Date: Wed Aug 2 13:32:24 2017 -0700 userfaultfd: non-cooperative: flush event_wqh at release time commit 5a18b64e3f02125be1c0ef777501ae38aafe2a24 upstream. There may still be threads waiting on event_wqh at the time the userfault file descriptor is closed. Flush the events wait-queue to prevent waiting threads from hanging. Link: http://lkml.kernel.org/r/1501398127-30419-1-git-send-email-rppt@linux.vnet.ibm.com Fixes: 9cd75c3cd4c3d ("userfaultfd: non-cooperative: add ability to report non-PF events from uffd descriptor") Signed-off-by: Mike Rapoport Cc: Andrea Arcangeli Cc: "Dr. David Alan Gilbert" Cc: Pavel Emelyanov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 57f793272176f251e73f90a7f421972349fe9631 Author: Mike Rapoport Date: Wed Aug 2 13:32:15 2017 -0700 userfaultfd_zeropage: return -ENOSPC in case mm has gone commit 9d95aa4bada24be35bb94827a55e1d6e243d866e upstream. In the non-cooperative userfaultfd case, the process exit may race with outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC instead of -EINVAL when mm is already gone will allow uffd monitor to distinguish this case from other error conditions. Unfortunately I overlooked userfaultfd_zeropage when updating userfaultd_copy(). Link: http://lkml.kernel.org/r/1501136819-21857-1-git-send-email-rppt@linux.vnet.ibm.com Fixes: 96333187ab162 ("userfaultfd_copy: return -ENOSPC in case mm has gone") Signed-off-by: Mike Rapoport Cc: Andrea Arcangeli Cc: "Dr. David Alan Gilbert" Cc: Pavel Emelyanov Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit eea474f88ca0986e0a64a225308681a2e93dd5db Author: Mike Rapoport Date: Wed Aug 2 13:31:55 2017 -0700 userfaultfd: non-cooperative: notify about unmap of destination during mremap commit b22823719302e88d0e2a6bb06433bd97b175a8d8 upstream. When mremap is called with MREMAP_FIXED it unmaps memory at the destination address without notifying userfaultfd monitor. If the destination were registered with userfaultfd, the monitor has no way to distinguish between the old and new ranges and to properly relate the page faults that would occur in the destination region. Fixes: 897ab3e0c49e ("userfaultfd: non-cooperative: add event for memory unmaps") Link: http://lkml.kernel.org/r/1500276876-3350-1-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by: Mike Rapoport Acked-by: Pavel Emelyanov Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2a7002bade9ad69e03d5b3ff86cdca6cb0b5d8a7 Author: Daniel Jordan Date: Wed Aug 2 13:31:47 2017 -0700 mm/hugetlb.c: __get_user_pages ignores certain follow_hugetlb_page errors commit 2be7cfed995e25de1ffaffe14cc065b7ffb528e0 upstream. Commit 9a291a7c9428 ("mm/hugetlb: report -EHWPOISON not -EFAULT when FOLL_HWPOISON is specified") causes __get_user_pages to ignore certain errors from follow_hugetlb_page. After such error, __get_user_pages subsequently calls faultin_page on the same VMA and start address that follow_hugetlb_page failed on instead of returning the error immediately as it should. In follow_hugetlb_page, when hugetlb_fault returns a value covered under VM_FAULT_ERROR, follow_hugetlb_page returns it without setting nr_pages to 0 as __get_user_pages expects in this case, which causes the following to happen in __get_user_pages: the "while (nr_pages)" check succeeds, we skip the "if (!vma..." check because we got a VMA the last time around, we find no page with follow_page_mask, and we call faultin_page, which calls hugetlb_fault for the second time. This issue also slightly changes how __get_user_pages works. Before, it only returned error if it had made no progress (i = 0). But now, follow_hugetlb_page can clobber "i" with an error code since its new return path doesn't check for progress. So if "i" is nonzero before a failing call to follow_hugetlb_page, that indication of progress is lost and __get_user_pages can return error even if some pages were successfully pinned. To fix this, change follow_hugetlb_page so that it updates nr_pages, allowing __get_user_pages to fail immediately and restoring the "error only if no progress" behavior to __get_user_pages. Tested that __get_user_pages returns when expected on error from hugetlb_fault in follow_hugetlb_page. Fixes: 9a291a7c9428 ("mm/hugetlb: report -EHWPOISON not -EFAULT when FOLL_HWPOISON is specified") Link: http://lkml.kernel.org/r/1500406795-58462-1-git-send-email-daniel.m.jordan@oracle.com Signed-off-by: Daniel Jordan Acked-by: Punit Agrawal Cc: Andrea Arcangeli Cc: "Aneesh Kumar K.V" Cc: Gerald Schaefer Cc: James Morse Cc: "Kirill A. Shutemov" Cc: Michal Hocko Cc: Mike Kravetz Cc: Naoya Horiguchi Cc: zhong jiang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bd081d335910bc5a67000f12c94d2951a013e67f Author: Mel Gorman Date: Wed Aug 2 13:31:52 2017 -0700 mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries commit 3ea277194daaeaa84ce75180ec7c7a2075027a68 upstream. Nadav Amit identified a theoritical race between page reclaim and mprotect due to TLB flushes being batched outside of the PTL being held. He described the race as follows: CPU0 CPU1 ---- ---- user accesses memory using RW PTE [PTE now cached in TLB] try_to_unmap_one() ==> ptep_get_and_clear() ==> set_tlb_ubc_flush_pending() mprotect(addr, PROT_READ) ==> change_pte_range() ==> [ PTE non-present - no flush ] user writes using cached RW PTE ... try_to_unmap_flush() The same type of race exists for reads when protecting for PROT_NONE and also exists for operations that can leave an old TLB entry behind such as munmap, mremap and madvise. For some operations like mprotect, it's not necessarily a data integrity issue but it is a correctness issue as there is a window where an mprotect that limits access still allows access. For munmap, it's potentially a data integrity issue although the race is massive as an munmap, mmap and return to userspace must all complete between the window when reclaim drops the PTL and flushes the TLB. However, it's theoritically possible so handle this issue by flushing the mm if reclaim is potentially currently batching TLB flushes. Other instances where a flush is required for a present pte should be ok as either the page lock is held preventing parallel reclaim or a page reference count is elevated preventing a parallel free leading to corruption. In the case of page_mkclean there isn't an obvious path that userspace could take advantage of without using the operations that are guarded by this patch. Other users such as gup as a race with reclaim looks just at PTEs. huge page variants should be ok as they don't race with reclaim. mincore only looks at PTEs. userfault also should be ok as if a parallel reclaim takes place, it will either fault the page back in or read some of the data before the flush occurs triggering a fault. Note that a variant of this patch was acked by Andy Lutomirski but this was for the x86 parts on top of his PCID work which didn't make the 4.13 merge window as expected. His ack is dropped from this version and there will be a follow-on patch on top of PCID that will include his ack. [akpm@linux-foundation.org: tweak comments] [akpm@linux-foundation.org: fix spello] Link: http://lkml.kernel.org/r/20170717155523.emckq2esjro6hf3z@suse.de Reported-by: Nadav Amit Signed-off-by: Mel Gorman Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3ff112f5afa2b886d0585d2ed928b923d4ecd7cc Author: David Woods Date: Fri May 26 17:53:20 2017 -0400 mmc: dw_mmc: Use device_property_read instead of of_property_read commit 852ff5fea9eb6a9799f1881d6df2cd69a9e6eed5 upstream. Using the device_property interfaces allows the dw_mmc driver to work on platforms which run on either device tree or ACPI. Signed-off-by: David Woods Reviewed-by: Chris Metcalf Acked-by: Jaehoon Chung Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7386cdc97eb0988ca160ede8c38a6482bdea9b7d Author: David Woods Date: Fri May 26 17:53:21 2017 -0400 mmc: core: Use device_property_read instead of of_property_read commit 73a47a9bb3e2c4a9c553c72456e63ab991b1a4d9 upstream. Using the device_property interfaces allows mmc drivers to work on platforms which run on either device tree or ACPI. Signed-off-by: David Woods Reviewed-by: Chris Metcalf Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 43f799ab1f7290cff684806875ac6ec8dac9686a Author: Ludovic Desroches Date: Wed Jul 26 16:02:46 2017 +0200 mmc: sdhci-of-at91: force card detect value for non removable devices commit 7a1e3f143176e8ebdb2f5a9b3b47abc18b879d90 upstream. When the device is non removable, the card detect signal is often used for another purpose i.e. muxed to another SoC peripheral or used as a GPIO. It could lead to wrong behaviors depending the default value of this signal if not muxed to the SDHCI controller. Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC") Signed-off-by: Ludovic Desroches Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 870a2401cc91586f1c87f6311f87a3bc8f53b1d2 Author: Trond Myklebust Date: Tue Aug 1 16:02:47 2017 -0400 NFSv4: Fix EXCHANGE_ID corrupt verifier issue commit fd40559c8657418385e42f797e0b04bfc0add748 upstream. The verifier is allocated on the stack, but the EXCHANGE_ID RPC call was changed to be asynchronous by commit 8d89bd70bc939. If we interrrupt the call to rpc_wait_for_completion_task(), we can therefore end up transmitting random stack contents in lieu of the verifier. Fixes: 8d89bd70bc939 ("NFS setup async exchange_id") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit f0609ce459c92ea7d046b7cfac594104c2bec458 Author: Arend Van Spriel Date: Wed Jul 26 13:09:24 2017 +0100 brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice commit 5f5d03143de5e0c593da4ab18fc6393c2815e108 upstream. Due to a bugfix in wireless tree and the commit mentioned below a merge was needed which went haywire. So the submitted change resulted in the function brcmf_sdiod_sgtable_alloc() being called twice during the probe thus leaking the memory of the first call. Fixes: 4d7928959832 ("brcmfmac: switch to new platform data") Reported-by: Stefan Wahren Tested-by: Stefan Wahren Reviewed-by: Hante Meuleman Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit a36e744105bad9b31e362e40a7cdcda02d7e2466 Author: Emmanuel Grumbach Date: Thu Jun 8 10:55:26 2017 +0300 iwlwifi: dvm: prevent an out of bounds access commit 0b0f934e92a8eaed2e6c48a50eae6f84661f74f3 upstream. iwlagn_check_ratid_empty takes the tid as a parameter, but it doesn't check that it is not IWL_TID_NON_QOS. Since IWL_TID_NON_QOS = 8 and iwl_priv::tid_data is an array with 8 entries, accessing iwl_priv::tid_data[IWL_TID_NON_QOS] is a bad idea. This happened in iwlagn_rx_reply_tx. Since iwlagn_check_ratid_empty is relevant only to check whether we can open A-MPDU, this flow is irrelevant if tid is IWL_TID_NON_QOS. Call iwlagn_check_ratid_empty only inside the if (tid != IWL_TID_NON_QOS) a few lines earlier in the function. Reported-by: Seraphime Kirkovski Tested-by: Seraphime Kirkovski Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 387b91879cdb8a5bdfd33ca6845bddc20b95de0b Author: Tejun Heo Date: Tue Jul 18 18:41:52 2017 -0400 workqueue: restore WQ_UNBOUND/max_active==1 to be ordered commit 5c0338c68706be53b3dc472e4308961c36e4ece1 upstream. The combination of WQ_UNBOUND and max_active == 1 used to imply ordered execution. After NUMA affinity 4c16bd327c74 ("workqueue: implement NUMA affinity for unbound workqueues"), this is no longer true due to per-node worker pools. While the right way to create an ordered workqueue is alloc_ordered_workqueue(), the documentation has been misleading for a long time and people do use WQ_UNBOUND and max_active == 1 for ordered workqueues which can lead to subtle bugs which are very difficult to trigger. It's unlikely that we'd see noticeable performance impact by enforcing ordering on WQ_UNBOUND / max_active == 1 workqueues. Let's automatically set __WQ_ORDERED for those workqueues. Signed-off-by: Tejun Heo Reported-by: Christoph Hellwig Reported-by: Alexei Potashnik Fixes: 4c16bd327c74 ("workqueue: implement NUMA affinity for unbound workqueues") Signed-off-by: Greg Kroah-Hartman commit b1f866f1b7b6c46a1269766dfb6672f454fbc172 Author: Dan Carpenter Date: Wed Jul 19 13:06:41 2017 +0300 libata: array underflow in ata_find_dev() commit 59a5e266c3f5c1567508888dd61a45b86daed0fa upstream. My static checker complains that "devno" can be negative, meaning that we read before the start of the loop. I've looked at the code, and I think the warning is right. This come from /proc so it's root only or it would be quite a quite a serious bug. The call tree looks like this: proc_scsi_write() <- gets id and channel from simple_strtoul() -> scsi_add_single_device() <- calls shost->transportt->user_scan() -> ata_scsi_user_scan() -> ata_find_dev() Signed-off-by: Dan Carpenter Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit d4f197159d1029ef723f595a65975cd682605094 Author: Tejun Heo Date: Sun Jul 23 08:14:15 2017 -0400 cgroup: fix error return value from cgroup_subtree_control() commit 3c74541777302eec43a0d1327c4d58b8659a776b upstream. While refactoring, f7b2814bb9b6 ("cgroup: factor out cgroup_{apply|finalize}_control() from cgroup_subtree_control_write()") broke error return value from the function. The return value from the last operation is always overridden to zero. Fix it. Signed-off-by: Tejun Heo Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 7d453afc2ec5eb97596a60f9490df692c1abd222 Author: Tejun Heo Date: Tue Jul 18 17:57:46 2017 -0400 cgroup: create dfl_root files on subsys registration commit 7af608e4f9530372aec6e940552bf76595f2e265 upstream. On subsystem registration, css_populate_dir() is not called on the new root css, so the interface files for the subsystem on cgrp_dfl_root aren't created on registration. This is a residue from the days when cgrp_dfl_root was used only as the parking spot for unused subsystems, which no longer is true as it's used as the root for cgroup2. This is often fine as later operations tend to create them as a part of mount (cgroup1) or subtree_control operations (cgroup2); however, it's not difficult to mount cgroup2 with the controller interface files missing as Waiman found out. Fix it by invoking css_populate_dir() on the root css on subsys registration. Signed-off-by: Tejun Heo Reported-and-tested-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 01563d03bd483afdd0cc1b14df06d0af5cef6625 Author: Tejun Heo Date: Sat Jul 8 07:17:02 2017 -0400 cgroup: don't call migration methods if there are no tasks to migrate commit 610467270fb368584b74567edd21c8cc5104490f upstream. Subsystem migration methods shouldn't be called for empty migrations. cgroup_migrate_execute() implements this guarantee by bailing early if there are no source css_sets. This used to be correct before a79a908fd2b0 ("cgroup: introduce cgroup namespaces"), but no longer since the commit because css_sets can stay pinned without tasks in them. This caused cgroup_migrate_execute() call into cpuset migration methods with an empty cgroup_taskset. cpuset migration methods correctly assume that cgroup_taskset_first() never returns NULL; however, due to the bug, it can, leading to the following oops. Unable to handle kernel paging request for data at address 0x00000960 Faulting instruction address: 0xc0000000001d6868 Oops: Kernel access of bad area, sig: 11 [#1] ... CPU: 14 PID: 16947 Comm: kworker/14:0 Tainted: G W 4.12.0-rc4-next-20170609 #2 Workqueue: events cpuset_hotplug_workfn task: c00000000ca60580 task.stack: c00000000c728000 NIP: c0000000001d6868 LR: c0000000001d6858 CTR: c0000000001d6810 REGS: c00000000c72b720 TRAP: 0300 Tainted: GW (4.12.0-rc4-next-20170609) MSR: 8000000000009033 CR: 44722422 XER: 20000000 CFAR: c000000000008710 DAR: 0000000000000960 DSISR: 40000000 SOFTE: 1 GPR00: c0000000001d6858 c00000000c72b9a0 c000000001536e00 0000000000000000 GPR04: c00000000c72b9c0 0000000000000000 c00000000c72bad0 c000000766367678 GPR08: c000000766366d10 c00000000c72b958 c000000001736e00 0000000000000000 GPR12: c0000000001d6810 c00000000e749300 c000000000123ef8 c000000775af4180 GPR16: 0000000000000000 0000000000000000 c00000075480e9c0 c00000075480e9e0 GPR20: c00000075480e8c0 0000000000000001 0000000000000000 c00000000c72ba20 GPR24: c00000000c72baa0 c00000000c72bac0 c000000001407248 c00000000c72ba20 GPR28: c00000000141fc80 c00000000c72bac0 c00000000c6bc790 0000000000000000 NIP [c0000000001d6868] cpuset_can_attach+0x58/0x1b0 LR [c0000000001d6858] cpuset_can_attach+0x48/0x1b0 Call Trace: [c00000000c72b9a0] [c0000000001d6858] cpuset_can_attach+0x48/0x1b0 (unreliable) [c00000000c72ba00] [c0000000001cbe80] cgroup_migrate_execute+0xb0/0x450 [c00000000c72ba80] [c0000000001d3754] cgroup_transfer_tasks+0x1c4/0x360 [c00000000c72bba0] [c0000000001d923c] cpuset_hotplug_workfn+0x86c/0xa20 [c00000000c72bca0] [c00000000011aa44] process_one_work+0x1e4/0x580 [c00000000c72bd30] [c00000000011ae78] worker_thread+0x98/0x5c0 [c00000000c72bdc0] [c000000000124058] kthread+0x168/0x1b0 [c00000000c72be30] [c00000000000b2e8] ret_from_kernel_thread+0x5c/0x74 Instruction dump: f821ffa1 7c7d1b78 60000000 60000000 38810020 7fa3eb78 3f42ffed 4bff4c25 60000000 3b5a0448 3d420020 eb610020 7f43d378 e9290000 f92af200 ---[ end trace dcaaf98fb36d9e64 ]--- This patch fixes the bug by adding an explicit nr_tasks counter to cgroup_taskset and skipping calling the migration methods if the counter is zero. While at it, remove the now spurious check on no source css_sets. Signed-off-by: Tejun Heo Reported-and-tested-by: Abdul Haleem Cc: Roman Gushchin Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces") Link: http://lkml.kernel.org/r/1497266622.15415.39.camel@abdul.in.ibm.com Signed-off-by: Greg Kroah-Hartman commit e54f1632ce5fc82b2bb6f1c0165f07666de656e1 Author: Hans de Goede Date: Thu Jul 6 18:49:27 2017 +0200 ACPI / LPSS: Only call pwm_add_table() for the first PWM controller commit dd242a080d178c36442a0bb28b6acf6f126d0569 upstream. At least on the UP board SBC both PWMs are enabled leading to us trying to add the same pwm_lookup twice, which leads to the following: [ 0.902224] list_add double add: new=ffffffffb8efd400, prev=ffffffffb8efd400, next=ffffffffb8eeede0. [ 0.912466] ------------[ cut here ]------------ [ 0.917624] kernel BUG at lib/list_debug.c:31! [ 0.922588] invalid opcode: 0000 [#1] SMP ... [ 1.027450] Call Trace: [ 1.030185] pwm_add_table+0x4c/0x90 [ 1.034181] bsw_pwm_setup+0x1a/0x20 [ 1.038175] acpi_lpss_create_device+0xfe/0x420 ... This commit fixes this by only calling pwm_add_table() for the first PWM controller (which is the one used for the backlight). Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458599 Fixes: bf7696a12071 (acpi: lpss: call pwm_add_table() for BSW...) Fixes: 04434ab5120a (ACPI / LPSS: Call pwm_add_table() for Bay Trail...) Signed-off-by: Hans de Goede Acked-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 49f4ca2f720d39d2af553bd355c1dd4e36f83de8 Author: Arnd Bergmann Date: Fri Jul 21 22:53:46 2017 +0200 scsi: lpfc: fix linking against modular NVMe support commit cd069bb9f9ff13b23492fda6ccdb458ac4f641ca upstream. When LPFC is built-in but NVMe is a loadable module, we fail to link the kernel: drivers/scsi/built-in.o: In function `lpfc_nvme_create_localport': (.text+0x156a82): undefined reference to `nvme_fc_register_localport' drivers/scsi/built-in.o: In function `lpfc_nvme_destroy_localport': (.text+0x156eaa): undefined reference to `nvme_fc_unregister_remoteport' We can avoid this either by forcing lpfc to be a module, or by disabling NVMe support in this case. This implements the former. Fixes: 7d7080335f8d ("scsi: lpfc: Finalize Kconfig options for nvme") Link: https://patchwork.kernel.org/patch/9636569/ Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit e7ed1b9d6f03c0c1e0c78160af459e148978b6e3 Author: John David Anglin Date: Sun Jul 30 16:20:19 2017 -0400 parisc: Handle vma's whose context is not current in flush_cache_range commit 13d57093c141db2036364d6be35e394fc5b64728 upstream. In testing James' patch to drivers/parisc/pdc_stable.c, I hit the BUG statement in flush_cache_range() during a system shutdown: kernel BUG at arch/parisc/kernel/cache.c:595! CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1 Workqueue: events free_ioctx IAOQ[0]: flush_cache_range+0x144/0x148 IAOQ[1]: flush_cache_page+0x0/0x1a8 RP(r2): flush_cache_range+0xec/0x148 Backtrace: [<00000000402910ac>] unmap_page_range+0x84/0x880 [<00000000402918f4>] unmap_single_vma+0x4c/0x60 [<0000000040291a18>] zap_page_range_single+0x110/0x160 [<0000000040291c34>] unmap_mapping_range+0x174/0x1a8 [<000000004026ccd8>] truncate_pagecache+0x50/0xa8 [<000000004026cd84>] truncate_setsize+0x54/0x70 [<000000004033d534>] put_aio_ring_file+0x44/0xb0 [<000000004033d5d8>] aio_free_ring+0x38/0x140 [<000000004033d714>] free_ioctx+0x34/0xa8 [<00000000401b0028>] process_one_work+0x1b8/0x4d0 [<00000000401b04f4>] worker_thread+0x1b4/0x648 [<00000000401b9128>] kthread+0x1b0/0x208 [<0000000040150020>] end_fault_vector+0x20/0x28 [<0000000040639518>] nf_ip_reroute+0x50/0xa8 [<0000000040638ed0>] nf_ip_route+0x10/0x78 [<0000000040638c90>] xfrm4_mode_tunnel_input+0x180/0x1f8 CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1 Workqueue: events free_ioctx Backtrace: [<0000000040163bf0>] show_stack+0x20/0x38 [<0000000040688480>] dump_stack+0xa8/0x120 [<0000000040163dc4>] die_if_kernel+0x19c/0x2b0 [<0000000040164d0c>] handle_interruption+0xa24/0xa48 This patch modifies flush_cache_range() to handle non current contexts. In as much as this occurs infrequently, the simplest approach is to flush the entire cache when this happens. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit fea9ea4fef5c879eec01401df7cdd6a21a127dc1 Author: Helge Deller Date: Mon Jul 31 08:38:27 2017 +0200 parisc: Increase thread and stack size to 32kb commit 8f8201dfed91a43ac38c899c82f81eef3d36afd9 upstream. Since kernel 4.11 the thread and irq stacks on parisc randomly overflow the default size of 16k. The reason why stack usage suddenly grew is yet unknown. Signed-off-by: Helge Deller Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman