commit af04fe4623d208bc78d2396059b838d8847a87ad Author: Alexandre Frade Date: Wed Jan 29 23:48:46 2020 -0300 5.4.16-xanmod9 Signed-off-by: Alexandre Frade commit 76c5fdb7fa00f5a0114aadc5e2b604f8e7cfbd73 Merge: c9d53db71b2f 60b6aa2b71ef Author: Alexandre Frade Date: Wed Jan 29 23:48:21 2020 -0300 Merge tag 'v5.4.16' into 5.4 This is the 5.4.16 stable release commit c9d53db71b2fb2258396bd25c66ff432f41308e5 Author: Ben Hutchings Date: Wed Mar 16 03:17:06 2011 +0000 sched: Do not enable autogrouping by default We want to provide the option of autogrouping but without enabling it by default yet. commit 60b6aa2b71efa7e0bd5393ce292ace4a0cf2e71b Author: Greg Kroah-Hartman Date: Wed Jan 29 16:45:34 2020 +0100 Linux 5.4.16 commit d8a11e0f4e26f033a217a24617c11bcd24b8f65a Author: Martin Schiller Date: Thu Jan 9 07:31:14 2020 +0100 net/x25: fix nonblocking connect commit e21dba7a4df4d93da237da65a096084b4f2e87b4 upstream. This patch fixes 2 issues in x25_connect(): 1. It makes absolutely no sense to reset the neighbour and the connection state after a (successful) nonblocking call of x25_connect. This prevents any connection from being established, since the response (call accept) cannot be processed. 2. Any further calls to x25_connect() while a call is pending should simply return, instead of creating new Call Request (on different logical channels). This patch should also fix the "KASAN: null-ptr-deref Write in x25_connect" and "BUG: unable to handle kernel NULL pointer dereference in x25_connect" bugs reported by syzbot. Signed-off-by: Martin Schiller Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ce75dd3abbc8f1be531ac5de559d59df9098020c Author: Pablo Neira Ayuso Date: Tue Jan 21 16:48:03 2020 +0100 netfilter: nf_tables: autoload modules from the abort path commit eb014de4fd418de1a277913cba244e47274fe392 upstream. This patch introduces a list of pending module requests. This new module list is composed of nft_module_request objects that contain the module name and one status field that tells if the module has been already loaded (the 'done' field). In the first pass, from the preparation phase, the netlink command finds that a module is missing on this list. Then, a module request is allocated and added to this list and nft_request_module() returns -EAGAIN. This triggers the abort path with the autoload parameter set on from nfnetlink, request_module() is called and the module request enters the 'done' state. Since the mutex is released when loading modules from the abort phase, the module list is zapped so this is iteration occurs over a local list. Therefore, the request_module() calls happen when object lists are in consistent state (after fulling aborting the transaction) and the commit list is empty. On the second pass, the netlink command will find that it already tried to load the module, so it does not request it again and nft_request_module() returns 0. Then, there is a look up to find the object that the command was missing. If the module was successfully loaded, the command proceeds normally since it finds the missing object in place, otherwise -ENOENT is reported to userspace. This patch also updates nfnetlink to include the reason to enter the abort phase, which is required for this new autoload module rationale. Fixes: ec7470b834fe ("netfilter: nf_tables: store transaction list locally while requesting module") Reported-by: syzbot+29125d208b3dae9a7019@syzkaller.appspotmail.com Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 07ac418120aed1d8bb98f36b9bc17460ce37a036 Author: Pablo Neira Ayuso Date: Tue Jan 21 16:07:00 2020 +0100 netfilter: nf_tables: add __nft_chain_type_get() commit 826035498ec14b77b62a44f0cb6b94d45530db6f upstream. This new helper function validates that unknown family and chain type coming from userspace do not trigger an out-of-bound array access. Bail out in case __nft_chain_type_get() returns NULL from nft_chain_parse_hook(). Fixes: 9370761c56b6 ("netfilter: nf_tables: convert built-in tables/chains to chain types") Reported-by: syzbot+156a04714799b1d480bc@syzkaller.appspotmail.com Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit ea52197c9c4b9e1722e4ec0b798e1ab3744dd5a2 Author: Kadlecsik József Date: Sun Jan 19 22:06:49 2020 +0100 netfilter: ipset: use bitmap infrastructure completely commit 32c72165dbd0e246e69d16a3ad348a4851afd415 upstream. The bitmap allocation did not use full unsigned long sizes when calculating the required size and that was triggered by KASAN as slab-out-of-bounds read in several places. The patch fixes all of them. Reported-by: syzbot+fabca5cbf5e54f3fe2de@syzkaller.appspotmail.com Reported-by: syzbot+827ced406c9a1d9570ed@syzkaller.appspotmail.com Reported-by: syzbot+190d63957b22ef673ea5@syzkaller.appspotmail.com Reported-by: syzbot+dfccdb2bdb4a12ad425e@syzkaller.appspotmail.com Reported-by: syzbot+df0d0f5895ef1f41a65b@syzkaller.appspotmail.com Reported-by: syzbot+b08bd19bb37513357fd4@syzkaller.appspotmail.com Reported-by: syzbot+53cdd0ec0bbabd53370a@syzkaller.appspotmail.com Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit d5fd8ac3fcc52dce384c54130a56e13719b2eaeb Author: Hans Verkuil Date: Sun Nov 10 07:27:04 2019 +0100 media: v4l2-ioctl.c: zero reserved fields for S/TRY_FMT commit ee8951e56c0f960b9621636603a822811cef3158 upstream. v4l2_vbi_format, v4l2_sliced_vbi_format and v4l2_sdr_format have a reserved array at the end that should be zeroed by drivers as per the V4L2 spec. Older drivers often do not do this, so just handle this in the core. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 40b1747b03684f03827b6323a17e4aa67af1e307 Author: Wen Huang Date: Thu Nov 28 18:51:04 2019 +0800 libertas: Fix two buffer overflows at parsing bss descriptor commit e5e884b42639c74b5b57dc277909915c0aefc8bb upstream. add_ie_rates() copys rates without checking the length in bss descriptor from remote AP.when victim connects to remote attacker, this may trigger buffer overflow. lbs_ibss_join_existing() copys rates without checking the length in bss descriptor from remote IBSS node.when victim connects to remote attacker, this may trigger buffer overflow. Fix them by putting the length check before performing copy. This fix addresses CVE-2019-14896 and CVE-2019-14897. This also fix build warning of mixed declarations and code. Reported-by: kbuild test robot Signed-off-by: Wen Huang Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 74389183b67101570ec25e80694758b5903fd543 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Prevent tx watchdog timeout commit 686f85d71d095f1d26b807e23b0f0bfd22042c45 upstream. Section 5.5.3.2 of the datasheet says, If FIFO Underrun, Byte Count Mismatch, Excessive Collision, or Excessive Deferral (if enabled) errors occur, transmission ceases. In this situation, the chip asserts a TXER interrupt rather than TXDN. But the handler for the TXDN is the only way that the transmit queue gets restarted. Hence, an aborted transmission can result in a watchdog timeout. This problem can be reproduced on congested link, as that can result in excessive transmitter collisions. Another way to reproduce this is with a FIFO Underrun, which may be caused by DMA latency. In event of a TXER interrupt, prevent a watchdog timeout by restarting transmission. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 58c0c4b122b1681c0f3b0b5b568468a2c00cd906 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Fix CAM initialization commit 772f66421d5aa0b9f256056f513bbc38ac132271 upstream. Section 4.3.1 of the datasheet says, This bit [TXP] must not be set if a Load CAM operation is in progress (LCAM is set). The SONIC will lock up if both bits are set simultaneously. Testing has shown that the driver sometimes attempts to set LCAM while TXP is set. Avoid this by waiting for command completion before and after giving the LCAM command. After issuing the Load CAM command, poll for !SONIC_CR_LCAM rather than SONIC_INT_LCD, because the SONIC_CR_TXP bit can't be used until !SONIC_CR_LCAM. When in reset mode, take the opportunity to reset the CAM Enable register. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 079e7e775895b7472de6c4d3be62b6e80997d354 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Fix command register usage commit 27e0c31c5f27c1d1a1d9d135c123069f60dcf97b upstream. There are several issues relating to command register usage during chip initialization. Firstly, the SONIC sometimes comes out of software reset with the Start Timer bit set. This gets logged as, macsonic macsonic eth0: sonic_init: status=24, i=101 Avoid this by giving the Stop Timer command earlier than later. Secondly, the loop that waits for the Read RRA command to complete has the break condition inverted. That's why the for loop iterates until its termination condition. Call the helper for this instead. Finally, give the Receiver Enable command after clearing interrupts, not before, to avoid the possibility of losing an interrupt. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4d391c40c29521907d484700836c97d2264982d5 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Quiesce SONIC before re-initializing descriptor memory commit 3f4b7e6a2be982fd8820a2b54d46dd9c351db899 upstream. Make sure the SONIC's DMA engine is idle before altering the transmit and receive descriptors. Add a helper for this as it will be needed again. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f638adb9f1a6373bd8369c70254c9d37ddd7885 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Fix receive buffer replenishment commit 89ba879e95582d3bba55081e45b5409e883312ca upstream. As soon as the driver is finished with a receive buffer it allocs a new one and overwrites the corresponding RRA entry with a new buffer pointer. Problem is, the buffer pointer is split across two word-sized registers. It can't be updated in one atomic store. So this operation races with the chip while it stores received packets and advances its RRP register. This could result in memory corruption by a DMA write. Avoid this problem by adding buffers only at the location given by the RWP register, in accordance with the National Semiconductor datasheet. Re-factor this code into separate functions to calculate a RRA pointer and to update the RWP. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3a0c502d4535bac2e01c6f6fd99bb837ea09d770 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Improve receive descriptor status flag check commit 94b166349503957079ef5e7d6f667f157aea014a upstream. After sonic_tx_timeout() calls sonic_init(), it can happen that sonic_rx() will subsequently encounter a receive descriptor with no flags set. Remove the comment that says that this can't happen. When giving a receive descriptor to the SONIC, clear the descriptor status field. That way, any rx descriptor with flags set can only be a newly received packet. Don't process a descriptor without the LPKT bit set. The buffer is still in use by the SONIC. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3a21378463475077b0176f3949964aa72e33765b Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Avoid needless receive descriptor EOL flag updates commit eaabfd19b2c787bbe88dc32424b9a43d67293422 upstream. The while loop in sonic_rx() traverses the rx descriptor ring. It stops when it reaches a descriptor that the SONIC has not used. Each iteration advances the EOL flag so the SONIC can keep using more descriptors. Therefore, the while loop has no definite termination condition. The algorithm described in the National Semiconductor literature is quite different. It consumes descriptors up to the one with its EOL flag set (which will also have its "in use" flag set). All freed descriptors are then returned to the ring at once, by adjusting the EOL flags (and link pointers). Adopt the algorithm from datasheet as it's simpler, terminates quickly and avoids a lot of pointless descriptor EOL flag changes. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f6ecc13bea2b391aab55105d768c584b8757b0cd Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Fix receive buffer handling commit 9e311820f67e740f4fb8dcb82b4c4b5b05bdd1a5 upstream. The SONIC can sometimes advance its rx buffer pointer (RRP register) without advancing its rx descriptor pointer (CRDA register). As a result the index of the current rx descriptor may not equal that of the current rx buffer. The driver mistakenly assumes that they are always equal. This assumption leads to incorrect packet lengths and possible packet duplication. Avoid this by calling a new function to locate the buffer corresponding to a given descriptor. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7092fbffc349c1330e08c42eaf948acb8503cb7 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Fix interface error stats collection commit 427db97df1ee721c20bdc9a66db8a9e1da719855 upstream. The tx_aborted_errors statistic should count packets flagged with EXD, EXC, FU, or BCM bits because those bits denote an aborted transmission. That corresponds to the bitmask 0x0446, not 0x0642. Use macros for these constants to avoid mistakes. Better to leave out FIFO Underruns (FU) as there's a separate counter for that purpose. Don't lump all these errors in with the general tx_errors counter as that's used for tx timeout events. On the rx side, don't count RDE and RBAE interrupts as dropped packets. These interrupts don't indicate a lost packet, just a lack of resources. When a lack of resources results in a lost packet, this gets reported in the rx_missed_errors counter (along with RFO events). Don't double-count rx_frame_errors and rx_crc_errors. Don't use the general rx_errors counter for events that already have special counters. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5a85f05e4626de6441cd5afaa46d07c9e287c7c Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Use MMIO accessors commit e3885f576196ddfc670b3d53e745de96ffcb49ab upstream. The driver accesses descriptor memory which is simultaneously accessed by the chip, so the compiler must not be allowed to re-order CPU accesses. sonic_buf_get() used 'volatile' to prevent that. sonic_buf_put() should have done so too but was overlooked. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c463d5a17032ff66a221e705ece62bed80a47978 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Clear interrupt flags immediately commit 5fedabf5a70be26b19d7520f09f12a62274317c6 upstream. The chip can change a packet's descriptor status flags at any time. However, an active interrupt flag gets cleared rather late. This allows a race condition that could theoretically lose an interrupt. Fix this by clearing asserted interrupt flags immediately. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 091c1715f9dde8eaf3bf513d8fe73fe032365510 Author: Finn Thain Date: Thu Jan 23 09:07:26 2020 +1100 net/sonic: Add mutual exclusion for accessing shared state commit 865ad2f2201dc18685ba2686f13217f8b3a9c52c upstream. The netif_stop_queue() call in sonic_send_packet() races with the netif_wake_queue() call in sonic_interrupt(). This causes issues like "NETDEV WATCHDOG: eth0 (macsonic): transmit queue 0 timed out". Fix this by disabling interrupts when accessing tx_skb[] and next_tx. Update a comment to clarify the synchronization properties. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ab94448beeab30c30c4399b244e65db838be4d64 Author: Linus Torvalds Date: Thu Jan 23 10:05:05 2020 -0800 readdir: be more conservative with directory entry names commit 2c6b7bcd747201441923a0d3062577a8d1fbd8f8 upstream. Commit 8a23eb804ca4 ("Make filldir[64]() verify the directory entry filename is valid") added some minimal validity checks on the directory entries passed to filldir[64](). But they really were pretty minimal. This fleshes out at least the name length check: we used to disallow zero-length names, but really, negative lengths or oevr-long names aren't ok either. Both could happen if there is some filesystem corruption going on. Now, most filesystems tend to use just an "unsigned char" or similar for the length of a directory entry name, so even with a corrupt filesystem you should never see anything odd like that. But since we then use the name length to create the directory entry record length, let's make sure it actually is half-way sensible. Note how POSIX states that the size of a path component is limited by NAME_MAX, but we actually use PATH_MAX for the check here. That's because while NAME_MAX is generally the correct maximum name length (it's 255, for the same old "name length is usually just a byte on disk"), there's nothing in the VFS layer that really cares. So the real limitation at a VFS layer is the total pathname length you can pass as a filename: PATH_MAX. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 454759886d0b463213fad0f1c733469e2c501ab9 Author: Al Viro Date: Sun Jan 26 09:29:34 2020 -0500 do_last(): fetch directory ->i_mode and ->i_uid before it's too late commit d0cb50185ae942b03c4327be322055d622dc79f6 upstream. may_create_in_sticky() call is done when we already have dropped the reference to dir. Fixes: 30aba6656f61e (namei: allow restricted O_CREAT of FIFOs and regular files) Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 5d001c4f74e0417c25e1da6fc861e8f9ee0ba290 Author: Jakub Sitnicki Date: Tue Jan 21 13:31:47 2020 +0100 net, sk_msg: Don't check if sock is locked when tearing down psock commit 58c8db929db1c1d785a6f5d8f8692e5dbcc35e84 upstream. As John Fastabend reports [0], psock state tear-down can happen on receive path *after* unlocking the socket, if the only other psock user, that is sockmap or sockhash, releases its psock reference before tcp_bpf_recvmsg does so: tcp_bpf_recvmsg() psock = sk_psock_get(sk) <- refcnt 2 lock_sock(sk); ... sock_map_free() <- refcnt 1 release_sock(sk) sk_psock_put() <- refcnt 0 Remove the lockdep check for socket lock in psock tear-down that got introduced in 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down"). [0] https://lore.kernel.org/netdev/5e25dc995d7d_74082aaee6e465b441@john-XPS-13-9370.notmuch/ Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down") Reported-by: syzbot+d73682fcf7fee6982fe3@syzkaller.appspotmail.com Suggested-by: John Fastabend Signed-off-by: Jakub Sitnicki Acked-by: John Fastabend Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b2e061912c3ec2843e149208fc0160c2bed877cb Author: Ulrich Weber Date: Wed Jan 15 12:11:29 2020 +0100 xfrm: support output_mark for offload ESP packets commit 4e4362d2bf2a49ff44dbbc9585207977ca3d71d0 upstream. Commit 9b42c1f179a6 ("xfrm: Extend the output_mark") added output_mark support but missed ESP offload support. xfrm_smark_get() is not called within xfrm_input() for packets coming from esp4_gro_receive() or esp6_gro_receive(). Therefore call xfrm_smark_get() directly within these functions. Fixes: 9b42c1f179a6 ("xfrm: Extend the output_mark to support input direction and masking.") Signed-off-by: Ulrich Weber Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 4e1572b19c64244cac4a8aee395b02a2b819e72d Author: Matthew Auld Date: Fri Jan 17 13:24:13 2020 +0000 drm/i915/userptr: fix size calculation commit ecc4d2a52df65479de5e333a9065ed02202a400f upstream. If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by: Matthew Auld Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-2-matthew.auld@intel.com (cherry picked from commit 8e78871bc1e5efec22c950d3fd24ddb63d4ff28a) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 503b54ab9666567e1aff98dc207cf3c89b7d2ab3 Author: Johannes Berg Date: Wed Dec 11 10:15:52 2019 +0100 iwlwifi: mvm: fix potential SKB leak on TXQ TX commit df2378ab0f2a9dd4cf4501268af1902cc4ebacd8 upstream. When we transmit after TXQ dequeue, we aren't paying attention to the return value of the transmit functions, leading to a potential SKB leak. Refactor the code a bit (and rename ..._tx to ..._tx_sta) to check for this happening. Signed-off-by: Johannes Berg Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 1e3c082df32052e77f132a5bb4b2249ef471152c Author: Johannes Berg Date: Wed Dec 11 10:09:56 2019 +0100 iwlwifi: mvm: fix SKB leak on invalid queue commit b9f726c94224e863d4d3458dfec2e7e1284a39ce upstream. It used to be the case that if we got here, we wouldn't warn but instead allocate the queue (DQA). With using the mac80211 TXQs model this changed, and we really have nothing to do with the frame here anymore, hence the warning now. However, clearly we missed in coding & review that this is now a pure error path and leaks the SKB if we return 0 instead of an indication that the SKB needs to be freed. Fix this. Signed-off-by: Johannes Berg Fixes: cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 68ee631ba110f03d6c415ffce399c9f0e987562e Author: Changbin Du Date: Sun Jan 12 11:42:31 2020 +0800 tracing: xen: Ordered comparison of function pointers commit d0695e2351102affd8efae83989056bc4b275917 upstream. Just as commit 0566e40ce7 ("tracing: initcall: Ordered comparison of function pointers"), this patch fixes another remaining one in xen.h found by clang-9. In file included from arch/x86/xen/trace.c:21: In file included from ./include/trace/events/xen.h:475: In file included from ./include/trace/define_trace.h:102: In file included from ./include/trace/trace_events.h:473: ./include/trace/events/xen.h:69:7: warning: ordered comparison of function \ pointers ('xen_mc_callback_fn_t' (aka 'void (*)(void *)') and 'xen_mc_callback_fn_t') [-Wordered-compare-function-pointers] __field(xen_mc_callback_fn_t, fn) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/trace/trace_events.h:421:29: note: expanded from macro '__field' ^ ./include/trace/trace_events.h:407:6: note: expanded from macro '__field_ext' is_signed_type(type), filter_type); \ ^ ./include/linux/trace_events.h:554:44: note: expanded from macro 'is_signed_type' ^ Fixes: c796f213a6934 ("xen/trace: add multicall tracing") Signed-off-by: Changbin Du Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3c6a183d3108229b1f4d8d378061d0dca1c17838 Author: Bart Van Assche Date: Wed Jan 15 20:47:37 2020 -0800 scsi: RDMA/isert: Fix a recently introduced regression related to logout commit 04060db41178c7c244f2c7dcd913e7fd331de915 upstream. iscsit_close_connection() calls isert_wait_conn(). Due to commit e9d3009cb936 both functions call target_wait_for_sess_cmds() although that last function should be called only once. Fix this by removing the target_wait_for_sess_cmds() call from isert_wait_conn() and by only calling isert_wait_conn() after target_wait_for_sess_cmds(). Fixes: e9d3009cb936 ("scsi: target: iscsi: Wait for all commands to finish before freeing a session"). Link: https://lore.kernel.org/r/20200116044737.19507-1-bvanassche@acm.org Reported-by: Rahul Kundu Signed-off-by: Bart Van Assche Tested-by: Mike Marciniszyn Acked-by: Sagi Grimberg Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit bbf0d37947f71abbabb659d8e2114a86648eb83b Author: Gilles Buloz Date: Fri Nov 29 10:56:05 2019 +0100 hwmon: (nct7802) Fix non-working alarm on voltages commit e51a7dda299815e92f43960d620cdfc8dfc144f2 upstream. No alarm is reported by /sys/.../inX_alarm In detail: The SMI Voltage status register is the only register giving a status for voltages, but it does not work like the non-SMI status registers used for temperatures and fans. A bit is set for each input crossing a threshold, in both direction, but the "inside" or "outside" limits info is not available. Also this register is cleared on read. Note : this is not explicitly spelled out in the datasheet, but from experiment. As a result if an input is crossing a threshold (min or max in any direction), the alarm is reported only once even if the input is still outside limits. Also if the alarm for another input is read before the one of this input, no alarm is reported at all. Signed-off-by: Gilles Buloz Link: https://lore.kernel.org/r/5de0f566.tBga5POKAgHlmd0p%gilles.buloz@kontron.com Fixes: 3434f3783580 ("hwmon: Driver for Nuvoton NCT7802Y") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 515b97c73447807a30f71267d15b329b194d4056 Author: Gilles Buloz Date: Wed Nov 27 18:09:34 2019 +0100 hwmon: (nct7802) Fix voltage limits to wrong registers commit 7713e62c8623c54dac88d1fa724aa487a38c3efb upstream. in0 thresholds are written to the in2 thresholds registers in2 thresholds to in3 thresholds in3 thresholds to in4 thresholds in4 thresholds to in0 thresholds Signed-off-by: Gilles Buloz Link: https://lore.kernel.org/r/5de0f509.rc0oEvPOMjbfPW1w%gilles.buloz@kontron.com Fixes: 3434f3783580 ("hwmon: Driver for Nuvoton NCT7802Y") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 54b818246b03163a99e569a4cf11c0e3a312696e Author: xiaofeng.yan Date: Mon Jan 20 14:26:39 2020 +0800 hsr: Fix a compilation error commit 80892772c4edac88c538165d26a0105f19b61c1c upstream. A compliation error happen when building branch 5.5-rc7 In file included from net/hsr/hsr_main.c:12:0: net/hsr/hsr_main.h:194:20: error: two or more data types in declaration specifiers static inline void void hsr_debugfs_rename(struct net_device *dev) So Removed one void. Fixes: 4c2d5e33dcd3 ("hsr: rename debugfs file when interface name is changed") Signed-off-by: xiaofeng.yan Acked-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5440678b5acbfea878d30922ba44ffecfb9487b7 Author: Jacek Anaszewski Date: Thu Dec 5 22:25:01 2019 +0100 leds: gpio: Fix uninitialized gpio label for fwnode based probe commit 90a8e82d3ca8c1f85ac63f4a94c9b034f05af4ee upstream. When switching to using generic LED name composition mechanism via devm_led_classdev_register_ext() API the part of code initializing struct gpio_led's template name property was removed alongside. It was however overlooked that the property was also passed to devm_fwnode_get_gpiod_from_child() in place of "label" parameter, which when set to NULL, results in gpio label being initialized to '?'. It could be observed in debugfs and failed to properly identify gpio association with LED consumer. Fix this shortcoming by updating the GPIO label after the LED is registered and its final name is known. Fixes: d7235f5feaa0 ("leds: gpio: Use generic support for composing LED names") Cc: Russell King Reviewed-by: Linus Walleij Signed-off-by: Jacek Anaszewski [fixed comment] Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 376b860334d2b2a0db65396093724b21be2e18a9 Author: Linus Torvalds Date: Wed Jan 22 12:37:25 2020 -0800 readdir: make user_access_begin() use the real access range commit 3c2659bd1db81ed6a264a9fc6262d51667d655ad upstream. In commit 9f79b78ef744 ("Convert filldir[64]() from __put_user() to unsafe_put_user()") I changed filldir to not do individual __put_user() accesses, but instead use unsafe_put_user() surrounded by the proper user_access_begin/end() pair. That make them enormously faster on modern x86, where the STAC/CLAC games make individual user accesses fairly heavy-weight. However, the user_access_begin() range was not really the exact right one, since filldir() has the unfortunate problem that it needs to not only fill out the new directory entry, it also needs to fix up the previous one to contain the proper file offset. It's unfortunate, but the "d_off" field in "struct dirent" is _not_ the file offset of the directory entry itself - it's the offset of the next one. So we end up backfilling the offset in the previous entry as we walk along. But since x86 didn't really care about the exact range, and used to be the only architecture that did anything fancy in user_access_begin() to begin with, the filldir[64]() changes did something lazy, and even commented on it: /* * Note! This range-checks 'previous' (which may be NULL). * The real range was checked in getdents */ if (!user_access_begin(dirent, sizeof(*dirent))) goto efault; and it all worked fine. But now 32-bit ppc is starting to also implement user_access_begin(), and the fact that we faked the range to only be the (possibly not even valid) previous directory entry becomes a problem, because ppc32 will actually be using the range that is passed in for more than just "check that it's user space". This is a complete rewrite of Christophe's original patch. By saving off the record length of the previous entry instead of a pointer to it in the filldir data structures, we can simplify the range check and the writing of the previous entry d_off field. No need for any conditionals in the user accesses themselves, although we retain the conditional EINTR checking for the "was this the first directory entry" signal handling latency logic. Fixes: 9f79b78ef744 ("Convert filldir[64]() from __put_user() to unsafe_put_user()") Link: https://lore.kernel.org/lkml/a02d3426f93f7eb04960a4d9140902d278cab0bb.1579697910.git.christophe.leroy@c-s.fr/ Link: https://lore.kernel.org/lkml/408c90c4068b00ea8f1c41cca45b84ec23d4946b.1579783936.git.christophe.leroy@c-s.fr/ Reported-and-tested-by: Christophe Leroy Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 16aab32ff8b379f3e1e3b4f0d52f50cb52fc48bb Author: Shuah Khan Date: Thu Jan 23 15:32:14 2020 -0700 iommu/amd: Fix IOMMU perf counter clobbering during init commit 8c17bbf6c8f70058a66305f2e1982552e6ea7f47 upstream. init_iommu_perf_ctr() clobbers the register when it checks write access to IOMMU perf counters and fails to restore when they are writable. Add save and restore to fix it. Signed-off-by: Shuah Khan Fixes: 30861ddc9cca4 ("perf/x86/amd: Add IOMMU Performance Counter resource management") Reviewed-by: Suravee Suthikulpanit Tested-by: Suravee Suthikulpanit Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 9f6216862a2075474fa985ea3b801c2ac4b41de3 Author: Christophe Leroy Date: Thu Jan 23 08:34:18 2020 +0000 lib: Reduce user_access_begin() boundaries in strncpy_from_user() and strnlen_user() commit ab10ae1c3bef56c29bac61e1201c752221b87b41 upstream. The range passed to user_access_begin() by strncpy_from_user() and strnlen_user() starts at 'src' and goes up to the limit of userspace although reads will be limited by the 'count' param. On 32 bits powerpc (book3s/32) access has to be granted for each 256Mbytes segment and the cost increases with the number of segments to unlock. Limit the range with 'count' param. Fixes: 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") Signed-off-by: Christophe Leroy Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9e2e1a5abccd3a4cd331549399c6ff4008aa4bba Author: Florian Westphal Date: Sat Jan 18 11:27:25 2020 +0100 netfilter: nft_osf: add missing check for DREG attribute commit 7eaecf7963c1c8f62d62c6a8e7c439b0e7f2d365 upstream. syzbot reports just another NULL deref crash because of missing test for presence of the attribute. Reported-by: syzbot+cf23983d697c26c34f60@syzkaller.appspotmail.com Fixes: b96af92d6eaf9fadd ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 373ffce2337bb4ad8109cc4309fde532b0a02e4d Author: Chuhong Yuan Date: Fri Jan 10 10:30:04 2020 -0800 Input: sun4i-ts - add a check for devm_thermal_zone_of_sensor_register commit 97e24b095348a15ec08c476423c3b3b939186ad7 upstream. The driver misses a check for devm_thermal_zone_of_sensor_register(). Add a check to fix it. Fixes: e28d0c9cd381 ("input: convert sun4i-ts to use devm_thermal_zone_of_sensor_register") Signed-off-by: Chuhong Yuan Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 21aa01da9dba44e61700247c2813e78aeb3720cb Author: Johan Hovold Date: Fri Jan 10 11:55:47 2020 -0800 Input: pegasus_notetaker - fix endpoint sanity check commit bcfcb7f9b480dd0be8f0df2df17340ca92a03b98 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could be used by a malicious device (or USB descriptor fuzzer) to trigger a NULL-pointer dereference. Fixes: 1afca2b66aac ("Input: add Pegasus Notetaker tablet driver") Signed-off-by: Johan Hovold Acked-by: Martin Kepplinger Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-2-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c65dfef2780316a1f916eec9689da1a09e6f77ee Author: Johan Hovold Date: Fri Jan 10 11:59:32 2020 -0800 Input: aiptek - fix endpoint sanity check commit 3111491fca4f01764e0c158c5e0f7ced808eef51 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-3-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 56ded4adf16e91ee522549e3d724fa3e1cdcdb4b Author: Johan Hovold Date: Fri Jan 10 12:00:18 2020 -0800 Input: gtco - fix endpoint sanity check commit a8eeb74df5a6bdb214b2b581b14782c5f5a0cf83 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 162f98dea487 ("Input: gtco - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-5-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3e629da150b53225d8f27cca5d27e3da783e40be Author: Johan Hovold Date: Fri Jan 10 12:01:27 2020 -0800 Input: sur40 - fix interface sanity checks commit 6b32391ed675827f8425a414abbc6fbd54ea54fe upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-8-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 68c2bc4da0986fb2add4e76cf1f41444ddc6e1b1 Author: Stephan Gerhold Date: Fri Jan 17 13:40:36 2020 -0800 Input: pm8xxx-vib - fix handling of separate enable register commit 996d5d5f89a558a3608a46e73ccd1b99f1b1d058 upstream. Setting the vibrator enable_mask is not implemented correctly: For regmap_update_bits(map, reg, mask, val) we give in either regs->enable_mask or 0 (= no-op) as mask and "val" as value. But "val" actually refers to the vibrator voltage control register, which has nothing to do with the enable_mask. So we usually end up doing nothing when we really wanted to enable the vibrator. We want to set or clear the enable_mask (to enable/disable the vibrator). Therefore, change the call to always modify the enable_mask and set the bits only if we want to enable the vibrator. Fixes: d4c7c5c96c92 ("Input: pm8xxx-vib - handle separate enable register") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200114183442.45720-1-stephan@gerhold.net Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c3f6abfe2f117390bd66488bf88059e704f38f39 Author: Jakub Kicinski Date: Fri Jan 10 04:38:32 2020 -0800 net/tls: fix async operation commit db885e66d268884dc72967279b7e84f522556abc upstream. Mallesham reports the TLS with async accelerator was broken by commit d10523d0b3d7 ("net/tls: free the record on encryption error") because encryption can return -EINPROGRESS in such setups, which should not be treated as an error. The error is also present in the BPF path (likely copied from there). Reported-by: Mallesham Jatharakonda Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Fixes: d10523d0b3d7 ("net/tls: free the record on encryption error") Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c9cb4f2bea447ca21fc959005105b76b3455e83c Author: Ido Schimmel Date: Wed Jan 15 13:53:46 2020 +0200 mlxsw: switchx2: Do not modify cloned SKBs during xmit commit 63963d0f9d17be83d0e419e03282847ecc2c3715 upstream. The driver needs to prepend a Tx header to each packet it is transmitting. The header includes information such as the egress port and traffic class. The addition of the header requires the driver to modify the SKB's header and therefore it must not be shared. Otherwise, we risk hitting various race conditions. For example, when a packet is flooded (cloned) by the bridge driver to two switch ports swp1 and swp2: t0 - mlxsw_sp_port_xmit() is called for swp1. Tx header is prepended with swp1's port number t1 - mlxsw_sp_port_xmit() is called for swp2. Tx header is prepended with swp2's port number, overwriting swp1's port number t2 - The device processes data buffer from t0. Packet is transmitted via swp2 t3 - The device processes data buffer from t1. Packet is transmitted via swp2 Usually, the device is fast enough and transmits the packet before its Tx header is overwritten, but this is not the case in emulated environments. Fix this by making sure the SKB's header is writable by calling skb_cow_head(). Since the function ensures we have headroom to push the Tx header, the check further in the function can be removed. v2: * Use skb_cow_head() instead of skb_unshare() as suggested by Jakub * Remove unnecessary check regarding headroom Fixes: 31557f0f9755 ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support") Signed-off-by: Ido Schimmel Reported-by: Shalom Toledo Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77d323cc3783d50f177a7b5b8ba8c9271b118048 Author: Faiz Abbas Date: Wed Jan 8 20:03:00 2020 +0530 mmc: sdhci_am654: Reset Command and Data line after tuning commit de31f6ab68a3f548d88686d53514f252d78f61d5 upstream. The tuning data is leftover in the buffer after tuning. This can cause issues in future data commands, especially with CQHCI. Reset the command and data lines after tuning to continue from a clean state. Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver") Cc: stable@vger.kernel.org Signed-off-by: Faiz Abbas Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20200108143301.1929-3-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d5bb81660456610a6b3e0b0f54df5a09898c0847 Author: Faiz Abbas Date: Wed Jan 8 20:02:59 2020 +0530 mmc: sdhci_am654: Remove Inverted Write Protect flag commit 4d627c88546a697b07565dbb70d2f9f46a5ee76f upstream. The MMC/SD controllers on am65x and j721e don't in fact detect the write protect line as inverted. No issues were detected because of this because the sdwp line is not connected on any of the evms. Fix this by removing the flag. Fixes: 1accbced1c32 ("mmc: sdhci_am654: Add Support for 4 bit IP on J721E") Cc: stable@vger.kernel.org Signed-off-by: Faiz Abbas Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20200108143301.1929-2-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d8bc6ac2db28ce03816263933a52adadbf68e984 Author: Michał Mirosław Date: Wed Jan 15 10:54:35 2020 +0100 mmc: sdhci: fix minimum clock rate for v3 controller commit 2a187d03352086e300daa2044051db00044cd171 upstream. For SDHCIv3+ with programmable clock mode, minimal clock frequency is still base clock / max(divider). Minimal programmable clock frequency is always greater than minimal divided clock frequency. Without this patch, SDHCI uses out-of-spec initial frequency when multiplier is big enough: mmc1: mmc_rescan_try_freq: trying to init card at 468750 Hz [for 480 MHz source clock divided by 1024] The code in sdhci_calc_clk() already chooses a correct SDCLK clock mode. Fixes: c3ed3877625f ("mmc: sdhci: add support for programmable clock mode") Cc: # 4f6aa3264af4: mmc: tegra: Only advertise UHS modes if IO regulator is present Cc: Signed-off-by: Michał Mirosław Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/ffb489519a446caffe7a0a05c4b9372bd52397bb.1579082031.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 723f200e19bdb42bf0b1cd5c129d599b23e93db0 Author: Michał Mirosław Date: Tue Jan 7 10:47:34 2020 +0100 mmc: tegra: fix SDR50 tuning override commit f571389c0b015e76f91c697c4c1700aba860d34f upstream. Commit 7ad2ed1dfcbe inadvertently mixed up a quirk flag's name and broke SDR50 tuning override. Use correct NVQUIRK_ name. Fixes: 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes") Cc: Acked-by: Adrian Hunter Reviewed-by: Thierry Reding Tested-by: Thierry Reding Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/9aff1d859935e59edd81e4939e40d6c55e0b55f6.1578390388.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bccb1568bae8b7adf4de980b2843fecbe9c52c5e Author: Alex Sverdlin Date: Wed Jan 8 15:57:47 2020 +0100 ARM: 8950/1: ftrace/recordmcount: filter relocation types commit 927d780ee371d7e121cea4fc7812f6ef2cea461c upstream. Scenario 1, ARMv7 ================= If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer the following may be generated: 00000230 : 230: b5f8 push {r3, r4, r5, r6, r7, lr} 232: b500 push {lr} 234: f7ff fffe bl 0 <__gnu_mcount_nc> 234: R_ARM_THM_CALL __gnu_mcount_nc 238: f240 0600 movw r6, #0 238: R_ARM_THM_MOVW_ABS_NC __gnu_mcount_nc 23c: f8d0 1180 ldr.w r1, [r0, #384] ; 0x180 FTRACE currently is not able to deal with it: WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230() ... CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1 ... [] (unwind_backtrace) from [] (show_stack+0x11/0x14) [] (show_stack) from [] (dump_stack+0x81/0xa8) [] (dump_stack) from [] (warn_slowpath_common+0x69/0x90) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x17/0x1c) [] (warn_slowpath_null) from [] (ftrace_bug+0x1ad/0x230) [] (ftrace_bug) from [] (ftrace_process_locs+0x27d/0x444) [] (ftrace_process_locs) from [] (ftrace_init+0x91/0xe8) [] (ftrace_init) from [] (start_kernel+0x34b/0x358) [] (start_kernel) from [<00308095>] (0x308095) ---[ end trace cb88537fdc8fa200 ]--- ftrace failed to modify [] prealloc_fixed_plts+0x8/0x60 actual: 44:f2:e1:36 ftrace record flags: 0 (0) expected tramp: c03143e9 Scenario 2, ARMv4T ================== ftrace: allocating 14435 entries in 43 pages ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310 CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1 Hardware name: Cirrus Logic EDB9302 Evaluation Board [] (unwind_backtrace) from [] (show_stack+0x20/0x2c) [] (show_stack) from [] (dump_stack+0x20/0x30) [] (dump_stack) from [] (__warn+0xdc/0x104) [] (__warn) from [] (warn_slowpath_null+0x4c/0x5c) [] (warn_slowpath_null) from [] (ftrace_bug+0x204/0x310) [] (ftrace_bug) from [] (ftrace_init+0x3b4/0x4d4) [] (ftrace_init) from [] (start_kernel+0x20c/0x410) [] (start_kernel) from [<00000000>] ( (null)) ---[ end trace 0506a2f5dae6b341 ]--- ftrace failed to modify [] perf_trace_sys_exit+0x5c/0xe8 actual: 1e:ff:2f:e1 Initializing ftrace call sites ftrace record flags: 0 (0) expected tramp: c000fb24 The analysis for this problem has been already performed previously, refer to the link below. Fix the above problems by allowing only selected reloc types in __mcount_loc. The list itself comes from the legacy recordmcount.pl script. Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/ Cc: stable@vger.kernel.org Fixes: ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount") Signed-off-by: Alexander Sverdlin Acked-by: Steven Rostedt (VMware) Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ff847d466bdb0f17608083185586bb3c60f7cb78 Author: Hans Verkuil Date: Thu Jan 16 20:12:27 2020 -0800 Revert "Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers" commit 8ff771f8c8d55d95f102cf88a970e541a8bd6bcf upstream. This reverts commit a284e11c371e446371675668d8c8120a27227339. This causes problems (drifting cursor) with at least the F11 function that reads more than 32 bytes. The real issue is in the F54 driver, and so this should be fixed there, and not in rmi_smbus.c. So first revert this bad commit, then fix the real problem in F54 in another patch. Signed-off-by: Hans Verkuil Reported-by: Timo Kaufmann Fixes: a284e11c371e ("Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200115124819.3191024-2-hverkuil-cisco@xs4all.nl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit cec754961758e4e7331d98a82140d64d2702aa7e Author: Johan Hovold Date: Mon Jan 13 10:38:57 2020 -0800 Input: keyspan-remote - fix control-message timeouts commit ba9a103f40fc4a3ec7558ec9b0b97d4f92034249 upstream. The driver was issuing synchronous uninterruptible control requests without using a timeout. This could lead to the driver hanging on probe due to a malfunctioning (or malicious) device until the device is physically disconnected. While sleeping in probe the driver prevents other devices connected to the same hub from being added to (or removed from) the bus. The USB upper limit of five seconds per request should be more than enough. Fixes: 99f83c9c9ac9 ("[PATCH] USB: add driver for Keyspan Digital Remote") Signed-off-by: Johan Hovold Reviewed-by: Greg Kroah-Hartman Cc: stable # 2.6.13 Link: https://lore.kernel.org/r/20200113171715.30621-1-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5d1973adcfffa180cb474ee55db0d990eb833378 Author: Jerry Snitselaar Date: Tue Jan 21 17:34:26 2020 -0700 iommu/vt-d: Call __dmar_remove_one_dev_info with valid pointer commit bf708cfb2f4811d1948a88c41ab96587e84ad344 upstream. It is possible for archdata.iommu to be set to DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO so check for those values before calling __dmar_remove_one_dev_info. Without a check it can result in a null pointer dereference. This has been seen while booting a kdump kernel on an HP dl380 gen9. Cc: Joerg Roedel Cc: Lu Baolu Cc: David Woodhouse Cc: stable@vger.kernel.org # 5.3+ Cc: linux-kernel@vger.kernel.org Fixes: ae23bfb68f28 ("iommu/vt-d: Detach domain before using a private one") Signed-off-by: Jerry Snitselaar Acked-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit d4616a9f8ee9d8a05fa9f36901d91ed6a0a49e1e Author: Boyan Ding Date: Wed Jan 1 12:41:20 2020 -0800 pinctrl: sunrisepoint: Add missing Interrupt Status register offset commit 9608ea6c6613ced75b2c41703d99f44e6f8849f1 upstream. Commit 179e5a6114cc ("pinctrl: intel: Remove default Interrupt Status offset") removes default interrupt status offset of GPIO controllers, with previous commits explicitly providing the previously default offsets. However, the is_offset value in SPTH_COMMUNITY is missing, preventing related irq from being properly detected and handled. Fixes: f702e0b93cdb ("pinctrl: sunrisepoint: Provide Interrupt Status register offset") Link: https://bugzilla.kernel.org/show_bug.cgi?id=205745 Cc: stable@vger.kernel.org Signed-off-by: Boyan Ding Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit dd05cf12c72f11b7841d4ffeca29e5190606df1b Author: Matthew Wilcox (Oracle) Date: Fri Jan 17 22:13:21 2020 -0500 XArray: Fix xas_find returning too many entries commit c44aa5e8ab58b5f4cf473970ec784c3333496a2e upstream. If you call xas_find() with the initial index > max, it should have returned NULL but was returning the entry at index. Signed-off-by: Matthew Wilcox (Oracle) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit db38561288b75082b5e839decaa15ed253bd2298 Author: Matthew Wilcox (Oracle) Date: Fri Jan 17 22:00:41 2020 -0500 XArray: Fix xa_find_after with multi-index entries commit 19c30f4dd0923ef191f35c652ee4058e91e89056 upstream. If the entry is of an order which is a multiple of XA_CHUNK_SIZE, the current detection of sibling entries does not work. Factor out an xas_sibling() function to make xa_find_after() a little more understandable, and write a new implementation that doesn't suffer from the same bug. Signed-off-by: Matthew Wilcox (Oracle) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a5135ca1f92a7b201b7f8297f42b8579f92bc55d Author: Matthew Wilcox (Oracle) Date: Fri Jan 17 17:45:12 2020 -0500 XArray: Fix infinite loop with entry at ULONG_MAX commit 430f24f94c8a174d411a550d7b5529301922e67a upstream. If there is an entry at ULONG_MAX, xa_for_each() will overflow the 'index + 1' in xa_find_after() and wrap around to 0. Catch this case and terminate the loop by returning NULL. Signed-off-by: Matthew Wilcox (Oracle) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b8560e3d90afad8c5ee1ae4fea41949a76b5bb8b Author: Emmanuel Grumbach Date: Tue Dec 3 10:08:49 2019 +0200 iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queues commit d829229e35f302fd49c052b5c5906c90ecf9911d upstream. The purpose of this was to keep all the queues updated with the Rx sequence numbers because unlikely yet possible situations where queues can't understand if a specific packet needs to be dropped or not. Unfortunately, it was reported that this caused issues in our DMA engine. We don't fully understand how this is related, but this is being currently debugged. For now, just don't send this notification to the Rx queues. This de-facto reverts my commit 3c514bf831ac12356b695ff054bef641b9e99593: iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues This issue was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=204873 https://bugzilla.kernel.org/show_bug.cgi?id=205001 and others maybe. Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues") CC: # 5.3+ Signed-off-by: Emmanuel Grumbach Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 4e7d8cd6a1a8959a5a3dcb289162041c2eb49124 Author: Mehmet Akif Tasova Date: Fri Dec 13 23:35:10 2019 +0300 Revert "iwlwifi: mvm: fix scan config command size" commit 205608749e1ef394f513888091e613c5bfccbcca upstream. Since v5.4-rc1 was released, iwlwifi started throwing errors when scan commands were sent to the firmware with certain devices (depending on the OTP burned in the device, which contains the list of available channels). For instance: iwlwifi 0000:00:14.3: FW error in SYNC CMD SCAN_CFG_CMD This bug was reported in the ArchLinux bug tracker: https://bugs.archlinux.org/task/64703 And also in a specific case in bugzilla, when the lar_disabled option was set: https://bugzilla.kernel.org/show_bug.cgi?id=205193 Revert the commit that introduced this error, by using the number of channels from the OTP instead of the number of channels that is specified in the FW TLV that tells us how many channels it supports. This reverts commit 06eb547c4ae4382e70d556ba213d13c95ca1801b. Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Mehmet Akif Tasova [ Luca: reworded the commit message a bit. ] Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 7cf7a7d025879086bd69570398832e00d3613dd5 Author: Frederic Barrat Date: Mon Jan 13 14:01:18 2020 +0100 powerpc/xive: Discard ESB load value when interrupt is invalid commit 17328f218fb760c9c6accc5b52494889243a6b98 upstream. A load on an ESB page returning all 1's means that the underlying device has invalidated the access to the PQ state of the interrupt through mmio. It may happen, for example when querying a PHB interrupt while the PHB is in an error state. In that case, we should consider the interrupt to be invalid when checking its state in the irq_get_irqchip_state() handler. Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Frederic Barrat [clg: wrote a commit log, introduced XIVE_ESB_INVALID ] Signed-off-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200113130118.27969-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit 6145307fa69332ab98cfd0efd6c63394418ba23b Author: Aneesh Kumar K.V Date: Wed Jan 8 11:14:22 2020 +0530 powerpc/mm/hash: Fix sharing context ids between kernel & userspace commit 5d2e5dd5849b4ef5e8ec35e812cdb732c13cd27e upstream. Commit 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range") has a bug in the definition of MIN_USER_CONTEXT. The result is that the context id used for the vmemmap and the lowest context id handed out to userspace are the same. The context id is essentially the process identifier as far as the first stage of the MMU translation is concerned. This can result in multiple SLB entries with the same VSID (Virtual Segment ID), accessible to the kernel and some random userspace process that happens to get the overlapping id, which is not expected eg: 07 c00c000008000000 40066bdea7000500 1T ESID= c00c00 VSID= 66bdea7 LLP:100 12 0002000008000000 40066bdea7000d80 1T ESID= 200 VSID= 66bdea7 LLP:100 Even though the user process and the kernel use the same VSID, the permissions in the hash page table prevent the user process from reading or writing to any kernel mappings. It can also lead to SLB entries with different base page size encodings (LLP), eg: 05 c00c000008000000 00006bde0053b500 256M ESID=c00c00000 VSID= 6bde0053b LLP:100 09 0000000008000000 00006bde0053bc80 256M ESID= 0 VSID= 6bde0053b LLP: 0 Such SLB entries can result in machine checks, eg. as seen on a G5: Oops: Machine check, sig: 7 [#1] BE PAGE SIZE=64K MU-Hash SMP NR_CPUS=4 NUMA Power Mac NIP: c00000000026f248 LR: c000000000295e58 CTR: 0000000000000000 REGS: c0000000erfd3d70 TRAP: 0200 Tainted: G M (5.5.0-rcl-gcc-8.2.0-00010-g228b667d8ea1) MSR: 9000000000109032 CR: 24282048 XER: 00000000 DAR: c00c000000612c80 DSISR: 00000400 IRQMASK: 0 ... NIP [c00000000026f248] .kmem_cache_free+0x58/0x140 LR [c088000008295e58] .putname 8x88/0xa Call Trace: .putname+0xB8/0xa .filename_lookup.part.76+0xbe/0x160 .do_faccessat+0xe0/0x380 system_call+0x5c/ex68 This happens with 256MB segments and 64K pages, as the duplicate VSID is hit with the first vmemmap segment and the first user segment, and older 32-bit userspace maps things in the first user segment. On other CPUs a machine check is not seen. Instead the userspace process can get stuck continuously faulting, with the fault never properly serviced, due to the kernel not understanding that there is already a HPTE for the address but with inaccessible permissions. On machines with 1T segments we've not seen the bug hit other than by deliberately exercising it. That seems to be just a matter of luck though, due to the typical layout of the user virtual address space and the ranges of vmemmap that are typically populated. To fix it we add 2 to MIN_USER_CONTEXT. This ensures the lowest context given to userspace doesn't overlap with the VMEMMAP context, or with the context for INVALID_REGION_ID. Fixes: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range") Cc: stable@vger.kernel.org # v5.2+ Reported-by: Christian Marillat Reported-by: Romain Dolbeau Signed-off-by: Aneesh Kumar K.V [mpe: Account for INVALID_REGION_ID, mostly rewrite change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200123102547.11623-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit bf470f051556b610265ea02ad2102de75e8e619c Author: Steven Rostedt (VMware) Date: Mon Jan 20 13:07:31 2020 -0500 tracing: Fix histogram code when expression has same var as value commit 8bcebc77e85f3d7536f96845a0fe94b1dddb6af0 upstream. While working on a tool to convert SQL syntex into the histogram language of the kernel, I discovered the following bug: # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' >> synthetic_events # echo 'hist:keys=pid:start=common_timestamp' > events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger Would not display any histograms in the sched_switch histogram side. But if I were to swap the location of "delta=common_timestamp-$start" with "start2=$start" Such that the last line had: # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger The histogram works as expected. What I found out is that the expressions clear out the value once it is resolved. As the variables are resolved in the order listed, when processing: delta=common_timestamp-$start The $start is cleared. When it gets to "start2=$start", it errors out with "unresolved symbol" (which is silent as this happens at the location of the trace), and the histogram is dropped. When processing the histogram for variable references, instead of adding a new reference for a variable used twice, use the same reference. That way, not only is it more efficient, but the order will no longer matter in processing of the variables. From Tom Zanussi: "Just to clarify some more about what the problem was is that without your patch, we would have two separate references to the same variable, and during resolve_var_refs(), they'd both want to be resolved separately, so in this case, since the first reference to start wasn't part of an expression, it wouldn't get the read-once flag set, so would be read normally, and then the second reference would do the read-once read and also be read but using read-once. So everything worked and you didn't see a problem: from: start2=$start,delta=common_timestamp-$start In the second case, when you switched them around, the first reference would be resolved by doing the read-once, and following that the second reference would try to resolve and see that the variable had already been read, so failed as unset, which caused it to short-circuit out and not do the trigger action to generate the synthetic event: to: delta=common_timestamp-$start,start2=$start With your patch, we only have the single resolution which happens correctly the one time it's resolved, so this can't happen." Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Tom Zanuss Tested-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 07af0d03e8b2e888b07ce5ed353fa8b6497918e1 Author: Masami Ichikawa Date: Thu Jan 16 22:12:36 2020 +0900 tracing: Do not set trace clock if tracefs lockdown is in effect commit bf24daac8f2bd5b8affaec03c2be1d20bcdd6837 upstream. When trace_clock option is not set and unstable clcok detected, tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of case). In that case, if lockdown is in effect, null pointer dereference error happens in ring_buffer_set_clock(). Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com Cc: stable@vger.kernel.org Fixes: 17911ff38aa58 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488 Signed-off-by: Masami Ichikawa Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 67551f958458ba077c6237a14c4cf6a834cba667 Author: Masami Hiramatsu Date: Fri Jan 10 10:45:39 2020 +0900 tracing/uprobe: Fix double perf_event linking on multiprobe uprobe commit 99c9a923e97a583a38050baa92c9377d73946330 upstream. Fix double perf_event linking to trace_uprobe_filter on multiple uprobe event by moving trace_uprobe_filter under trace_probe_event. In uprobe perf event, trace_uprobe_filter data structure is managing target mm filters (in perf_event) related to each uprobe event. Since commit 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") left the trace_uprobe_filter data structure in trace_uprobe, if a trace_probe_event has multiple trace_uprobe (multi-probe event), a perf_event is added to different trace_uprobe_filter on each trace_uprobe. This leads a linked list corruption. To fix this issue, move trace_uprobe_filter to trace_probe_event and link it once on each event instead of each probe. Link: http://lkml.kernel.org/r/157862073931.1800.3800576241181489174.stgit@devnote2 Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Ingo Molnar Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: "David S . Miller" Cc: Namhyung Kim Cc: =?utf-8?q?Toke_H=C3=B8iland-J?= =?utf-8?b?w7hyZ2Vuc2Vu?= Cc: Jean-Tsung Hsiao Cc: Jesper Dangaard Brouer Cc: stable@vger.kernel.org Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") Link: https://lkml.kernel.org/r/20200108171611.GA8472@kernel.org Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 44eebad1049644e6200d6a08c7f6d56436c55021 Author: Masami Hiramatsu Date: Fri Dec 20 11:31:43 2019 +0900 tracing: trigger: Replace unneeded RCU-list traversals commit aeed8aa3874dc15b9d82a6fe796fd7cfbb684448 upstream. With CONFIG_PROVE_RCU_LIST, I had many suspicious RCU warnings when I ran ftracetest trigger testcases. ----- # dmesg -c > /dev/null # ./ftracetest test.d/trigger ... # dmesg | grep "RCU-list traversed" | cut -f 2 -d ] | cut -f 2 -d " " kernel/trace/trace_events_hist.c:6070 kernel/trace/trace_events_hist.c:1760 kernel/trace/trace_events_hist.c:5911 kernel/trace/trace_events_trigger.c:504 kernel/trace/trace_events_hist.c:1810 kernel/trace/trace_events_hist.c:3158 kernel/trace/trace_events_hist.c:3105 kernel/trace/trace_events_hist.c:5518 kernel/trace/trace_events_hist.c:5998 kernel/trace/trace_events_hist.c:6019 kernel/trace/trace_events_hist.c:6044 kernel/trace/trace_events_trigger.c:1500 kernel/trace/trace_events_trigger.c:1540 kernel/trace/trace_events_trigger.c:539 kernel/trace/trace_events_trigger.c:584 ----- I investigated those warnings and found that the RCU-list traversals in event trigger and hist didn't need to use RCU version because those were called only under event_mutex. I also checked other RCU-list traversals related to event trigger list, and found that most of them were called from event_hist_trigger_func() or hist_unregister_trigger() or register/unregister functions except for a few cases. Replace these unneeded RCU-list traversals with normal list traversal macro and lockdep_assert_held() to check the event_mutex is held. Link: http://lkml.kernel.org/r/157680910305.11685.15110237954275915782.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: 30350d65ac567 ("tracing: Add variable support to hist triggers") Reviewed-by: Tom Zanussi Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit b1302cbe530b26ce6ba4a1a4019513393a566f6f Author: Alexander Potapenko Date: Thu Jan 16 12:09:34 2020 +0100 PM: hibernate: fix crashes with init_on_free=1 commit 18451f9f9e5810b8bd1245c5ae166f257e0e2b9d upstream. Upon resuming from hibernation, free pages may contain stale data from the kernel that initiated the resume. This breaks the invariant inflicted by init_on_free=1 that freed pages must be zeroed. To deal with this problem, make clear_free_pages() also clear the free pages when init_on_free is enabled. Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options") Reported-by: Johannes Stezenbach Signed-off-by: Alexander Potapenko Cc: 5.3+ # 5.3+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d63b777d8145d351d1e8f991156a98fe51bea964 Author: Tvrtko Ursulin Date: Thu Jan 16 13:45:08 2020 +0000 drm/i915: Align engine->uabi_class/instance with i915_drm.h commit 5eec71829ad7749a8c918f66a91a9bcf6fb4462a upstream. In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by: Tvrtko Ursulin Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson Cc: # v5.3+ Reviewed-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20200116134508.25211-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 0b3bd0cdc329a1e2e00995cffd61aacf58c87cb4) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 3e041c27b9909704a54bc673f9110391e740f583 Author: Boris Brezillon Date: Wed Jan 15 20:15:54 2020 -0600 drm/panfrost: Add the panfrost_gem_mapping concept commit bdefca2d8dc0f80bbe49e08bf52a717146490706 upstream. With the introduction of per-FD address space, the same BO can be mapped in different address space if the BO is globally visible (GEM_FLINK) and opened in different context or if the dmabuf is self-imported. The current implementation does not take case into account, and attaches the mapping directly to the panfrost_gem_object. Let's create a panfrost_gem_mapping struct and allow multiple mappings per BO. The mappings are refcounted which helps solve another problem where mappings were torn down (GEM handle closed by userspace) while GPU jobs accessing those BOs were still in-flight. Jobs now keep a reference on the mappings they use. v2 (robh): - Minor review comment clean-ups from Steven - Use list_is_singular helper - Just WARN if we add a mapping when madvise state is not WILLNEED. With that, drop the use of object_name_lock. v3 (robh): - Revert returning list iterator in panfrost_gem_mapping_get() Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation") Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: Signed-off-by: Boris Brezillon Signed-off-by: Rob Herring Acked-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20200116021554.15090-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8c40a8d7d38444ce8f0ba7be9689ff5d254d71a3 Author: Alex Deucher Date: Tue Jan 14 17:09:28 2020 -0600 PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken commit 5e89cd303e3a4505752952259b9f1ba036632544 upstream. To account for parts of the chip that are "harvested" (disabled) due to silicon flaws, caches on some AMD GPUs must be initialized before ATS is enabled. ATS is normally enabled by the IOMMU driver before the GPU driver loads, so this cache initialization would have to be done in a quirk, but that's too complex to be practical. For Navi14 (device ID 0x7340), this initialization is done by the VBIOS, but apparently some boards went to production with an older VBIOS that doesn't do it. Disable ATS for those boards. Link: https://lore.kernel.org/r/20200114205523.1054271-3-alexander.deucher@amd.com Bug: https://gitlab.freedesktop.org/drm/amd/issues/1015 See-also: d28ca864c493 ("PCI: Mark AMD Stoney Radeon R7 GPU ATS as broken") See-also: 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken") [bhelgaas: squash into one patch, simplify slightly, commit log] Signed-off-by: Alex Deucher Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fdd0f3b0e98badb7eb2428252f83c2acb494e176 Author: Jeff Layton Date: Wed Apr 3 13:16:01 2019 -0400 ceph: hold extra reference to r_parent over life of request commit 9c1c2b35f1d94de8325344c2777d7ee67492db3b upstream. Currently, we just assume that it will stick around by virtue of the submitter's reference, but later patches will allow the syscall to return early and we can't rely on that reference at that point. While I'm not aware of any reports of it, Xiubo pointed out that this may fix a use-after-free. If the wait for a reply times out or is canceled via signal, and then the reply comes in after the syscall returns, the client can end up trying to access r_parent without a reference. Take an extra reference to the inode when setting r_parent and release it when releasing the request. Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 19d0cd2127428aa755907aa05828f6698e48cf87 Author: Guenter Roeck Date: Thu Jan 16 10:44:17 2020 -0800 hwmon: (core) Do not use device managed functions for memory allocations commit 3bf8bdcf3bada771eb12b57f2a30caee69e8ab8d upstream. The hwmon core uses device managed functions, tied to the hwmon parent device, for various internal memory allocations. This is problematic since hwmon device lifetime does not necessarily match its parent's device lifetime. If there is a mismatch, memory leaks will accumulate until the parent device is released. Fix the problem by managing all memory allocations internally. The only exception is memory allocation for thermal device registration, which can be tied to the hwmon device, along with thermal device registration itself. Fixes: d560168b5d0f ("hwmon: (core) New hwmon registration API") Cc: stable@vger.kernel.org # v4.14.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem Cc: stable@vger.kernel.org # v4.14.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register() Cc: stable@vger.kernel.org # v4.9.x: 3a412d5e4a1c: hwmon: (core) Simplify sysfs attribute name allocation Cc: stable@vger.kernel.org # v4.9.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem Cc: stable@vger.kernel.org # v4.9.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register() Cc: stable@vger.kernel.org # v4.9+ Cc: Martin K. Petersen Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0387ee1b95d1cf21156dc73ccb7a34a8884b0958 Author: Luuk Paulussen Date: Fri Dec 6 12:16:59 2019 +1300 hwmon: (adt7475) Make volt2reg return same reg as reg2volt input commit cf3ca1877574a306c0207cbf7fdf25419d9229df upstream. reg2volt returns the voltage that matches a given register value. Converting this back the other way with volt2reg didn't return the same register value because it used truncation instead of rounding. This meant that values read from sysfs could not be written back to sysfs to set back the same register value. With this change, volt2reg will return the same value for every voltage previously returned by reg2volt (for the set of possible input values) Signed-off-by: Luuk Paulussen Link: https://lore.kernel.org/r/20191205231659.1301-1-luuk.paulussen@alliedtelesis.co.nz cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 2d00fec60c8d5c19b0c85936b47ec50ac7917bc5 Author: David Howells Date: Sun Jan 26 01:02:53 2020 +0000 afs: Fix characters allowed into cell names commit a45ea48e2bcd92c1f678b794f488ca0bda9835b8 upstream. The afs filesystem needs to prohibit certain characters from cell names, such as '/', as these are used to form filenames in procfs, leading to the following warning being generated: WARNING: CPU: 0 PID: 3489 at fs/proc/generic.c:178 Fix afs_alloc_cell() to disallow nonprintable characters, '/', '@' and names that begin with a dot. Remove the check for "@cell" as that is then redundant. This can be tested by running: echo add foo/.bar 1.2.3.4 >/proc/fs/afs/cells Note that we will also need to deal with: - Names ending in ".invalid" shouldn't be passed to the DNS. - Names that contain non-valid domainname chars shouldn't be passed to the DNS. - DNS replies that say "your-dns-needs-immediate-attention." and replies containing A records that say 127.0.53.53 should be considered invalid. [https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf] but these need to be dealt with by the kafs-client DNS program rather than the kernel. Reported-by: syzbot+b904ba7c947a37b4b291@syzkaller.appspotmail.com Cc: stable@kernel.org Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b29d143a690a660b27e7e84c01dd541d38fe9372 Author: Jens Axboe Date: Sun Jan 26 09:53:12 2020 -0700 Revert "io_uring: only allow submit from owning task" commit 73e08e711d9c1d79fae01daed4b0e1fee5f8a275 upstream. This ends up being too restrictive for tasks that willingly fork and share the ring between forks. Andres reports that this breaks his postgresql work. Since we're close to 5.5 release, revert this change for now. Cc: stable@vger.kernel.org Fixes: 44d282796f81 ("io_uring: only allow submit from owning task") Reported-by: Andres Freund Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 29ce06b6b6d45ce461ddb723502a0827b8d8c9fb Author: David Ahern Date: Fri Jan 10 09:03:58 2020 -0800 ipv4: Detect rollover in specific fib table dump [ Upstream commit 9827c0634e461703abf81e8cc8b7adf5da5886d0 ] Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has been added to a table. The looping is caused by the key rolling over from FFFFFFFF to 0. When dumping a specific table only, we need a means to detect when the table dump is done. The key and count saved to cb args are both 0 only at the start of the table dump. If key is 0 and count > 0, then we are in the rollover case. Detect and return to avoid looping. This only affects dumps of a specific table; for dumps of all tables (the case prior to the change in the Fixes tag) inet_dump_fib moved the entry counter to the next table and reset the cb args used by fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back to 0 did not cause looping with the dumps. Fixes: effe67926624 ("net: Enable kernel side filtering of route dumps") Reported-by: Sven-Haegar Koch Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9bd7ae7eab7cddbb7fa68cc9319829e5374316fa Author: Tariq Toukan Date: Mon Jan 20 13:42:00 2020 +0200 net/mlx5e: kTLS, Do not send decrypted-marked SKBs via non-accel path commit 342508c1c7540e281fd36151c175ba5ff954a99f upstream. When TCP out-of-order is identified (unexpected tcp seq mismatch), driver analyzes the packet and decides what handling should it get: 1. go to accelerated path (to be encrypted in HW), 2. go to regular xmit path (send w/o encryption), 3. drop. Packets marked with skb->decrypted by the TLS stack in the TX flow skips SW encryption, and rely on the HW offload. Verify that such packets are never sent un-encrypted on the wire. Add a WARN to catch such bugs, and prefer dropping the packet in these cases. Fixes: 46a3ea98074e ("net/mlx5e: kTLS, Enhance TX resync flow") Signed-off-by: Tariq Toukan Signed-off-by: Boris Pismenny Reviewed-by: Boris Pismenny Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 43eda24c6f75cdeaf7780fdb18142d5a45601d02 Author: Tariq Toukan Date: Mon Jan 13 14:46:09 2020 +0200 net/mlx5e: kTLS, Remove redundant posts in TX resync flow commit 1e92899791358dba94a9db7cc3b6004636b5a2f6 upstream. The call to tx_post_resync_params() is done earlier in the flow, the post of the control WQEs is unnecessarily repeated. Remove it. Fixes: 700ec4974240 ("net/mlx5e: kTLS, Fix missing SQ edge fill") Signed-off-by: Tariq Toukan Signed-off-by: Boris Pismenny Reviewed-by: Boris Pismenny Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 384faad2ad5a49c56e4e7c931533f7e2a6368f84 Author: Tariq Toukan Date: Sun Jan 12 16:22:14 2020 +0200 net/mlx5e: kTLS, Fix corner-case checks in TX resync flow commit ffbd9ca94e2ebbfe802d4b28bab5ba19818de853 upstream. There are the following cases: 1. Packet ends before start marker: bypass offload. 2. Packet starts before start marker and ends after it: drop, not supported, breaks contract with kernel. 3. packet ends before tls record info starts: drop, this packet was already acknowledged and its record info was released. Add the above as comment in code. Mind possible wraparounds of the TCP seq, replace the simple comparison with a call to the TCP before() method. In addition, remove logic that handles negative sync_len values, as it became impossible. Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support") Fixes: 46a3ea98074e ("net/mlx5e: kTLS, Enhance TX resync flow") Signed-off-by: Tariq Toukan Signed-off-by: Boris Pismenny Reviewed-by: Boris Pismenny Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 7ae31c620dcc6cc8efbe3db5e2f261af42403814 Author: Erez Shitrit Date: Sun Jan 12 08:57:59 2020 +0200 net/mlx5: DR, use non preemptible call to get the current cpu number commit c0702a4bd41829f05638ec2dab70f6bb8d8010ce upstream. Use raw_smp_processor_id instead of smp_processor_id() otherwise we will get the following trace in debug-kernel: BUG: using smp_processor_id() in preemptible [00000000] code: devlink caller is dr_create_cq.constprop.2+0x31d/0x970 [mlx5_core] Call Trace: dump_stack+0x9a/0xf0 debug_smp_processor_id+0x1f3/0x200 dr_create_cq.constprop.2+0x31d/0x970 genl_family_rcv_msg+0x5fd/0x1170 genl_rcv_msg+0xb8/0x160 netlink_rcv_skb+0x11e/0x340 Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue RDMA operations") Signed-off-by: Erez Shitrit Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 8a3b1a86d4f3828160f48a56a33c090e557e4539 Author: Eli Cohen Date: Sun Jan 12 13:43:37 2020 +0200 net/mlx5: E-Switch, Prevent ingress rate configuration of uplink rep commit e401a1848be87123a2b2049addbf21138cb47081 upstream. Since the implementation relies on limiting the VF transmit rate to simulate ingress rate limiting, and since either uplink representor or ecpf are not associated with a VF, we limit the rate limit configuration for those ports. Fixes: fcb64c0f5640 ("net/mlx5: E-Switch, add ingress rate support") Signed-off-by: Eli Cohen Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit b20f5fb7d473ef06a7c19d7f193ec5c4b34342c2 Author: Erez Shitrit Date: Wed Jan 8 14:17:32 2020 +0200 net/mlx5: DR, Enable counter on non-fwd-dest objects commmit b850a82114df9b0ec1d191dc64eed1f20a772e0f upstream. The current code handles only counters that attached to dest, we still have the cases where we have counter on non-dest, like over drop etc. Fixes: 6a48faeeca10 ("net/mlx5: Add direct rule fs_cmd implementation") Signed-off-by: Hamdan Igbaria Signed-off-by: Erez Shitrit Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit ffc574c95e5bb3c247def6da00b2ce6358496ac0 Author: Meir Lichtinger Date: Thu Dec 12 16:09:33 2019 +0200 net/mlx5: Update the list of the PCI supported devices commit 505a7f5478062c6cd11e22022d9f1bf64cd8eab3 upstream Add the upcoming ConnectX-7 device ID. Fixes: 85327a9c4150 ("net/mlx5: Update the list of the PCI supported devices") Signed-off-by: Meir Lichtinger Reviewed-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 36940c4daad0f8668234eb6f4f33c87fc8a01eef Author: Paul Blakey Date: Tue Dec 31 17:04:15 2019 +0200 net/mlx5: Fix lowest FDB pool size commit 93b8a7ecb7287cc9b0196f12a25b57c2462d11dc upstream. The pool sizes represent the pool sizes in the fw. when we request a pool size from fw, it will return the next possible group. We track how many pools the fw has left and start requesting groups from the big to the small. When we start request 4k group, which doesn't exists in fw, fw wants to allocate the next possible size, 64k, but will fail since its exhausted. The correct smallest pool size in fw is 128 and not 4k. Fixes: e52c28024008 ("net/mlx5: E-Switch, Add chains and priorities") Signed-off-by: Paul Blakey Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit d18d22ce8f62839365c984b1df474d3975ed4eb2 Author: Maxim Mikityanskiy Date: Tue Jan 21 15:09:40 2020 +0000 net: Fix packet reordering caused by GRO and listified RX cooperation [ Upstream commit c80794323e82ac6ab45052ebba5757ce47b4b588 ] Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs") introduces batching of GRO_NORMAL packets in napi_frags_finish, and commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()") adds the same to napi_skb_finish. However, dev_gro_receive (that is called just before napi_{frags,skb}_finish) can also pass skbs to the networking stack: e.g., when the GRO session is flushed, napi_gro_complete is called, which passes pp directly to netif_receive_skb_internal, skipping napi->rx_list. It means that the packet stored in pp will be handled by the stack earlier than the packets that arrived before, but are still waiting in napi->rx_list. It leads to TCP reorderings that can be observed in the TCPOFOQueue counter in netstat. This commit fixes the reordering issue by making napi_gro_complete also use napi->rx_list, so that all packets going through GRO will keep their order. In order to keep napi_gro_flush working properly, gro_normal_list calls are moved after the flush to clear napi->rx_list. iwlwifi calls napi_gro_flush directly and does the same thing that is done by gro_normal_list, so the same change is applied there: napi_gro_flush is moved to be before the flush of napi->rx_list. A few other drivers also use napi_gro_flush (brocade/bna/bnad.c, cortina/gemini.c, hisilicon/hns3/hns3_enet.c). The first two also use napi_complete_done afterwards, which performs the gro_normal_list flush, so they are fine. The latter calls napi_gro_receive right after napi_gro_flush, so it can end up with non-empty napi->rx_list anyway. Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs") Signed-off-by: Maxim Mikityanskiy Cc: Alexander Lobakin Cc: Edward Cree Acked-by: Alexander Lobakin Acked-by: Saeed Mahameed Acked-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8bc3025206165141cf7937f487fd0275479d5562 Author: Kristian Evensen Date: Thu Jan 23 13:20:18 2020 +0100 fou: Fix IPv6 netlink policy [ Upstream commit bb48eb9b12a95db9d679025927269d4adda6dbd1 ] When submitting v2 of "fou: Support binding FoU socket" (1713cb37bf67), I accidentally sent the wrong version of the patch and one fix was missing. In the initial version of the patch, as well as the version 2 that I submitted, I incorrectly used ".type" for the two V6-attributes. The correct is to use ".len". Reported-by: Dmitry Vyukov Fixes: 1713cb37bf67 ("fou: Support binding FoU socket") Signed-off-by: Kristian Evensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7b6ef675c46d275250c66a516accd41cde7c0e6 Author: Ido Schimmel Date: Wed Jan 22 20:09:52 2020 +0200 mlxsw: spectrum_acl: Fix use-after-free during reload [ Upstream commit 971de2e572118c1128bff295341e37b6c8b8f108 ] During reload (or module unload), the router block is de-initialized. Among other things, this results in the removal of a default multicast route from each active virtual router (VRF). These default routes are configured during initialization to trap packets to the CPU. In Spectrum-2, unlike Spectrum-1, multicast routes are implemented using ACL rules. Since the router block is de-initialized before the ACL block, it is possible that the ACL rules corresponding to the default routes are deleted while being accessed by the ACL delayed work that queries rules' activity from the device. This can result in a rare use-after-free [1]. Fix this by protecting the rules list accessed by the delayed work with a lock. We cannot use a spinlock as the activity read operation is blocking. [1] [ 123.331662] ================================================================== [ 123.339920] BUG: KASAN: use-after-free in mlxsw_sp_acl_rule_activity_update_work+0x330/0x3b0 [ 123.349381] Read of size 8 at addr ffff8881f3bb4520 by task kworker/0:2/78 [ 123.357080] [ 123.358773] CPU: 0 PID: 78 Comm: kworker/0:2 Not tainted 5.5.0-rc5-custom-33108-gf5df95d3ef41 #2209 [ 123.368898] Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 [ 123.378456] Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work [ 123.385970] Call Trace: [ 123.388734] dump_stack+0xc6/0x11e [ 123.392568] print_address_description.constprop.4+0x21/0x340 [ 123.403236] __kasan_report.cold.8+0x76/0xb1 [ 123.414884] kasan_report+0xe/0x20 [ 123.418716] mlxsw_sp_acl_rule_activity_update_work+0x330/0x3b0 [ 123.444034] process_one_work+0xb06/0x19a0 [ 123.453731] worker_thread+0x91/0xe90 [ 123.467348] kthread+0x348/0x410 [ 123.476847] ret_from_fork+0x24/0x30 [ 123.480863] [ 123.482545] Allocated by task 73: [ 123.486273] save_stack+0x19/0x80 [ 123.490000] __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 123.495379] mlxsw_sp_acl_rule_create+0xa7/0x230 [ 123.500566] mlxsw_sp2_mr_tcam_route_create+0xf6/0x3e0 [ 123.506334] mlxsw_sp_mr_tcam_route_create+0x5b4/0x820 [ 123.512102] mlxsw_sp_mr_table_create+0x3b5/0x690 [ 123.517389] mlxsw_sp_vr_get+0x289/0x4d0 [ 123.521797] mlxsw_sp_fib_node_get+0xa2/0x990 [ 123.526692] mlxsw_sp_router_fib4_event_work+0x54c/0x2d60 [ 123.532752] process_one_work+0xb06/0x19a0 [ 123.537352] worker_thread+0x91/0xe90 [ 123.541471] kthread+0x348/0x410 [ 123.545103] ret_from_fork+0x24/0x30 [ 123.549113] [ 123.550795] Freed by task 518: [ 123.554231] save_stack+0x19/0x80 [ 123.557958] __kasan_slab_free+0x125/0x170 [ 123.562556] kfree+0xd7/0x3a0 [ 123.565895] mlxsw_sp_acl_rule_destroy+0x63/0xd0 [ 123.571081] mlxsw_sp2_mr_tcam_route_destroy+0xd5/0x130 [ 123.576946] mlxsw_sp_mr_tcam_route_destroy+0xba/0x260 [ 123.582714] mlxsw_sp_mr_table_destroy+0x1ab/0x290 [ 123.588091] mlxsw_sp_vr_put+0x1db/0x350 [ 123.592496] mlxsw_sp_fib_node_put+0x298/0x4c0 [ 123.597486] mlxsw_sp_vr_fib_flush+0x15b/0x360 [ 123.602476] mlxsw_sp_router_fib_flush+0xba/0x470 [ 123.607756] mlxsw_sp_vrs_fini+0xaa/0x120 [ 123.612260] mlxsw_sp_router_fini+0x137/0x384 [ 123.617152] mlxsw_sp_fini+0x30a/0x4a0 [ 123.621374] mlxsw_core_bus_device_unregister+0x159/0x600 [ 123.627435] mlxsw_devlink_core_bus_device_reload_down+0x7e/0xb0 [ 123.634176] devlink_reload+0xb4/0x380 [ 123.638391] devlink_nl_cmd_reload+0x610/0x700 [ 123.643382] genl_rcv_msg+0x6a8/0xdc0 [ 123.647497] netlink_rcv_skb+0x134/0x3a0 [ 123.651904] genl_rcv+0x29/0x40 [ 123.655436] netlink_unicast+0x4d4/0x700 [ 123.659843] netlink_sendmsg+0x7c0/0xc70 [ 123.664251] __sys_sendto+0x265/0x3c0 [ 123.668367] __x64_sys_sendto+0xe2/0x1b0 [ 123.672773] do_syscall_64+0xa0/0x530 [ 123.676892] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 123.682552] [ 123.684238] The buggy address belongs to the object at ffff8881f3bb4500 [ 123.684238] which belongs to the cache kmalloc-128 of size 128 [ 123.698261] The buggy address is located 32 bytes inside of [ 123.698261] 128-byte region [ffff8881f3bb4500, ffff8881f3bb4580) [ 123.711303] The buggy address belongs to the page: [ 123.716682] page:ffffea0007ceed00 refcount:1 mapcount:0 mapping:ffff888236403500 index:0x0 [ 123.725958] raw: 0200000000000200 dead000000000100 dead000000000122 ffff888236403500 [ 123.734646] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 [ 123.743315] page dumped because: kasan: bad access detected [ 123.749562] [ 123.751241] Memory state around the buggy address: [ 123.756620] ffff8881f3bb4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 123.764716] ffff8881f3bb4480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 123.772812] >ffff8881f3bb4500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 123.780904] ^ [ 123.785697] ffff8881f3bb4580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 123.793793] ffff8881f3bb4600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 123.801883] ================================================================== Fixes: cf7221a4f5a5 ("mlxsw: spectrum_router: Add Multicast routing support for Spectrum-2") Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ef3c0a1660a7d52fbcd1a417915bb5f06c72117a Author: Michael Ellerman Date: Wed Jan 22 15:07:28 2020 +1100 airo: Add missing CAP_NET_ADMIN check in AIROOLDIOCTL/SIOCDEVPRIVATE [ Upstream commit 78f7a7566f5eb59321e99b55a6fdb16ea05b37d1 ] The driver for Cisco Aironet 4500 and 4800 series cards (airo.c), implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl(). The ioctl handler copies an aironet_ioctl struct from userspace, which includes a command. Some of the commands are handled in readrids(), where the user controlled command is converted into a driver-internal value called "ridcode". There are two command values, AIROGWEPKTMP and AIROGWEPKNV, which correspond to ridcode values of RID_WEP_TEMP and RID_WEP_PERM respectively. These commands both have checks that the user has CAP_NET_ADMIN, with the comment that "Only super-user can read WEP keys", otherwise they return -EPERM. However there is another command value, AIRORRID, that lets the user specify the ridcode value directly, with no other checks. This means the user can bypass the CAP_NET_ADMIN check on AIROGWEPKTMP and AIROGWEPKNV. Fix it by moving the CAP_NET_ADMIN check out of the command handling and instead do it later based on the ridcode. That way regardless of whether the ridcode is set via AIROGWEPKTMP or AIROGWEPKNV, or passed in using AIRORID, we always do the CAP_NET_ADMIN check. Found by Ilja by code inspection, not tested as I don't have the required hardware. Reported-by: Ilja Van Sprundel Signed-off-by: Michael Ellerman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9975b19b8d82841077af1d5643c5a0a5599d2e02 Author: Michael Ellerman Date: Wed Jan 22 15:07:27 2020 +1100 airo: Fix possible info leak in AIROOLDIOCTL/SIOCDEVPRIVATE [ Upstream commit d6bce2137f5d6bb1093e96d2f801479099b28094 ] The driver for Cisco Aironet 4500 and 4800 series cards (airo.c), implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl(). The ioctl handler copies an aironet_ioctl struct from userspace, which includes a command and a length. Some of the commands are handled in readrids(), which kmalloc()'s a buffer of RIDSIZE (2048) bytes. That buffer is then passed to PC4500_readrid(), which has two cases. The else case does some setup and then reads up to RIDSIZE bytes from the hardware into the kmalloc()'ed buffer. Here len == RIDSIZE, pBuf is the kmalloc()'ed buffer: // read the rid length field bap_read(ai, pBuf, 2, BAP1); // length for remaining part of rid len = min(len, (int)le16_to_cpu(*(__le16*)pBuf)) - 2; ... // read remainder of the rid rc = bap_read(ai, ((__le16*)pBuf)+1, len, BAP1); PC4500_readrid() then returns to readrids() which does: len = comp->len; if (copy_to_user(comp->data, iobuf, min(len, (int)RIDSIZE))) { Where comp->len is the user controlled length field. So if the "rid length field" returned by the hardware is < 2048, and the user requests 2048 bytes in comp->len, we will leak the previous contents of the kmalloc()'ed buffer to userspace. Fix it by kzalloc()'ing the buffer. Found by Ilja by code inspection, not tested as I don't have the required hardware. Reported-by: Ilja Van Sprundel Signed-off-by: Michael Ellerman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a802ddbf41a3ba8dc5b05120f173c096dc54bd30 Author: Eric Dumazet Date: Wed Jan 22 09:07:35 2020 -0800 tun: add mutex_unlock() call and napi.skb clearing in tun_get_user() [ Upstream commit 1efba987c48629c0c64703bb4ea76ca1a3771d17 ] If both IFF_NAPI_FRAGS mode and XDP are enabled, and the XDP program consumes the skb, we need to clear the napi.skb (or risk a use-after-free) and release the mutex (or risk a deadlock) WARNING: lock held when returning to user space! 5.5.0-rc6-syzkaller #0 Not tainted ------------------------------------------------ syz-executor.0/455 is leaving the kernel with locks still held! 1 lock held by syz-executor.0/455: #0: ffff888098f6e748 (&tfile->napi_mutex){+.+.}, at: tun_get_user+0x1604/0x3fc0 drivers/net/tun.c:1835 Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Petar Penkov Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 69486bfa064e77895392be3ad6a7b29d22556668 Author: Eric Dumazet Date: Wed Jan 22 21:03:00 2020 -0800 tcp: do not leave dangling pointers in tp->highest_sack [ Upstream commit 2bec445f9bf35e52e395b971df48d3e1e5dc704a ] Latest commit 853697504de0 ("tcp: Fix highest_sack and highest_sack_seq") apparently allowed syzbot to trigger various crashes in TCP stack [1] I believe this commit only made things easier for syzbot to find its way into triggering use-after-frees. But really the bugs could lead to bad TCP behavior or even plain crashes even for non malicious peers. I have audited all calls to tcp_rtx_queue_unlink() and tcp_rtx_queue_unlink_and_free() and made sure tp->highest_sack would be updated if we are removing from rtx queue the skb that tp->highest_sack points to. These updates were missing in three locations : 1) tcp_clean_rtx_queue() [This one seems quite serious, I have no idea why this was not caught earlier] 2) tcp_rtx_queue_purge() [Probably not a big deal for normal operations] 3) tcp_send_synack() [Probably not a big deal for normal operations] [1] BUG: KASAN: use-after-free in tcp_highest_sack_seq include/net/tcp.h:1864 [inline] BUG: KASAN: use-after-free in tcp_highest_sack_seq include/net/tcp.h:1856 [inline] BUG: KASAN: use-after-free in tcp_check_sack_reordering+0x33c/0x3a0 net/ipv4/tcp_input.c:891 Read of size 4 at addr ffff8880a488d068 by task ksoftirqd/1/16 CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:134 tcp_highest_sack_seq include/net/tcp.h:1864 [inline] tcp_highest_sack_seq include/net/tcp.h:1856 [inline] tcp_check_sack_reordering+0x33c/0x3a0 net/ipv4/tcp_input.c:891 tcp_try_undo_partial net/ipv4/tcp_input.c:2730 [inline] tcp_fastretrans_alert+0xf74/0x23f0 net/ipv4/tcp_input.c:2847 tcp_ack+0x2577/0x5bf0 net/ipv4/tcp_input.c:3710 tcp_rcv_established+0x6dd/0x1e90 net/ipv4/tcp_input.c:5706 tcp_v4_do_rcv+0x619/0x8d0 net/ipv4/tcp_ipv4.c:1619 tcp_v4_rcv+0x307f/0x3b40 net/ipv4/tcp_ipv4.c:2001 ip_protocol_deliver_rcu+0x5a/0x880 net/ipv4/ip_input.c:204 ip_local_deliver_finish+0x23b/0x380 net/ipv4/ip_input.c:231 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:252 dst_input include/net/dst.h:442 [inline] ip_rcv_finish+0x1db/0x2f0 net/ipv4/ip_input.c:428 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:538 __netif_receive_skb_one_core+0x113/0x1a0 net/core/dev.c:5148 __netif_receive_skb+0x2c/0x1d0 net/core/dev.c:5262 process_backlog+0x206/0x750 net/core/dev.c:6093 napi_poll net/core/dev.c:6530 [inline] net_rx_action+0x508/0x1120 net/core/dev.c:6598 __do_softirq+0x262/0x98c kernel/softirq.c:292 run_ksoftirqd kernel/softirq.c:603 [inline] run_ksoftirqd+0x8e/0x110 kernel/softirq.c:595 smpboot_thread_fn+0x6a3/0xa40 kernel/smpboot.c:165 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 10091: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc mm/kasan/common.c:513 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:521 slab_post_alloc_hook mm/slab.h:584 [inline] slab_alloc_node mm/slab.c:3263 [inline] kmem_cache_alloc_node+0x138/0x740 mm/slab.c:3575 __alloc_skb+0xd5/0x5e0 net/core/skbuff.c:198 alloc_skb_fclone include/linux/skbuff.h:1099 [inline] sk_stream_alloc_skb net/ipv4/tcp.c:875 [inline] sk_stream_alloc_skb+0x113/0xc90 net/ipv4/tcp.c:852 tcp_sendmsg_locked+0xcf9/0x3470 net/ipv4/tcp.c:1282 tcp_sendmsg+0x30/0x50 net/ipv4/tcp.c:1432 inet_sendmsg+0x9e/0xe0 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:672 __sys_sendto+0x262/0x380 net/socket.c:1998 __do_sys_sendto net/socket.c:2010 [inline] __se_sys_sendto net/socket.c:2006 [inline] __x64_sys_sendto+0xe1/0x1a0 net/socket.c:2006 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 10095: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:335 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474 kasan_slab_free+0xe/0x10 mm/kasan/common.c:483 __cache_free mm/slab.c:3426 [inline] kmem_cache_free+0x86/0x320 mm/slab.c:3694 kfree_skbmem+0x178/0x1c0 net/core/skbuff.c:645 __kfree_skb+0x1e/0x30 net/core/skbuff.c:681 sk_eat_skb include/net/sock.h:2453 [inline] tcp_recvmsg+0x1252/0x2930 net/ipv4/tcp.c:2166 inet_recvmsg+0x136/0x610 net/ipv4/af_inet.c:838 sock_recvmsg_nosec net/socket.c:886 [inline] sock_recvmsg net/socket.c:904 [inline] sock_recvmsg+0xce/0x110 net/socket.c:900 __sys_recvfrom+0x1ff/0x350 net/socket.c:2055 __do_sys_recvfrom net/socket.c:2073 [inline] __se_sys_recvfrom net/socket.c:2069 [inline] __x64_sys_recvfrom+0xe1/0x1a0 net/socket.c:2069 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880a488d040 which belongs to the cache skbuff_fclone_cache of size 456 The buggy address is located 40 bytes inside of 456-byte region [ffff8880a488d040, ffff8880a488d208) The buggy address belongs to the page: page:ffffea0002922340 refcount:1 mapcount:0 mapping:ffff88821b057000 index:0x0 raw: 00fffe0000000200 ffffea00022a5788 ffffea0002624a48 ffff88821b057000 raw: 0000000000000000 ffff8880a488d040 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a488cf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8880a488cf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880a488d000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8880a488d080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a488d100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 853697504de0 ("tcp: Fix highest_sack and highest_sack_seq") Fixes: 50895b9de1d3 ("tcp: highest_sack fix") Fixes: 737ff314563c ("tcp: use sequence distance to detect reordering") Signed-off-by: Eric Dumazet Cc: Cambda Zhu Cc: Yuchung Cheng Cc: Neal Cardwell Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 562a7c35049c82f2422366f24c4e4a9520a5a450 Author: Wen Yang Date: Mon Jan 20 18:04:56 2020 +0800 tcp_bbr: improve arithmetic division in bbr_update_bw() [ Upstream commit 5b2f1f3070b6447b76174ea8bfb7390dc6253ebd ] do_div() does a 64-by-32 division. Use div64_long() instead of it if the divisor is long, to avoid truncation to 32-bit. And as a nice side effect also cleans up the function a bit. Signed-off-by: Wen Yang Cc: Eric Dumazet Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: Hideaki YOSHIFUJI Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 41c230ae2aa4ff9ca33afef22e705d67d45b16f6 Author: Paolo Abeni Date: Tue Jan 21 16:50:49 2020 +0100 Revert "udp: do rmem bulk free even if the rx sk queue is empty" [ Upstream commit d39ca2590d10712f412add7a88e1dd467a7246f4 ] This reverts commit 0d4a6608f68c7532dcbfec2ea1150c9761767d03. Willem reported that after commit 0d4a6608f68c ("udp: do rmem bulk free even if the rx sk queue is empty") the memory allocated by an almost idle system with many UDP sockets can grow a lot. For stable kernel keep the solution as simple as possible and revert the offending commit. Reported-by: Willem de Bruijn Diagnosed-by: Eric Dumazet Fixes: 0d4a6608f68c ("udp: do rmem bulk free even if the rx sk queue is empty") Signed-off-by: Paolo Abeni Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 63635790a8911c1cc284508e8b9709cedf17cdb7 Author: James Hughes Date: Mon Jan 20 11:12:40 2020 +0000 net: usb: lan78xx: Add .ndo_features_check [ Upstream commit ce896476c65d72b4b99fa09c2f33436b4198f034 ] As reported by Eric Dumazet, there are still some outstanding cases where the driver does not handle TSO correctly when skb's are over a certain size. Most cases have been fixed, this patch should ensure that forwarded SKB's that are greater than MAX_SINGLE_PACKET_SIZE - TX_OVERHEAD are software segmented and handled correctly. Signed-off-by: James Hughes Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d6f7ed61fa6e64fd25b8488463fad96966d87497 Author: Jouni Hogander Date: Mon Jan 20 09:51:03 2020 +0200 net-sysfs: Fix reference count leak [ Upstream commit cb626bf566eb4433318d35681286c494f04fedcc ] Netdev_register_kobject is calling device_initialize. In case of error reference taken by device_initialize is not given up. Drivers are supposed to call free_netdev in case of error. In non-error case the last reference is given up there and device release sequence is triggered. In error case this reference is kept and the release sequence is never started. Fix this by setting reg_state as NETREG_UNREGISTERED if registering fails. This is the rootcause for couple of memory leaks reported by Syzkaller: BUG: memory leak unreferenced object 0xffff8880675ca008 (size 256): comm "netdev_register", pid 281, jiffies 4294696663 (age 6.808s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000058ca4711>] kmem_cache_alloc_trace+0x167/0x280 [<000000002340019b>] device_add+0x882/0x1750 [<000000001d588c3a>] netdev_register_kobject+0x128/0x380 [<0000000011ef5535>] register_netdevice+0xa1b/0xf00 [<000000007fcf1c99>] __tun_chr_ioctl+0x20d5/0x3dd0 [<000000006a5b7b2b>] tun_chr_ioctl+0x2f/0x40 [<00000000f30f834a>] do_vfs_ioctl+0x1c7/0x1510 [<00000000fba062ea>] ksys_ioctl+0x99/0xb0 [<00000000b1c1b8d2>] __x64_sys_ioctl+0x78/0xb0 [<00000000984cabb9>] do_syscall_64+0x16f/0x580 [<000000000bde033d>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<00000000e6ca2d9f>] 0xffffffffffffffff BUG: memory leak unreferenced object 0xffff8880668ba588 (size 8): comm "kobject_set_nam", pid 286, jiffies 4294725297 (age 9.871s) hex dump (first 8 bytes): 6e 72 30 00 cc be df 2b nr0....+ backtrace: [<00000000a322332a>] __kmalloc_track_caller+0x16e/0x290 [<00000000236fd26b>] kstrdup+0x3e/0x70 [<00000000dd4a2815>] kstrdup_const+0x3e/0x50 [<0000000049a377fc>] kvasprintf_const+0x10e/0x160 [<00000000627fc711>] kobject_set_name_vargs+0x5b/0x140 [<0000000019eeab06>] dev_set_name+0xc0/0xf0 [<0000000069cb12bc>] netdev_register_kobject+0xc8/0x320 [<00000000f2e83732>] register_netdevice+0xa1b/0xf00 [<000000009e1f57cc>] __tun_chr_ioctl+0x20d5/0x3dd0 [<000000009c560784>] tun_chr_ioctl+0x2f/0x40 [<000000000d759e02>] do_vfs_ioctl+0x1c7/0x1510 [<00000000351d7c31>] ksys_ioctl+0x99/0xb0 [<000000008390040a>] __x64_sys_ioctl+0x78/0xb0 [<0000000052d196b7>] do_syscall_64+0x16f/0x580 [<0000000019af9236>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<00000000bc384531>] 0xffffffffffffffff v3 -> v4: Set reg_state to NETREG_UNREGISTERED if registering fails v2 -> v3: * Replaced BUG_ON with WARN_ON in free_netdev and netdev_release v1 -> v2: * Relying on driver calling free_netdev rather than calling put_device directly in error path Reported-by: syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com Cc: David Miller Cc: Greg Kroah-Hartman Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9b60a32108e2ec263b5c27b2396e92ee8d773f3b Author: Eric Dumazet Date: Tue Jan 21 11:02:20 2020 -0800 net_sched: use validated TCA_KIND attribute in tc_new_tfilter() [ Upstream commit 36d79af7fb59d6d9106feb9c1855eb93d6d53fe6 ] sysbot found another issue in tc_new_tfilter(). We probably should use @name which contains the sanitized version of TCA_KIND. BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:608 [inline] BUG: KMSAN: uninit-value in string+0x522/0x690 lib/vsprintf.c:689 CPU: 1 PID: 10753 Comm: syz-executor.1 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 string_nocheck lib/vsprintf.c:608 [inline] string+0x522/0x690 lib/vsprintf.c:689 vsnprintf+0x207d/0x31b0 lib/vsprintf.c:2574 __request_module+0x2ad/0x11c0 kernel/kmod.c:143 tcf_proto_lookup_ops+0x241/0x720 net/sched/cls_api.c:139 tcf_proto_create net/sched/cls_api.c:262 [inline] tc_new_tfilter+0x2a4e/0x5010 net/sched/cls_api.c:2058 rtnetlink_rcv_msg+0xcb7/0x1570 net/core/rtnetlink.c:5415 netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg net/socket.c:659 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330 ___sys_sendmsg net/socket.c:2384 [inline] __sys_sendmsg+0x451/0x5f0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45b349 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f88b3948c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f88b39496d4 RCX: 000000000045b349 RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003 RBP: 000000000075bfc8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 000000000000099f R14: 00000000004cb163 R15: 000000000075bfd4 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127 kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:82 slab_alloc_node mm/slub.c:2774 [inline] __kmalloc_node_track_caller+0xb40/0x1200 mm/slub.c:4382 __kmalloc_reserve net/core/skbuff.c:141 [inline] __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209 alloc_skb include/linux/skbuff.h:1049 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline] netlink_sendmsg+0x7d3/0x14d0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg net/socket.c:659 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330 ___sys_sendmsg net/socket.c:2384 [inline] __sys_sendmsg+0x451/0x5f0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 6f96c3c6904c ("net_sched: fix backward compatibility for TCA_KIND") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Cong Wang Cc: Marcelo Ricardo Leitner Cc: Jamal Hadi Salim Cc: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b6a9a954b3fea24386b46be1bf9f5b0ba32470db Author: Cong Wang Date: Wed Jan 22 15:42:02 2020 -0800 net_sched: fix datalen for ematch [ Upstream commit 61678d28d4a45ef376f5d02a839cc37509ae9281 ] syzbot reported an out-of-bound access in em_nbyte. As initially analyzed by Eric, this is because em_nbyte sets its own em->datalen in em_nbyte_change() other than the one specified by user, but this value gets overwritten later by its caller tcf_em_validate(). We should leave em->datalen untouched to respect their choices. I audit all the in-tree ematch users, all of those implement ->change() set em->datalen, so we can just avoid setting it twice in this case. Reported-and-tested-by: syzbot+5af9a90dad568aa9f611@syzkaller.appspotmail.com Reported-by: syzbot+2f07903a5b05e7f36410@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Eric Dumazet Signed-off-by: Cong Wang Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 888934af187cd7168545711027db64006e7dad9d Author: Eric Dumazet Date: Tue Jan 21 22:47:29 2020 -0800 net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link() [ Upstream commit d836f5c69d87473ff65c06a6123e5b2cf5e56f5b ] rtnl_create_link() needs to apply dev->min_mtu and dev->max_mtu checks that we apply in do_setlink() Otherwise malicious users can crash the kernel, for example after an integer overflow : BUG: KASAN: use-after-free in memset include/linux/string.h:365 [inline] BUG: KASAN: use-after-free in __alloc_skb+0x37b/0x5e0 net/core/skbuff.c:238 Write of size 32 at addr ffff88819f20b9c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 memset+0x24/0x40 mm/kasan/common.c:108 memset include/linux/string.h:365 [inline] __alloc_skb+0x37b/0x5e0 net/core/skbuff.c:238 alloc_skb include/linux/skbuff.h:1049 [inline] alloc_skb_with_frags+0x93/0x590 net/core/skbuff.c:5664 sock_alloc_send_pskb+0x7ad/0x920 net/core/sock.c:2242 sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2259 mld_newpack+0x1d7/0x7f0 net/ipv6/mcast.c:1609 add_grhead.isra.0+0x299/0x370 net/ipv6/mcast.c:1713 add_grec+0x7db/0x10b0 net/ipv6/mcast.c:1844 mld_send_cr net/ipv6/mcast.c:1970 [inline] mld_ifc_timer_expire+0x3d3/0x950 net/ipv6/mcast.c:2477 call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x6c3/0x1790 kernel/time/timer.c:1786 __do_softirq+0x262/0x98c kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x19b/0x1e0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x1a3/0x610 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61 Code: 98 6b ea f9 eb 8a cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 44 1c 60 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 34 1c 60 00 fb f4 cc 55 48 89 e5 41 57 41 56 41 55 41 54 53 e8 4e 5d 9a f9 e8 79 RSP: 0018:ffffffff89807ce8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13 RAX: 1ffffffff13266ae RBX: ffffffff8987a1c0 RCX: 0000000000000000 RDX: dffffc0000000000 RSI: 0000000000000006 RDI: ffffffff8987aa54 RBP: ffffffff89807d18 R08: ffffffff8987a1c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000 R13: ffffffff8a799980 R14: 0000000000000000 R15: 0000000000000000 arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:690 default_idle_call+0x84/0xb0 kernel/sched/idle.c:94 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x3c8/0x6e0 kernel/sched/idle.c:269 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:361 rest_init+0x23b/0x371 init/main.c:451 arch_call_rest_init+0xe/0x1b start_kernel+0x904/0x943 init/main.c:784 x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490 x86_64_start_kernel+0x77/0x7b arch/x86/kernel/head64.c:471 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:242 The buggy address belongs to the page: page:ffffea00067c82c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 raw: 057ffe0000000000 ffffea00067c82c8 ffffea00067c82c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88819f20b880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88819f20b900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88819f20b980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88819f20ba00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88819f20ba80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 500869d71822a4e05cef536f01b9005395369e65 Author: William Dauchy Date: Tue Jan 21 15:26:24 2020 +0100 net, ip_tunnel: fix namespaces move [ Upstream commit d0f418516022c32ecceaf4275423e5bd3f8743a9 ] in the same manner as commit 690afc165bb3 ("net: ip6_gre: fix moving ip6gre between namespaces"), fix namespace moving as it was broken since commit 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata."). Indeed, the ip6_gre commit removed the local flag for collect_md condition, so there is no reason to keep it for ip_gre/ip_tunnel. this patch will fix both ip_tunnel and ip_gre modules. Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.") Signed-off-by: William Dauchy Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ead0377f601ec3aae7965fb16da28685963a097b Author: William Dauchy Date: Tue Jan 21 21:49:54 2020 +0100 net, ip6_tunnel: fix namespaces move [ Upstream commit 5311a69aaca30fa849c3cc46fb25f75727fb72d0 ] in the same manner as commit d0f418516022 ("net, ip_tunnel: fix namespaces move"), fix namespace moving as it was broken since commit 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel"), but for ipv6 this time; there is no reason to keep it for ip6_tunnel. Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnel") Signed-off-by: William Dauchy Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7943bb0f06365cf5e32f3cf8a6b29eeae981fb8a Author: Niko Kortstrom Date: Thu Jan 16 11:43:27 2020 +0200 net: ip6_gre: fix moving ip6gre between namespaces [ Upstream commit 690afc165bb314354667f67157c1a1aea7dc797a ] Support for moving IPv4 GRE tunnels between namespaces was added in commit b57708add314 ("gre: add x-netns support"). The respective change for IPv6 tunnels, commit 22f08069e8b4 ("ip6gre: add x-netns support") did not drop NETIF_F_NETNS_LOCAL flag so moving them from one netns to another is still denied in IPv6 case. Drop NETIF_F_NETNS_LOCAL flag from ip6gre tunnels to allow moving ip6gre tunnel endpoints between network namespaces. Signed-off-by: Niko Kortstrom Acked-by: Nicolas Dichtel Acked-by: William Tu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6e524f4fad3e25e18e14a02cbd2f325d6375558 Author: Michael Ellerman Date: Fri Jan 24 20:41:44 2020 +1100 net: cxgb3_main: Add CAP_NET_ADMIN check to CHELSIO_GET_MEM [ Upstream commit 3546d8f1bbe992488ed91592cf6bf76e7114791a = The cxgb3 driver for "Chelsio T3-based gigabit and 10Gb Ethernet adapters" implements a custom ioctl as SIOCCHIOCTL/SIOCDEVPRIVATE in cxgb_extension_ioctl(). One of the subcommands of the ioctl is CHELSIO_GET_MEM, which appears to read memory directly out of the adapter and return it to userspace. It's not entirely clear what the contents of the adapter memory contains, but the assumption is that it shouldn't be accessible to all users. So add a CAP_NET_ADMIN check to the CHELSIO_GET_MEM case. Put it after the is_offload() check, which matches two of the other subcommands in the same function which also check for is_offload() and CAP_NET_ADMIN. Found by Ilja by code inspection, not tested as I don't have the required hardware. Reported-by: Ilja Van Sprundel Signed-off-by: Michael Ellerman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 32df8d0bf461586b57a7ae3d3c0714584b03e7e6 Author: Florian Fainelli Date: Thu Jan 23 09:49:34 2020 -0800 net: bcmgenet: Use netif_tx_napi_add() for TX NAPI [ Upstream commit 148965df1a990af98b2c84092c2a2274c7489284 ] Before commit 7587935cfa11 ("net: bcmgenet: move NAPI initialization to ring initialization") moved the code, this used to be netif_tx_napi_add(), but we lost that small semantic change in the process, restore that. Fixes: 7587935cfa11 ("net: bcmgenet: move NAPI initialization to ring initialization") Signed-off-by: Florian Fainelli Acked-by: Doug Berger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e2bd33937c507df324176da01a99448bf3864b4c Author: Yuki Taguchi Date: Mon Jan 20 13:48:37 2020 +0900 ipv6: sr: remove SKB_GSO_IPXIP6 on End.D* actions [ Upstream commit 62ebaeaedee7591c257543d040677a60e35c7aec ] After LRO/GRO is applied, SRv6 encapsulated packets have SKB_GSO_IPXIP6 feature flag, and this flag must be removed right after decapulation procedure. Currently, SKB_GSO_IPXIP6 flag is not removed on End.D* actions, which creates inconsistent packet state, that is, a normal TCP/IP packets have the SKB_GSO_IPXIP6 flag. This behavior can cause unexpected fallback to GSO on routing to netdevices that do not support SKB_GSO_IPXIP6. For example, on inter-VRF forwarding, decapsulated packets separated into small packets by GSO because VRF devices do not support TSO for packets with SKB_GSO_IPXIP6 flag, and this degrades forwarding performance. This patch removes encapsulation related GSO flags from the skb right after the End.D* action is applied. Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local") Signed-off-by: Yuki Taguchi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6cbb9683d7437f9c1ae96a7a8e3add38e0ed2560 Author: Eric Dumazet Date: Tue Jan 21 23:17:14 2020 -0800 gtp: make sure only SOCK_DGRAM UDP sockets are accepted [ Upstream commit 940ba14986657a50c15f694efca1beba31fa568f ] A malicious user could use RAW sockets and fool GTP using them as standard SOCK_DGRAM UDP sockets. BUG: KMSAN: uninit-value in udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline] BUG: KMSAN: uninit-value in setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85 CPU: 0 PID: 11262 Comm: syz-executor613 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 udp_tunnel_encap_enable include/net/udp_tunnel.h:174 [inline] setup_udp_tunnel_sock+0x45e/0x6f0 net/ipv4/udp_tunnel.c:85 gtp_encap_enable_socket+0x37f/0x5a0 drivers/net/gtp.c:827 gtp_encap_enable drivers/net/gtp.c:844 [inline] gtp_newlink+0xfb/0x1e50 drivers/net/gtp.c:666 __rtnl_newlink net/core/rtnetlink.c:3305 [inline] rtnl_newlink+0x2973/0x3920 net/core/rtnetlink.c:3363 rtnetlink_rcv_msg+0x1153/0x1570 net/core/rtnetlink.c:5424 netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg net/socket.c:659 [inline] ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330 ___sys_sendmsg net/socket.c:2384 [inline] __sys_sendmsg+0x451/0x5f0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x441359 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fff1cd0ac28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441359 RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003 RBP: 00000000006cb018 R08: 00000000004002c8 R09: 00000000004002c8 R10: 00000000004002c8 R11: 0000000000000246 R12: 00000000004020d0 R13: 0000000000402160 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags+0x3c/0x90 mm/kmsan/kmsan.c:144 kmsan_internal_alloc_meta_for_pages mm/kmsan/kmsan_shadow.c:307 [inline] kmsan_alloc_page+0x12a/0x310 mm/kmsan/kmsan_shadow.c:336 __alloc_pages_nodemask+0x57f2/0x5f60 mm/page_alloc.c:4800 alloc_pages_current+0x67d/0x990 mm/mempolicy.c:2207 alloc_pages include/linux/gfp.h:534 [inline] alloc_slab_page+0x111/0x12f0 mm/slub.c:1511 allocate_slab mm/slub.c:1656 [inline] new_slab+0x2bc/0x1130 mm/slub.c:1722 new_slab_objects mm/slub.c:2473 [inline] ___slab_alloc+0x1533/0x1f30 mm/slub.c:2624 __slab_alloc mm/slub.c:2664 [inline] slab_alloc_node mm/slub.c:2738 [inline] slab_alloc mm/slub.c:2783 [inline] kmem_cache_alloc+0xb23/0xd70 mm/slub.c:2788 sk_prot_alloc+0xf2/0x620 net/core/sock.c:1597 sk_alloc+0xf0/0xbe0 net/core/sock.c:1657 inet_create+0x7c7/0x1370 net/ipv4/af_inet.c:321 __sock_create+0x8eb/0xf00 net/socket.c:1420 sock_create net/socket.c:1471 [inline] __sys_socket+0x1a1/0x600 net/socket.c:1513 __do_sys_socket net/socket.c:1522 [inline] __se_sys_socket+0x8d/0xb0 net/socket.c:1520 __x64_sys_socket+0x4a/0x70 net/socket.c:1520 do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Eric Dumazet Cc: Pablo Neira Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 80a4c81c67918f8f879b8ca63c0301e22b7e8b7a Author: Wenwen Wang Date: Sat Jan 25 14:33:29 2020 +0000 firestream: fix memory leaks [ Upstream commit fa865ba183d61c1ec8cbcab8573159c3b72b89a4 ] In fs_open(), 'vcc' is allocated through kmalloc() and assigned to 'atm_vcc->dev_data.' In the following execution, if an error occurs, e.g., there is no more free channel, an error code EBUSY or ENOMEM will be returned. However, 'vcc' is not deallocated, leading to memory leaks. Note that, in normal cases where fs_open() returns 0, 'vcc' will be deallocated in fs_close(). But, if fs_open() fails, there is no guarantee that fs_close() will be invoked. To fix this issue, deallocate 'vcc' before the error code is returned. Signed-off-by: Wenwen Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 34545cad8e0476aa6843f132e1177fe1517b2814 Author: Richard Palethorpe Date: Tue Jan 21 14:42:58 2020 +0100 can, slip: Protect tty->disc_data in write_wakeup and close with RCU [ Upstream commit 0ace17d56824165c7f4c68785d6b58971db954dd ] write_wakeup can happen in parallel with close/hangup where tty->disc_data is set to NULL and the netdevice is freed thus also freeing disc_data. write_wakeup accesses disc_data so we must prevent close from freeing the netdev while write_wakeup has a non-NULL view of tty->disc_data. We also need to make sure that accesses to disc_data are atomic. Which can all be done with RCU. This problem was found by Syzkaller on SLCAN, but the same issue is reproducible with the SLIP line discipline using an LTP test based on the Syzkaller reproducer. A fix which didn't use RCU was posted by Hillf Danton. Fixes: 661f7fda21b1 ("slip: Fix deadlock in write_wakeup") Fixes: a8e83b17536a ("slcan: Port write_wakeup deadlock fix from slip") Reported-by: syzbot+017e491ae13c0068598a@syzkaller.appspotmail.com Signed-off-by: Richard Palethorpe Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: "David S. Miller" Cc: Tyler Hall Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: syzkaller@googlegroups.com Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 111e415c94f5c299de1ee50c825b60e63d5919e9 Author: Greg Kroah-Hartman Date: Sun Jan 26 10:01:09 2020 +0100 Linux 5.4.15 commit 15763f047ea2785a253d53edc91892ed7acb304f Author: Sumit Garg Date: Mon Dec 30 18:52:40 2019 +0530 optee: Fix multi page dynamic shm pool alloc [ Upstream commit 5a769f6ff439cedc547395a6dc78faa26108f741 ] optee_shm_register() expected pages to be passed as an array of page pointers rather than as an array of contiguous pages. So fix that via correctly passing pages as per expectation. Fixes: a249dd200d03 ("tee: optee: Fix dynamic shm pool allocations") Reported-by: Vincent Cao Signed-off-by: Sumit Garg Tested-by: Vincent Cao Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 88532d1e64e1a303b23ea13355c990f10a6b4b93 Author: Jonas Karlman Date: Mon Dec 23 08:49:19 2019 +0000 phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz [ Upstream commit 4f510aa10468954b1da4e94689c38ac6ea8d3627 ] Commit 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock framework") changed what rate clk_round_rate() is called with, an additional 999 Hz added to the requsted mode clock. This has caused a regression on RK3328 and presumably also on RK3228 because the inno-hdmi-phy clock requires an exact match of the requested rate in the pre pll config table. When an exact match is not found the parent clock rate (24MHz) is returned to the clk_round_rate() caller. This cause wrong pixel clock to be used and result in no-signal when configuring a mode on RK3328. Fix this by rounding the rate down to closest 1000 Hz in round_rate func, this allows an exact match to be found in pre pll config table. Fixes: 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock framework") Signed-off-by: Jonas Karlman Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit ce28f9842d0e1d36a3c8891c4d46cc4c1d56940f Author: Arnd Bergmann Date: Tue Dec 10 21:28:31 2019 +0100 gpio: aspeed: avoid return type warning [ Upstream commit 11e299de3aced4ea23a9fb1fef6c983c8d516302 ] gcc has a hard time tracking whether BUG_ON(1) ends execution or not: drivers/gpio/gpio-aspeed-sgpio.c: In function 'bank_reg': drivers/gpio/gpio-aspeed-sgpio.c:112:1: error: control reaches end of non-void function [-Werror=return-type] Use the simpler BUG() that gcc knows cannot continue. Fixes: f8b410e3695a ("gpio: aspeed-sgpio: Rename and add Kconfig/Makefile") Signed-off-by: Arnd Bergmann Acked-by: Andrew Jeffery Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 60d671da2fa2e9505e560aef0ee510fc45fb4322 Author: Jouni Hogander Date: Thu Dec 5 15:57:07 2019 +0200 net-sysfs: Call dev_hold always in netdev_queue_add_kobject [ Upstream commit e0b60903b434a7ee21ba8d8659f207ed84101e89 ] Dev_hold has to be called always in netdev_queue_add_kobject. Otherwise usage count drops below 0 in case of failure in kobject_init_and_add. Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") Reported-by: Hulk Robot Cc: Tetsuo Handa Cc: David Miller Cc: Lukas Bulwahn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 465b10fee9a8ad820a191b1be0991fdac98b188b Author: Julian Wiedmann Date: Thu Dec 5 14:33:04 2019 +0100 s390/qeth: fix dangling IO buffers after halt/clear [ Upstream commit f9e50b02a99c3ebbaa30690e8d5be28a5c2624eb ] The cio layer's intparm logic does not align itself well with how qeth manages cmd IOs. When an active IO gets terminated via halt/clear, the corresponding IRQ's intparm does not reflect the cmd buffer but rather the intparm that was passed to ccw_device_halt() / ccw_device_clear(). This behaviour was recently clarified in commit b91d9e67e50b ("s390/cio: fix intparm documentation"). As a result, qeth_irq() currently doesn't cancel a cmd that was terminated via halt/clear. This primarily causes us to leak card->read_cmd after the qeth device is removed, since our IO path still holds a refcount for this cmd. For qeth this means that we need to keep track of which IO is pending on a device ('active_cmd'), and use this as the intparm when calling halt/clear. Otherwise qeth_irq() can't match the subsequent IRQ to its cmd buffer. Since we now keep track of the _expected_ intparm, we can also detect any mismatch; this would constitute a bug somewhere in the lower layers. In this case cancel the active cmd - we effectively "lost" the IRQ and should not expect any further notification for this IO. Fixes: 405548959cc7 ("s390/qeth: add support for dynamically allocated cmds") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ccbc5d03c2bd83a07be78351571483bc22c0c63e Author: Justin Tee Date: Thu Dec 5 10:09:01 2019 +0800 block: fix memleak of bio integrity data [ Upstream commit ece841abbed2da71fa10710c687c9ce9efb6bf69 ] 7c20f11680a4 ("bio-integrity: stop abusing bi_end_io") moves bio_integrity_free from bio_uninit() to bio_integrity_verify_fn() and bio_endio(). This way looks wrong because bio may be freed without calling bio_endio(), for example, blk_rq_unprep_clone() is called from dm_mq_queue_rq() when the underlying queue of dm-mpath is busy. So memory leak of bio integrity data is caused by commit 7c20f11680a4. Fixes this issue by re-adding bio_integrity_free() to bio_uninit(). Fixes: 7c20f11680a4 ("bio-integrity: stop abusing bi_end_io") Reviewed-by: Christoph Hellwig Signed-off-by Justin Tee Add commit log, and simplify/fix the original patch wroten by Justin. Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 022321aa796730da85c8b765c63dcaa289b89391 Author: Wen Yang Date: Sat Nov 30 21:08:42 2019 +0800 platform/chrome: wilco_ec: fix use after free issue [ Upstream commit 856a0a6e2d09d31fd8f00cc1fc6645196a509d56 ] This is caused by dereferencing 'dev_data' after put_device() in the telem_device_remove() function. This patch just moves the put_device() down a bit to avoid this issue. Fixes: 1210d1e6bad1 ("platform/chrome: wilco_ec: Add telemetry char device interface") Signed-off-by: Wen Yang Cc: Benson Leung Cc: Enric Balletbo i Serra Cc: Nick Crews Cc: linux-kernel@vger.kernel.org Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin commit 074fd02d45976eed02f82cb2d9e01b0169cc1ec5 Author: Toke Høiland-Jørgensen Date: Thu Nov 21 14:36:12 2019 +0100 xdp: Fix cleanup on map free for devmap_hash map type [ Upstream commit 071cdecec57fb5d5df78e6a12114ad7bccea5b0e ] Tetsuo pointed out that it was not only the device unregister hook that was broken for devmap_hash types, it was also cleanup on map free. So better fix this as well. While we're at it, there's no reason to allocate the netdev_map array for DEVMAP_HASH, so skip that and adjust the cost accordingly. Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index") Reported-by: Tetsuo Handa Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20191121133612.430414-1-toke@redhat.com Signed-off-by: Sasha Levin commit 62ac16b0deeffff42501cface181a652a9004f26 Author: Sam Bobroff Date: Mon Nov 18 10:53:53 2019 +1100 drm/radeon: fix bad DMA from INTERRUPT_CNTL2 [ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ] The INTERRUPT_CNTL2 register expects a valid DMA address, but is currently set with a GPU MC address. This can cause problems on systems that detect the resulting DMA read from an invalid address (found on a Power8 guest). Instead, use the DMA address of the dummy page because it will always be safe. Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)") Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI") Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)") Signed-off-by: Sam Bobroff Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ca4c17f2106e2d1296d335d39ecb2e3d8a9ccccf Author: Chuhong Yuan Date: Mon Nov 18 15:38:02 2019 +0800 dmaengine: ti: edma: fix missed failure handling [ Upstream commit 340049d453682a9fe8d91fe794dd091730f4bb25 ] When devm_kcalloc fails, it forgets to call edma_free_slot. Replace direct return with failure handler to fix it. Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191118073802.28424-1-hslester96@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c1b9854f3e3f9dffc671952a59d652cf9e31afab Author: zhengbin Date: Thu Nov 21 09:12:18 2019 +0000 afs: Remove set but not used variables 'before', 'after' [ Upstream commit 51590df4f3306cb1f43dca54e3ccdd121ab89594 ] Fixes gcc '-Wunused-but-set-variable' warning: fs/afs/dir_edit.c: In function afs_set_contig_bits: fs/afs/dir_edit.c:75:20: warning: variable after set but not used [-Wunused-but-set-variable] fs/afs/dir_edit.c: In function afs_set_contig_bits: fs/afs/dir_edit.c:75:12: warning: variable before set but not used [-Wunused-but-set-variable] fs/afs/dir_edit.c: In function afs_clear_contig_bits: fs/afs/dir_edit.c:100:20: warning: variable after set but not used [-Wunused-but-set-variable] fs/afs/dir_edit.c: In function afs_clear_contig_bits: fs/afs/dir_edit.c:100:12: warning: variable before set but not used [-Wunused-but-set-variable] They are never used since commit 63a4681ff39c. Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...") Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: David Howells Signed-off-by: Sasha Levin commit b8444fa88da81f66e27b278907ff63be09d75fd1 Author: Christoph Hellwig Date: Tue Nov 19 17:35:36 2019 +0100 dma-direct: don't check swiotlb=force in dma_direct_map_resource [ Upstream commit 4268ac6ae5870af10a7417b22990d615f72f77e2 ] When mapping resources we can't just use swiotlb ram for bounce buffering. Switch to a direct dma_capable check instead. Fixes: cfced786969c ("dma-mapping: remove the default map_resource implementation") Reported-by: Robin Murphy Signed-off-by: Christoph Hellwig Acked-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Sasha Levin commit 0812e7de492804b3d31048cc0b1c941769b79553 Author: Lorenzo Bianconi Date: Mon Oct 28 16:21:41 2019 +0100 mt76: mt76u: rely on usb_interface instead of usb_dev [ Upstream commit 80df01f4dc79abbed724bbe0851cab3fe8ad9d99 ] usb drivers are supposed to communicate using usb_interface instead mt76x{0,2}u is now registering through usb_device. Fix it by passing usb_intf device to mt76_alloc_device routine. Fixes: 112f980ac8926 ("mt76usb: use usb_dev private data") Signed-off-by: Lorenzo Bianconi Tested-By: Zero_Chaos Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0e9619ff10caa2f74d9d605f2be31d3faa843aea Author: Vincent Guittot Date: Mon Nov 18 14:21:19 2019 +0100 sched/cpufreq: Move the cfs_rq_util_change() call to cpufreq_update_util() [ Upstream commit bef69dd87828ef5d8ecdab8d857cd3a33cf98675 ] update_cfs_rq_load_avg() calls cfs_rq_util_change() every time PELT decays, which might be inefficient when the cpufreq driver has rate limitation. When a task is attached on a CPU, we have this call path: update_load_avg() update_cfs_rq_load_avg() cfs_rq_util_change -- > trig frequency update attach_entity_load_avg() cfs_rq_util_change -- > trig frequency update The 1st frequency update will not take into account the utilization of the newly attached task and the 2nd one might be discarded because of rate limitation of the cpufreq driver. update_cfs_rq_load_avg() is only called by update_blocked_averages() and update_load_avg() so we can move the call to cfs_rq_util_change/cpufreq_update_util() into these two functions. It's also interesting to note that update_load_avg() already calls cfs_rq_util_change() directly for the !SMP case. This change will also ensure that cpufreq_update_util() is called even when there is no more CFS rq in the leaf_cfs_rq_list to update, but only IRQ, RT or DL PELT signals. [ mingo: Minor updates. ] Reported-by: Doug Smythies Tested-by: Doug Smythies Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Acked-by: Rafael J. Wysocki Cc: Linus Torvalds Cc: Thomas Gleixner Cc: juri.lelli@redhat.com Cc: linux-pm@vger.kernel.org Cc: mgorman@suse.de Cc: rostedt@goodmis.org Cc: sargun@sargun.me Cc: srinivas.pandruvada@linux.intel.com Cc: tj@kernel.org Cc: xiexiuqi@huawei.com Cc: xiezhipeng1@huawei.com Fixes: 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path") Link: https://lkml.kernel.org/r/1574083279-799-1-git-send-email-vincent.guittot@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit e0e2379bfc70ef2d540e6f29f2aafd3c07a8026d Author: Chuck Lever Date: Fri Nov 15 08:39:07 2019 -0500 SUNRPC: Fix another issue with MIC buffer space [ Upstream commit e8d70b321ecc9b23d09b8df63e38a2f73160c209 ] xdr_shrink_pagelen() BUG's when @len is larger than buf->page_len. This can happen when xdr_buf_read_mic() is given an xdr_buf with a small page array (like, only a few bytes). Instead, just cap the number of bytes that xdr_shrink_pagelen() will move. Fixes: 5f1bc39979d ("SUNRPC: Fix buffer handling of GSS MIC ... ") Signed-off-by: Chuck Lever Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 16128944c90749d0b88758bcf727c8e8af3b2f4e Author: Sebastian Andrzej Siewior Date: Fri Nov 15 19:01:25 2019 +0100 workqueue: Add RCU annotation for pwq list walk [ Upstream commit 49e9d1a9faf2f71fdfd80a30697ee9a15070626d ] An additional check has been recently added to ensure that a RCU related lock is held while the RCU list is iterated. The `pwqs' are sometimes iterated without a RCU lock but with the &wq->mutex acquired leading to a warning. Teach list_for_each_entry_rcu() that the RCU usage is okay if &wq->mutex is acquired during the list traversal. Fixes: 28875945ba98d ("rcu: Add support for consolidated-RCU reader checking") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b30a9b012a4e9b400a3e3caa0e4c83d77089ef7b Author: Jens Wiklander Date: Wed Nov 6 16:48:28 2019 +0100 tee: optee: fix device enumeration error handling [ Upstream commit 03212e347f9443e524d6383c6806ac08295c1fb0 ] Prior to this patch in optee_probe() when optee_enumerate_devices() was called the struct optee was fully initialized. If optee_enumerate_devices() returns an error optee_probe() is supposed to clean up and free the struct optee completely, but will at this late stage need to call optee_remove() instead. This isn't done and thus freeing the struct optee prematurely. With this patch the call to optee_enumerate_devices() is done after optee_probe() has returned successfully and in case optee_enumerate_devices() fails everything is cleaned up with a call to optee_remove(). Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support") Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 5c179c003b45909df8bf55c072df897bcb2ef0e0 Author: Sumit Garg Date: Fri Nov 8 16:57:14 2019 +0530 tee: optee: Fix dynamic shm pool allocations [ Upstream commit a249dd200d03791cab23e47571f3e13d9c72af6c ] In case of dynamic shared memory pool, kernel memory allocated using dmabuf_mgr pool needs to be registered with OP-TEE prior to its usage during optee_open_session() or optee_invoke_func(). So fix dmabuf_mgr pool allocations via an additional call to optee_shm_register(). Also, allow kernel pages to be registered as shared memory with OP-TEE. Fixes: 9733b072a12a ("optee: allow to work without static shared memory") Signed-off-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 2eb4d745cf7f4617fdbc33d8278191a36ada0ee4 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:43 2019 +0100 mmc: core: fix wl1251 sdio quirks [ Upstream commit 16568b4a4f0c34bd35cfadac63303c7af7812764 ] wl1251 and wl1271 have different vendor id and device id. So we need to handle both with sdio quirks. Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by: H. Nikolaus Schaller Cc: # v4.11+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f8afdceb9f2b13f9f732f944db94f9df8a533559 Author: H. Nikolaus Schaller Date: Thu Nov 7 11:30:42 2019 +0100 mmc: sdio: fix wl1251 vendor id [ Upstream commit e5db673e7fe2f971ec82039a28dc0811c2100e87 ] v4.11-rc1 did introduce a patch series that rearranged the sdio quirks into a header file. Unfortunately this did forget to handle SDIO_VENDOR_ID_TI differently between wl1251 and wl1271 with the result that although the wl1251 was found on the sdio bus, the firmware did not load any more and there was no interface registration. This patch defines separate constants to be used by sdio quirks and drivers. Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by: H. Nikolaus Schaller Cc: # v4.11+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8b8b5f9a7b3b6295325e0252c31c4947f8ed5b5c Author: Sudeep Holla Date: Mon Nov 11 16:25:22 2019 +0000 firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BIT [ Upstream commit 7bd39bc6bfdf96f5df0f92199bbc1a3ee2f2adb8 ] The logic to ring the scmi performance fastchannel ignores the value read from the doorbell register in case of !CONFIG_64BIT. This bug also shows up as warning with '-Wunused-but-set-variable' gcc flag: drivers/firmware/arm_scmi/perf.c: In function scmi_perf_fc_ring_db: drivers/firmware/arm_scmi/perf.c:323:7: warning: variable val set but not used [-Wunused-but-set-variable] Fix the same by aligning the logic with CONFIG_64BIT as used in the macro SCMI_PERF_FC_RING_DB(). Fixes: 823839571d76 ("firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol") Reported-by: Hulk Robot Reported-by: Zheng Yongjun Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 83ff921a5e891a22e8b4ac1d0dfbb478de3691e8 Author: Hewenliang Date: Mon Nov 11 21:16:55 2019 -0500 kselftests: cgroup: Avoid the reuse of fd after it is deallocated [ Upstream commit d671fa6393d6788fc65555d4643b71cb3a361f36 ] It is necessary to set fd to -1 when inotify_add_watch() fails in cg_prepare_for_wait. Otherwise the fd which has been closed in cg_prepare_for_wait may be misused in other functions such as cg_enter_and_wait_for_frozen and cg_freeze_wait. Fixes: 5313bfe425c8 ("selftests: cgroup: add freezer controller self-tests") Signed-off-by: Hewenliang Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit c570172d62413eddc9ac330449e84446ade384ad Author: Alain Volmat Date: Thu Oct 24 14:52:00 2019 +0200 i2c: stm32f7: report dma error during probe [ Upstream commit d77eceb2de99f5d7e0c645bad15511fe1af59e09 ] Distinguish between the case where dma information is not provided within the DT and the case of an error during the dma init. Exit the probe with error in case of an error during dma init. Fixes: bb8822cbbc53 ("i2c: i2c-stm32: Add generic DMA API") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit f6d362634e1645e74a8472511f29a63a7c41cb13 Author: Eric Dumazet Date: Fri Nov 8 05:07:46 2019 -0800 packet: fix data-race in fanout_flow_is_huge() [ Upstream commit b756ad928d98e5ef0b74af7546a6a31a8dadde00 ] KCSAN reported the following data-race [1] Adding a couple of READ_ONCE()/WRITE_ONCE() should silence it. Since the report hinted about multiple cpus using the history concurrently, I added a test avoiding writing on it if the victim slot already contains the desired value. [1] BUG: KCSAN: data-race in fanout_demux_rollover / fanout_demux_rollover read to 0xffff8880b01786cc of 4 bytes by task 18921 on cpu 1: fanout_flow_is_huge net/packet/af_packet.c:1303 [inline] fanout_demux_rollover+0x33e/0x3f0 net/packet/af_packet.c:1353 packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453 deliver_skb net/core/dev.c:1888 [inline] dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958 xmit_one net/core/dev.c:3195 [inline] dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215 __dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792 dev_queue_xmit+0x21/0x30 net/core/dev.c:3825 neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179 ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795 udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173 udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471 inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0x9f/0xc0 net/socket.c:657 ___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311 __sys_sendmmsg+0x123/0x350 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg net/socket.c:2439 [inline] __x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 write to 0xffff8880b01786cc of 4 bytes by task 18922 on cpu 0: fanout_flow_is_huge net/packet/af_packet.c:1306 [inline] fanout_demux_rollover+0x3a4/0x3f0 net/packet/af_packet.c:1353 packet_rcv_fanout+0x34e/0x490 net/packet/af_packet.c:1453 deliver_skb net/core/dev.c:1888 [inline] dev_queue_xmit_nit+0x15b/0x540 net/core/dev.c:1958 xmit_one net/core/dev.c:3195 [inline] dev_hard_start_xmit+0x3f5/0x430 net/core/dev.c:3215 __dev_queue_xmit+0x14ab/0x1b40 net/core/dev.c:3792 dev_queue_xmit+0x21/0x30 net/core/dev.c:3825 neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a2/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179 ip6_send_skb+0x53/0x110 net/ipv6/ip6_output.c:1795 udp_v6_send_skb.isra.0+0x3ec/0xa70 net/ipv6/udp.c:1173 udpv6_sendmsg+0x1906/0x1c20 net/ipv6/udp.c:1471 inet6_sendmsg+0x6d/0x90 net/ipv6/af_inet6.c:576 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0x9f/0xc0 net/socket.c:657 ___sys_sendmsg+0x2b7/0x5d0 net/socket.c:2311 __sys_sendmmsg+0x123/0x350 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg net/socket.c:2439 [inline] __x64_sys_sendmmsg+0x64/0x80 net/socket.c:2439 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 18922 Comm: syz-executor.3 Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 3b3a5b0aab5b ("packet: rollover huge flows before small flows") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f3cf5124e28d50c4ae3e0c86434eed720921f0ef Author: Colin Ian King Date: Wed Nov 6 08:34:18 2019 +0000 rtc: bd70528: fix module alias to autoload module [ Upstream commit afe19a7ae8b6b6032d04d3895ebd5bbac7fe9f30 ] The module alias platform tag contains a spelling mistake. Fix it. Fixes: f33506abbcdd ("rtc: bd70528: Add MODULE ALIAS to autoload module") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20191106083418.159045-1-colin.king@canonical.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 7bd74545fae9721b72749b4ff0bda54a3d2736c8 Author: Kees Cook Date: Wed Oct 30 12:46:08 2019 -0700 selftests: gen_kselftest_tar.sh: Do not clobber kselftest/ [ Upstream commit ea1bf0bb18c0bd627d7b551196453ff2fff44225 ] The default installation location for gen_kselftest_tar.sh was still "kselftest/" which collides with the existing directory. Instead, this moves the installation target into "kselftest_install/kselftest/" and adjusts the tar creation accordingly. This also adjusts indentation and logic to be consistent. Fixes: 42d46e57ec97 ("selftests: Extract single-test shell logic from lib.mk") Signed-off-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e9870cdb685cd0750fb4f05cbfc81075be88919e Author: Wei Yongjun Date: Wed Nov 6 15:54:49 2019 +0000 net: axienet: Fix error return code in axienet_probe() [ Upstream commit eb34e98baf4ce269423948dacefea6747e963b48 ] In the DMA memory resource get failed case, the error is not set and 0 will be returned. Fix it by removing redundant check since devm_ioremap_resource() will handle it. Fixes: 28ef9ebdb64c ("net: axienet: make use of axistream-connected attribute optional") Signed-off-by: Wei Yongjun Reviewed-by: Radhey Shyam Pandey Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e9a6f09fc29ca36ae5a6df7644cce51fccf705e7 Author: Eric Dumazet Date: Tue Nov 5 14:11:49 2019 -0800 net: neigh: use long type to store jiffies delta [ Upstream commit 9d027e3a83f39b819e908e4e09084277a2e45e95 ] A difference of two unsigned long needs long storage. Fixes: c7fb64db001f ("[NETLINK]: Neighbour table configuration and statistics via rtnetlink") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ab269ffa5aa153965868bd34f747819a4b88bdc5 Author: Daniel Golle Date: Sat Nov 2 18:47:01 2019 +0100 rt2800: remove errornous duplicate condition [ Upstream commit a1f7c2cabf701a17b1a05d6526bbdadc3d05e05c ] On 2019-10-28 06:07, wbob wrote: > Hello Roman, > > while reading around drivers/net/wireless/ralink/rt2x00/rt2800lib.c > I stumbled on what I think is an edit of yours made in error in march > 2017: > > https://github.com/torvalds/linux/commit/41977e86#diff-dae5dc10da180f3b055809a48118e18aR5281 > > RT6352 in line 5281 should not have been introduced as the "else if" > below line 5291 can then not take effect for a RT6352 device. Another > possibility is for line 5291 to be not for RT6352, but this seems > very unlikely. Are you able to clarify still after this substantial time? > > 5277: static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev) > ... > 5279: } else if (rt2x00_rt(rt2x00dev, RT5390) || > 5280: rt2x00_rt(rt2x00dev, RT5392) || > 5281: rt2x00_rt(rt2x00dev, RT6352)) { > ... > 5291: } else if (rt2x00_rt(rt2x00dev, RT6352)) { > ... Hence remove errornous line 5281 to make the driver actually execute the correct initialization routine for MT7620 chips. As it was requested by Stanislaw Gruszka remove setting values of MIMO_PS_CFG and TX_PIN_CFG. MIMO_PS_CFG is responsible for MIMO power-safe mode (which is disabled), hence we can drop setting it. TX_PIN_CFG is set correctly in other functions, and as setting this value breaks some devices, rather don't set it here during init, but only modify it later on. Fixes: 41977e86c984 ("rt2x00: add support for MT7620") Reported-by: wbob Reported-by: Roman Yeryomin Signed-off-by: Daniel Golle Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ca52b5cd5d18c18a24327f192d145df70fad3186 Author: Stephen Hemminger Date: Fri Nov 1 16:42:37 2019 -0700 hv_netvsc: flag software created hash value [ Upstream commit df9f540ca74297a84bafacfa197e9347b20beea5 ] When the driver needs to create a hash value because it was not done at higher level, then the hash should be marked as a software not hardware hash. Fixes: f72860afa2e3 ("hv_netvsc: Exclude non-TCP port numbers from vRSS hashing") Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 79310c41b0c789a98ab662c02263cc4038ffd023 Author: Tonghao Zhang Date: Fri Nov 1 22:23:53 2019 +0800 net: openvswitch: don't unlock mutex when changing the user_features fails [ Upstream commit 4c76bf696a608ea5cc555fe97ec59a9033236604 ] Unlocking of a not locked mutex is not allowed. Other kernel thread may be in critical section while we unlock it because of setting user_feature fail. Fixes: 95a7233c4 ("net: openvswitch: Set OvS recirc_id from tc chain index") Cc: Paul Blakey Signed-off-by: Tonghao Zhang Tested-by: Greg Rose Acked-by: William Tu Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c3327816d3491675b6368575bef73d547a6d59f Author: Bean Huo Date: Tue Oct 29 14:22:45 2019 +0000 scsi: ufs: delete redundant function ufshcd_def_desc_sizes() [ Upstream commit 059efd847a4097c67817782d8ff65397e369e69b ] There is no need to call ufshcd_def_desc_sizes() in ufshcd_init(), since descriptor lengths will be checked and initialized later in ufshcd_init_desc_sizes(). Fixes: a4b0e8a4e92b1b(scsi: ufs: Factor out ufshcd_read_desc_param) Link: https://lore.kernel.org/r/BN7PR08MB5684A3ACE214C3D4792CE729DB610@BN7PR08MB5684.namprd08.prod.outlook.com Signed-off-by: Bean Huo Acked-by: Avri Altman Reviewed-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 71394774331d8e0cfa6205bbbf5413a883d8d70d Author: Madalin Bucur Date: Thu Oct 31 16:37:50 2019 +0200 dpaa_eth: avoid timestamp read on error paths [ Upstream commit 9a4f4f3a894ff4487f5597b7aabba9432b238292 ] The dpaa_cleanup_tx_fd() function is called by the frame transmit confirmation callback but also on several error paths. This function is reading the transmit timestamp value. Avoid reading an invalid timestamp value on the error paths. Fixes: 4664856e9ca2 ("dpaa_eth: add support for hardware timestamping") Signed-off-by: Madalin Bucur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 54c45b818ad1f91aad149e0e5c0fdfadcab17f19 Author: Madalin Bucur Date: Thu Oct 31 16:37:49 2019 +0200 dpaa_eth: perform DMA unmapping before read [ Upstream commit c70fd3182caef014e6c628b412f81aa57a3ef9e4 ] DMA unmapping is required before accessing the HW provided timestamping information. Fixes: 4664856e9ca2 ("dpaa_eth: add support for hardware timestamping") Signed-off-by: Madalin Bucur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e4e32af72d0cd26d1ca291a85b6e5e6e7b0dd576 Author: Dan Carpenter Date: Mon Sep 23 17:26:34 2019 +0300 rcu: Fix uninitialized variable in nocb_gp_wait() [ Upstream commit b8889c9c89a2655a231dfed93cc9bdca0930ea67 ] We never set this to false. This probably doesn't affect most people's runtime because GCC will automatically initialize it to false at certain common optimization levels. But that behavior is related to a bug in GCC and obviously should not be relied on. Fixes: 5d6742b37727 ("rcu/nocb: Use rcu_segcblist for no-CBs CPUs") Signed-off-by: Dan Carpenter Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 220ba320861c7368159b5c80b7dc7418e4ea5d8b Author: Andrii Nakryiko Date: Mon Oct 28 22:59:53 2019 -0700 libbpf: Don't use kernel-side u32 type in xsk.c [ Upstream commit a566e35f1e8b4b3be1e96a804d1cca38b578167c ] u32 is a kernel-side typedef. User-space library is supposed to use __u32. This breaks Github's projection of libbpf. Do u32 -> __u32 fix. Fixes: 94ff9ebb49a5 ("libbpf: Fix compatibility for kernels without need_wakeup") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Björn Töpel Cc: Magnus Karlsson Link: https://lore.kernel.org/bpf/20191029055953.2461336-1-andriin@fb.com Signed-off-by: Sasha Levin commit bd9d813ca8fe455e58c22512f225e14dc9ac209a Author: Daniel Baluta Date: Mon Oct 14 18:32:28 2019 +0300 firmware: imx: Remove call to devm_of_platform_populate [ Upstream commit 0e4e8cc30a2940c57448af1376e40d3c0996fb29 ] IMX DSP device is created by SOF layer. The current call to devm_of_platform_populate is not needed and it doesn't produce any effects. Fixes: ffbf23d50353915d ("firmware: imx: Add DSP IPC protocol interface) Signed-off-by: Daniel Baluta Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 16232b03957ccd3d2e121c89393fdad2dc375929 Author: Matti Vaittinen Date: Wed Oct 23 15:35:24 2019 +0300 power: supply: bd70528: Add MODULE_ALIAS to allow module auto loading [ Upstream commit 9480029fe5c24d482efad38dc631bd555fc7afe2 ] The bd70528 charger driver is probed by MFD driver. Add MODULE_ALIAS in order to allow udev to load the module when MFD sub-device cell for charger is added. Fixes: f8c7f7ddd8ef0 ("power: supply: Initial support for ROHM BD70528 PMIC charger block") Signed-off-by: Matti Vaittinen Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit bdfb7621c4c79ec0bd86494823ae36a651a9d693 Author: Dan Carpenter Date: Thu Oct 17 12:12:16 2019 +0300 drm/amdgpu/vi: silence an uninitialized variable warning [ Upstream commit 4ff17a1df7d550257972a838220a8af4611c8f2c ] Smatch complains that we need to initialized "*cap" otherwise it can lead to an uninitialized variable bug in the caller. This seems like a reasonable warning and it doesn't hurt to silence it at least. drivers/gpu/drm/amd/amdgpu/vi.c:767 vi_asic_reset_method() error: uninitialized symbol 'baco_reset'. Fixes: 425db2553e43 ("drm/amdgpu: expose BACO interfaces to upper level from PP") Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b6cb98e60d0649e0d7c59da550c9860e03483656 Author: Matti Vaittinen Date: Wed Oct 23 15:14:52 2019 +0300 regulator: bd70528: Add MODULE_ALIAS to allow module auto loading [ Upstream commit 55d5f62c3fa005a6a8010363d7d1855909ceefbc ] The bd70528 regulator driver is probed by MFD driver. Add MODULE_ALIAS in order to allow udev to load the module when MFD sub-device cell for regulators is added. Fixes: 99ea37bd1e7d7 ("regulator: bd70528: Support ROHM BD70528 regulator block") Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/20191023121452.GA1812@localhost.localdomain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e70290bb1f8fa625b0e9a98fd78efd3ec51fabcb Author: Ondrej Jirman Date: Mon Oct 14 15:53:03 2019 +0200 pwm: sun4i: Fix incorrect calculation of duty_cycle/period [ Upstream commit 50cc7e3e4f26e3bf5ed74a8d061195c4d2161b8b ] Since 5.4-rc1, pwm_apply_state calls ->get_state after ->apply if available, and this revealed an issue with integer precision when calculating duty_cycle and period for the currently set state in ->get_state callback. This issue manifested in broken backlight on several Allwinner based devices. Previously this worked, because ->apply updated the passed state directly. Fixes: deb9c462f4e53 ("pwm: sun4i: Don't update the state for the caller of pwm_apply_state") Signed-off-by: Ondrej Jirman Acked-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit aff509a3a127f0f059f2da9ddcbf477a74585664 Author: Andy Shevchenko Date: Fri Aug 30 17:34:32 2019 +0300 ACPI: platform: Unregister stale platform devices [ Upstream commit cb0701acfa7e3fe9e919cf2aa2aa939b7fd603c2 ] When commit 68bdb6773289 ("ACPI: add support for ACPI reconfiguration notifiers") introduced reconfiguration notifiers, it missed the point that the ACPI table, which might be loaded and then unloaded via ConfigFS, could contain devices that were not enumerated by their parents. In such cases, the stale platform device is dangling in the system while the rest of the devices from the same table are already gone. Introduce acpi_platform_device_remove_notify() notifier that, in similar way to I²C or SPI buses, unregisters the platform devices on table removal event. Fixes: 68bdb6773289 ("ACPI: add support for ACPI reconfiguration notifiers") Depends-on: 00500147cbd3 ("drivers: Introduce device lookup variants by ACPI_COMPANION device") Signed-off-by: Andy Shevchenko [ rjw: Changelog & function rename ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c99f4a8c666dbfd69b05c2321b43de46b0e8dfe7 Author: Ilias Apalodimas Date: Wed Oct 16 14:40:32 2019 +0300 net: netsec: Correct dma sync for XDP_TX frames [ Upstream commit d9496f3ecfe4823c1e12aecbcc29220147fa012c ] bpf_xdp_adjust_head() can change the frame boundaries. Account for the potential shift properly by calculating the new offset before syncing the buffer to the device for XDP_TX Fixes: ba2b232108d3 ("net: netsec: add XDP support") Signed-off-by: Ilias Apalodimas Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 238ca6417eec3b82a812964d5f98561b22614c7d Author: Geert Uytterhoeven Date: Tue Sep 17 08:23:53 2019 +0200 drm: rcar_lvds: Fix color mismatches on R-Car H2 ES2.0 and later [ Upstream commit 3986457110a054466bf02f9c4a85aa2bba96177b ] Commit 5cca30ebe089be23 ("drm/rcar-du: Add LVDS_LANES quirk") states that LVDS lanes 1 and 3 are inverted on R-Car H2 ES1 only, and that the problem has been fixed in newer revisions. However, the code didn't take into account the actual hardware revision, thus applying the quirk also on newer hardware revisions, causing green color reversals. Fix this by applying the quirk when running on R-Car H2 ES1.x only. Reported-by: Yoshihiro Shimoda Fixes: 5cca30ebe089be23 ("drm/rcar-du: Add LVDS_LANES quirk") Signed-off-by: Geert Uytterhoeven Tested-by: Yoshihiro Shimoda Reviewed-by: Ulrich Hecht Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 1865d6440fb63ad979d7034b2d7c94937bfd2200 Author: Kefeng Wang Date: Fri Oct 4 12:19:25 2019 +0800 PCI: mobiveil: Fix csr_read()/write() build issue [ Upstream commit 4906c05b87d44c19b225935e24d62e4480ca556d ] RISCV has csr_read()/write() macros in arch/riscv/include/asm/csr.h. The same function naming is used in the PCI mobiveil driver thus causing build error. Rename csr_[read,write][l,] to mobiveil_csr_read()/write() to fix it. drivers/pci/controller/pcie-mobiveil.c:238:69: error: macro "csr_read" passed 3 arguments, but takes just 1 static u32 csr_read(struct mobiveil_pcie *pcie, u32 off, size_t size) drivers/pci/controller/pcie-mobiveil.c:253:80: error: macro "csr_write" passed 4 arguments, but takes just 2 static void csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off, size_t size) Fixes: bcbe0d9a8d93 ("PCI: mobiveil: Unify register accessors") Signed-off-by: Kefeng Wang Signed-off-by: Lorenzo Pieralisi Reviewed-by: Andrew Murray Cc: Hou Zhiqiang Cc: Lorenzo Pieralisi Cc: Minghuan Lian Cc: Subrahmanya Lingappa Cc: Andrew Murray Signed-off-by: Sasha Levin commit 3da105401e6f7e7ba77fe412da4bdb5214274611 Author: Sakari Ailus Date: Thu Oct 3 15:32:08 2019 +0300 software node: Get reference to parent swnode in get_parent op [ Upstream commit 51c100a651a471fcb8ead1ecc1224471eb0d61b9 ] The software_node_get_parent() returned a pointer to the parent swnode, but did not take a reference to it, leading the caller to put a reference that was not taken. Take that reference now. Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the firmware node framework") Signed-off-by: Sakari Ailus Reviewed-by: Heikki Krogerus Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3a77d9e20752b67cb3602cc5e4d9997f53e7d463 Author: Douglas Anderson Date: Thu Oct 3 11:47:30 2019 -0700 drm/rockchip: Round up _before_ giving to the clock framework [ Upstream commit 287422a95fe28e05c1952de0472e0dfdffa6caae ] I'm embarassed to say that even though I've touched vop_crtc_mode_fixup() twice and I swear I tested it, there's still a stupid glaring bug in it. Specifically, on veyron_minnie (with all the latest display timings) we want to be setting our pixel clock to 66,666,666.67 Hz and we tell userspace that's what we set, but we're actually choosing 66,000,000 Hz. This is confirmed by looking at the clock tree. The problem is that in drm_display_mode_from_videomode() we convert from Hz to kHz with: dmode->clock = vm->pixelclock / 1000; ...and drm_display_mode_from_videomode() is called from panel-simple when we have an "override_mode" like we do on veyron_minnie. See commit 123643e5c40a ("ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings"). ...so when the device tree specifies a clock of 66666667 for the panel then DRM translates that to 66666000. The clock framework will always pick a clock that is _lower_ than the one requested, so it will refuse to pick 66666667 and we'll end up at 66000000. While we could try to fix drm_display_mode_from_videomode() to round to the nearest kHz and it would fix our problem, it wouldn't help if the clock we actually needed was 60,000,001 Hz. We could alternatively have DRM always round up, but maybe this would break someone else who already baked in the assumption that DRM rounds down. Specifically note that clock drivers are not consistent about whether they round up or round down when you call clk_set_rate(). We know how Rockchip's clock driver works, but (for instance) you can see that on most Qualcomm clocks the default is clk_rcg2_ops which rounds up. Let's solve this by just adding 999 Hz before calling clk_round_rate(). This should be safe and work everywhere. As discussed in more detail in comments in the commit, Rockchip's PLLs are configured in a way that there shouldn't be another PLL setting that is only a few kHz off so we won't get mixed up. NOTE: if this is picked to stable, it's probably easiest to first pick commit 527e4ca3b6d1 ("drm/rockchip: Base adjustments of the mode based on prev adjustments") which shouldn't hurt in stable. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson Reviewed-by: Sean Paul Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191003114726.v2.1.Ib233b3e706cf6317858384264d5b0ed35657456e@changeid Signed-off-by: Sasha Levin commit 66f0a21ad07dfa47bb58742168cc3248699715b6 Author: Ioana Radulescu Date: Mon Oct 7 14:38:27 2019 +0300 dpaa2-eth: Fix minor bug in ethtool stats reporting [ Upstream commit 4b177f065e7ec37399b18e18412a8c7b75f8f299 ] Don't print error message for a successful return value. Fixes: d84c3a4ded96 ("dpaa2-eth: Add new DPNI statistics counters") Signed-off-by: Ioana Radulescu Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9af27538c55d7f838e1a0e465e40deaa033bf396 Author: Tony Lindgren Date: Sat Sep 14 14:02:55 2019 -0700 hwrng: omap3-rom - Fix missing clock by probing with device tree [ Upstream commit 0c0ef9ea6f3f0d5979dc7b094b0a184c1a94716b ] Commit 0ed266d7ae5e ("clk: ti: omap3: cleanup unnecessary clock aliases") removed old omap3 clock framework aliases but caused omap3-rom-rng to stop working with clock not found error. Based on discussions on the mailing list it was requested by Tero Kristo that it would be best to fix this issue by probing omap3-rom-rng using device tree to provide a proper clk property. The other option would be to add back the missing clock alias, but that does not help moving things forward with removing old legacy platform_data. Let's also add a proper device tree binding and keep it together with the fix. Cc: devicetree@vger.kernel.org Cc: Aaro Koskinen Cc: Adam Ford Cc: Pali Rohár Cc: Rob Herring Cc: Sebastian Reichel Cc: Tero Kristo Fixes: 0ed266d7ae5e ("clk: ti: omap3: cleanup unnecessary clock aliases") Reported-by: Aaro Koskinen Signed-off-by: Tony Lindgren Acked-by: Rob Herring Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6bdbfb6e7e8da254dbdfbb262d925a1da0cfb4d2 Author: yu kuai Date: Thu Sep 19 22:09:09 2019 +0800 drm/amdgpu: remove excess function parameter description [ Upstream commit d0580c09c65cff211f589a40e08eabc62da463fb ] Fixes gcc warning: drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:431: warning: Excess function parameter 'sw' description in 'vcn_v2_5_disable_clock_gating' drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:550: warning: Excess function parameter 'sw' description in 'vcn_v2_5_enable_clock_gating' Fixes: cbead2bdfcf1 ("drm/amdgpu: add VCN2.5 VCPU start and stop") Signed-off-by: yu kuai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d500cbaf0cc7f8e541e4b499941504dd1346541a Author: Dan Carpenter Date: Wed Sep 11 13:49:28 2019 +0300 drm: panel-lvds: Potential Oops in probe error handling [ Upstream commit fb2ee9bf084bcaeff1e5be100decc0eacb4af2d5 ] The "lvds->backlight" pointer could be NULL in situations where of_parse_phandle() returns NULL. This code is cleaner if we use the managed devm_of_find_backlight() so the clean up is automatic. Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver") Signed-off-by: Dan Carpenter Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190911104928.GA15930@mwanda Signed-off-by: Sasha Levin commit 9bd9e94fb95bbbf63d1d80adabfb13b297d1cdc7 Author: Steven Price Date: Thu Aug 22 10:32:18 2019 +0100 drm/panfrost: Add missing check for pfdev->regulator [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ] When modifying panfrost_devfreq_target() to support a device without a regulator defined I missed the check on the error path. Let's add it. Reported-by: Dan Carpenter Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator") Signed-off-by: Steven Price Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20190822093218.26014-1-steven.price@arm.com Signed-off-by: Sasha Levin commit f88ed5cf0d995b3a095839141dbd4eee49f0b913 Author: Ping-Ke Shih Date: Wed Oct 2 14:35:31 2019 +0800 rtw88: fix error handling when setup efuse info commit f4268729eb1eefe23f6746849c1b5626d9030532 upstream. Disable efuse if the efuse is enabled when we failed to setup the efuse information, otherwise the hardware will not turn off. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Ping-Ke Shih Signed-off-by: Yan-Hsuan Chuang Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 6b6d5f5338e82e21cf78e72828b79c861db0efab Author: Yan-Hsuan Chuang Date: Wed Oct 2 14:35:25 2019 +0800 rtw88: fix beaconing mode rsvd_page memory violation issue commit c3594559f49c601d410dee4b767c3536a5535bfd upstream. When downloading the reserved page, the first page always contains a beacon for the firmware to reference. For non-beaconing modes such as station mode, also put a blank skb with length=1. And for the beaconing modes, driver will get a real beacon with a length approximate to the page size. But as the beacon is always put at the first page, it does not need a tx_desc, because the TX path will generate one when TXing the reserved page to the hardware. So we could allocate a buffer with a size smaller than the reserved page, when using memcpy() to copy the content of reserved page to the buffer, the over-sized reserved page will violate the kernel memory. To fix it, add the tx_desc before memcpy() the reserved packets to the buffer, then we can get SKBs with correct length when counting the pages in total. And for page 0, count the extra tx_desc_sz that the TX path will generate. This way, the first beacon that allocated without tx_desc can be counted with the extra tx_desc_sz to get actual pages it requires. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Yan-Hsuan Chuang Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ddb46d9a909488c702046575df673aa3c5efe305 Author: Andy Shevchenko Date: Tue Nov 5 20:06:54 2019 +0200 gpiolib: No need to call gpiochip_remove_pin_ranges() twice commit 2f4133bb5f14f49a99acf0cc55b84996dbfb4dff upstream. of_gpiochip_add(), when fails, calls gpiochip_remove_pin_ranges(). ADD: gpiochip_add_data_with_key() -> of_gpiochip_add() -> (ERROR path) gpiochip_remove_pin_ranges() At the same time of_gpiochip_remove() calls exactly the above mentioned function unconditionally and so does gpiochip_remove(). REMOVE: gpiochip_remove() -> gpiochip_remove_pin_ranges() of_gpiochip_remove() -> gpiochip_remove_pin_ranges() Since gpiochip_remove() calls gpiochip_remove_pin_ranges() unconditionally, we have duplicate call to the same function when it's not necessary. Move gpiochip_remove_pin_ranges() from of_gpiochip_add() to gpiochip_add() to avoid duplicate calls and be consistent with the explicit call in gpiochip_remove(). Fixes: e93fa3f24353 ("gpiolib: remove duplicate pin range code") Depends-on: f7299d441a4d ("gpio: of: Fix of_gpiochip_add() error path") Cc: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 37bb3c4646818d15089fe2c48424d52700743a93 Author: Peter Zijlstra Date: Fri Nov 8 14:16:00 2019 +0100 sched/core: Further clarify sched_class::set_next_task() commit a0e813f26ebcb25c0b5e504498fbd796cca1a4ba upstream. It turns out there really is something special to the first set_next_task() invocation. In specific the 'change' pattern really should not cause balance callbacks. Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bsegall@google.com Cc: dietmar.eggemann@arm.com Cc: juri.lelli@redhat.com Cc: ktkhai@virtuozzo.com Cc: mgorman@suse.de Cc: qais.yousef@arm.com Cc: qperret@google.com Cc: rostedt@goodmis.org Cc: valentin.schneider@arm.com Cc: vincent.guittot@linaro.org Fixes: f95d4eaee6d0 ("sched/{rt,deadline}: Fix set_next_task vs pick_next_task") Link: https://lkml.kernel.org/r/20191108131909.775434698@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 57d748f43f0742f58b5cf01b2d7b9a0d2e113e3d Author: Navid Emamdoost Date: Mon Oct 21 15:06:48 2019 -0500 ipmi: Fix memory leak in __ipmi_bmc_register commit 4aa7afb0ee20a97fbf0c5bab3df028d5fb85fdab upstream. In the impelementation of __ipmi_bmc_register() the allocated memory for bmc should be released in case ida_simple_get() fails. Fixes: 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name") Signed-off-by: Navid Emamdoost Message-Id: <20191021200649.1511-1-navid.emamdoost@gmail.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 2b35a576043f37641a1743ad0dd8cbf88161992c Author: Shuiqing Li Date: Fri Nov 8 18:57:12 2019 +0800 watchdog: sprd: Fix the incorrect pointer getting from driver data commit 39e68d9e7ab276880980ee5386301fb218202192 upstream. The device driver data saved the 'struct sprd_wdt' object, it is incorrect to get 'struct watchdog_device' object from the driver data, thus fix it. Fixes: 477603467009 ("watchdog: Add Spreadtrum watchdog driver") Reported-by: Dongwei Wang Signed-off-by: Shuiqing Li Signed-off-by: Baolin Wang Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/76d4687189ec940baa90cb8d679a8d4c8f02ee80.1573210405.git.baolin.wang@linaro.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 8a43239f46a557b8444be4f0119d1354993af0ff Author: Luc Van Oostenryck Date: Thu Nov 21 15:48:51 2019 +1030 soc: aspeed: Fix snoop_file_poll()'s return type commit a4e55ccd4392e70f296d12e81b93c6ca96ee21d5 upstream. snoop_file_poll() is defined as returning 'unsigned int' but the .poll method is declared as returning '__poll_t', a bitwise type. Fix this by using the proper return type and using the EPOLL constants instead of the POLL ones, as required for __poll_t. Link: https://lore.kernel.org/r/20191121051851.268726-1-joel@jms.id.au Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Luc Van Oostenryck Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit f255ba7d639bb1be48417bef0e083b7989de44d9 Author: Geert Uytterhoeven Date: Wed Oct 16 16:33:06 2019 +0200 soc: renesas: Add missing check for non-zero product register address commit 4194b583c104922c6141d6610bfbce26847959df upstream. If the DTB for a device with an RZ/A2 SoC lacks a device node for the BSID register, the ID validation code falls back to using a register at address 0x0, which leads to undefined behavior (e.g. reading back a random value). This could be fixed by letting fam_rza2.reg point to the actual BSID register. However, the hardcoded fallbacks were meant for backwards compatibility with old DTBs only, not for new SoCs. Hence fix this by validating renesas_family.reg before using it. Fixes: 175f435f44b724e3 ("soc: renesas: identify RZ/A2") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191016143306.28995-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman commit fe20bda153045d9b9a2ea799a45c11a89d9ce63c Author: Stephen Boyd Date: Tue Oct 8 16:45:04 2019 -0700 soc: qcom: llcc: Name regmaps to avoid collisions commit 2bfd3e7651addcaf48f12d4f11ea9d8fca6c3aa8 upstream. We'll end up with debugfs collisions if we don't give names to the regmaps created by this driver. Change the name of the config before registering it so we don't collide in debugfs. Fixes: 7f9c136216c7 ("soc: qcom: Add broadcast base for Last Level Cache Controller (LLCC)") Cc: Venkata Narendra Kumar Gutta Reviewed-by: Evan Green Signed-off-by: Stephen Boyd Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit a9ec66b1c86dd664ed479c7c9d5c35382c52e19d Author: Thierry Reding Date: Tue Oct 1 13:48:29 2019 +0200 soc/tegra: pmc: Fix crashes for hierarchical interrupts commit c9e753767a9c75d2044fb7343950a6a992d34a16 upstream. Interrupts that don't have an associated wake event or GPIO wake events end up with an associate IRQ chip that is NULL and which causes IRQ code to crash. This is because we don't implicitly set the parent IRQ chip by allocating the interrupt at the parent. However, there really isn't a corresponding interrupt at the parent, so we need to work around this by setting the special no_irq_chip as the IRQ chip for these interrupts. Fixes: 19906e6b1667 ("soc/tegra: pmc: Add wake event support") Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 3af1974d54d4618b103f35b46101b9daeec9499c Author: Jean-Jacques Hiblot Date: Mon Sep 23 12:02:50 2019 +0200 leds: tlc591xx: update the maximum brightness commit a2cafdfd8cf5ad8adda6c0ce44a59f46431edf02 upstream. The TLC chips actually offer 257 levels: - 0: led OFF - 1-255: Led dimmed is using a PWM. The duty cycle range from 0.4% to 99.6% - 256: led fully ON Fixes: e370d010a5fe ("leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver") Signed-off-by: Jean-Jacques Hiblot Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 6498b7a5718e42ce9ee0954e1fa2a6942e8f7af1 Author: Arnaldo Carvalho de Melo Date: Thu Nov 14 10:46:45 2019 -0300 perf map: No need to adjust the long name of modules commit f068435d9bb2d825d59e3c101bc579f09315ee01 upstream. At some point in the past we needed to make sure we would get the long name of modules and not just what we get from /proc/modules, but that need, as described in the cset that introduced the adjustment function: Fixes: c03d5184f0e9 ("perf machine: Adjust dso->long_name for offline module") Without using the buildid-cache: # lsmod | grep trusted # insmod trusted.ko # lsmod | grep trusted trusted 24576 0 # strace -e open,openat perf probe -m ./trusted.ko key_seal |& grep trusted openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 4 openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 7 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/.debug/root/trusted.ko/dd3d355d567394d540f527e093e0f64b95879584/probes", O_RDWR|O_CREAT, 0644) = 3 openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/.debug/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, ".debug/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 4 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 probe:key_seal (on key_seal in trusted) # perf probe -l probe:key_seal (on key_seal in trusted) # No attempt at opening '[trusted]'. Now using the build-id cache: # rmmod trusted # perf buildid-cache --add ./trusted.ko # insmod trusted.ko # strace -e open,openat perf probe -m ./trusted.ko key_seal |& grep trusted openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 4 openat(AT_FDCWD, "/sys/module/trusted/notes/.note.gnu.build-id", O_RDONLY) = 7 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/.debug/root/trusted.ko/dd3d355d567394d540f527e093e0f64b95879584/probes", O_RDWR|O_CREAT, 0644) = 3 openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/debug/root/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/.debug/trusted.ko", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, ".debug/trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "trusted.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 4 openat(AT_FDCWD, "/root/trusted.ko", O_RDONLY) = 3 # Again, no attempt at reading '[trusted]'. Finally, adding a probe to that function and then using: [root@quaco ~]# perf trace -e probe_perf:*/max-stack=16/ --max-events=2 0.000 perf/13456 probe_perf:dso__adjust_kmod_long_name(__probe_ip: 5492263) dso__adjust_kmod_long_name (/home/acme/bin/perf) machine__process_kernel_mmap_event (/home/acme/bin/perf) machine__process_mmap_event (/home/acme/bin/perf) perf_event__process_mmap (/home/acme/bin/perf) machines__deliver_event (/home/acme/bin/perf) perf_session__deliver_event (/home/acme/bin/perf) perf_session__process_event (/home/acme/bin/perf) process_simple (/home/acme/bin/perf) reader__process_events (/home/acme/bin/perf) __perf_session__process_events (/home/acme/bin/perf) perf_session__process_events (/home/acme/bin/perf) process_buildids (/home/acme/bin/perf) record__finish_output (/home/acme/bin/perf) __cmd_record (/home/acme/bin/perf) cmd_record (/home/acme/bin/perf) run_builtin (/home/acme/bin/perf) 0.055 perf/13456 probe_perf:dso__adjust_kmod_long_name(__probe_ip: 5492263) dso__adjust_kmod_long_name (/home/acme/bin/perf) machine__process_kernel_mmap_event (/home/acme/bin/perf) machine__process_mmap_event (/home/acme/bin/perf) perf_event__process_mmap (/home/acme/bin/perf) machines__deliver_event (/home/acme/bin/perf) perf_session__deliver_event (/home/acme/bin/perf) perf_session__process_event (/home/acme/bin/perf) process_simple (/home/acme/bin/perf) reader__process_events (/home/acme/bin/perf) __perf_session__process_events (/home/acme/bin/perf) perf_session__process_events (/home/acme/bin/perf) process_buildids (/home/acme/bin/perf) record__finish_output (/home/acme/bin/perf) __cmd_record (/home/acme/bin/perf) cmd_record (/home/acme/bin/perf) run_builtin (/home/acme/bin/perf) # This was the only path I could find using the perf tools that reach at this function, then as of november/2019, if we put a probe in the line where the actuall setting of the dso->long_name is done: # perf trace -e probe_perf:* ^C[root@quaco ~] # perf stat -e probe_perf:* -I 2000 2.000404265 0 probe_perf:dso__adjust_kmod_long_name 4.001142200 0 probe_perf:dso__adjust_kmod_long_name 6.001704120 0 probe_perf:dso__adjust_kmod_long_name 8.002398316 0 probe_perf:dso__adjust_kmod_long_name 10.002984010 0 probe_perf:dso__adjust_kmod_long_name 12.003597851 0 probe_perf:dso__adjust_kmod_long_name 14.004113303 0 probe_perf:dso__adjust_kmod_long_name 16.004582773 0 probe_perf:dso__adjust_kmod_long_name 18.005176373 0 probe_perf:dso__adjust_kmod_long_name 20.005801605 0 probe_perf:dso__adjust_kmod_long_name 22.006467540 0 probe_perf:dso__adjust_kmod_long_name ^C 23.683261941 0 probe_perf:dso__adjust_kmod_long_name # Its not being used at all. To further test this I used kvm.ko as the offline module, i.e. removed if from the buildid-cache by nuking it completely (rm -rf ~/.debug) and moved it from the normal kernel distro path, removed the modules, stoped the kvm guest, and then installed it manually, etc. # rmmod kvm-intel # rmmod kvm # lsmod | grep kvm # modprobe kvm-intel modprobe: ERROR: ctx=0x55d3b1722260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory modprobe: ERROR: ctx=0x55d3b1722260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory modprobe: ERROR: could not insert 'kvm_intel': Unknown symbol in module, or unknown parameter (see dmesg) # insmod ./kvm.ko # modprobe kvm-intel modprobe: ERROR: ctx=0x562f34026260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory modprobe: ERROR: ctx=0x562f34026260 path=/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm/kvm.ko.xz error=No such file or directory # lsmod | grep kvm kvm_intel 299008 0 kvm 765952 1 kvm_intel irqbypass 16384 1 kvm # # perf probe -x ~/bin/perf machine__findnew_module_map:12 mname=m.name:string filename=filename:string 'dso_long_name=map->dso->long_name:string' 'dso_name=map->dso->name:string' # perf probe -l probe_perf:machine__findnew_module_map (on machine__findnew_module_map:12@util/machine.c in /home/acme/bin/perf with mname filename dso_long_name dso_name) # perf record ^C[ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 3.416 MB perf.data (33956 samples) ] # perf trace -e probe_perf:machine* 6.322 perf/23099 probe_perf:machine__findnew_module_map(__probe_ip: 5492493, mname: "[salsa20_generic]", filename: "/lib/modules/5.3.8-200.fc30.x86_64/kernel/crypto/salsa20_generic.ko.xz", dso_long_name: "/lib/modules/5.3.8-200.fc30.x86_64/kernel/crypto/salsa20_generic.ko.xz", dso_name: "[salsa20_generic]") 6.375 perf/23099 probe_perf:machine__findnew_module_map(__probe_ip: 5492493, mname: "[kvm]", filename: "[kvm]", dso_long_name: "[kvm]", dso_name: "[kvm]") The filename doesn't come with the path, no point in trying to set the dso->long_name. [root@quaco ~]# strace -e open,openat perf probe -m ./kvm.ko kvm_apic_local_deliver |& egrep 'open.*kvm' openat(AT_FDCWD, "/sys/module/kvm_intel/notes/.note.gnu.build-id", O_RDONLY) = 4 openat(AT_FDCWD, "/sys/module/kvm/notes/.note.gnu.build-id", O_RDONLY) = 4 openat(AT_FDCWD, "/lib/modules/5.3.8-200.fc30.x86_64/kernel/arch/x86/kvm", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 7 openat(AT_FDCWD, "/sys/module/kvm_intel/notes/.note.gnu.build-id", O_RDONLY) = 8 openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/.debug/root/kvm.ko/5955f426cb93f03f30f3e876814be2db80ab0b55/probes", O_RDWR|O_CREAT, 0644) = 3 openat(AT_FDCWD, "/usr/lib/debug/root/kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/debug/root/kvm.ko", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/.debug/kvm.ko", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3 openat(AT_FDCWD, "kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, ".debug/kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "kvm.ko.debug", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3 openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 4 openat(AT_FDCWD, "/root/kvm.ko", O_RDONLY) = 3 [root@quaco ~]# Cc: Adrian Hunter Cc: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-jlfew3lyb24d58egrp0o72o2@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit e1763c9456be68151543cccfa810ae0de1554384 Author: Corentin Labbe Date: Thu Nov 14 13:58:49 2019 +0100 crypto: sun4i-ss - fix big endian issues commit d1d787bcebfe122a5bd443ae565696661e2e9656 upstream. When testing BigEndian kernel, the sun4i-ss was failling all crypto tests. This patch fix endian issues with it. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 36148a8fdc2fa336304b8a0f302067125b0ebc24 Author: Christian Lamparter Date: Sun Oct 27 16:47:47 2019 +0100 crypto: amcc - restore CRYPTO_AES dependency commit 298b4c604008025b134bc6fccbc4018449945d60 upstream. This patch restores the CRYPTO_AES dependency. This is necessary since some of the crypto4xx driver provided modes need functioning software fallbacks for AES-CTR/CCM and GCM. Fixes: da3e7a9715ea ("crypto: amcc - switch to AES library for GCM key derivation") Cc: Ard Biesheuvel Signed-off-by: Christian Lamparter Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit cdac80457e88195e82c3bbe197faae89ab98fbaa Author: Patrick Steinhardt Date: Wed Dec 4 07:13:22 2019 +0100 nfsd: depend on CRYPTO_MD5 for legacy client tracking commit 38a2204f5298620e8a1c3b1dc7b831425106dbc0 upstream. The legacy client tracking infrastructure of nfsd makes use of MD5 to derive a client's recovery directory name. As the nfsd module doesn't declare any dependency on CRYPTO_MD5, though, it may fail to allocate the hash if the kernel was compiled without it. As a result, generation of client recovery directories will fail with the following error: NFSD: unable to generate recoverydir name The explicit dependency on CRYPTO_MD5 was removed as redundant back in 6aaa67b5f3b9 (NFSD: Remove redundant "select" clauses in fs/Kconfig 2008-02-11) as it was already implicitly selected via RPCSEC_GSS_KRB5. This broke when RPCSEC_GSS_KRB5 was made optional for NFSv4 in commit df486a25900f (NFS: Fix the selection of security flavours in Kconfig) at a later point. Fix the issue by adding back an explicit dependency on CRYPTO_MD5. Fixes: df486a25900f (NFS: Fix the selection of security flavours in Kconfig) Signed-off-by: Patrick Steinhardt Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit e8dea4ed48865460353e2833b40bacde8a3ce9fb Author: Heiko Carstens Date: Tue Nov 12 09:19:26 2019 +0100 s390/pkey: fix memory leak within _copy_apqns_from_user() commit f9cac4fd8878929c6ebff0bd272317905d77c38a upstream. Fixes: f2bbc96e7cfad ("s390/pkey: add CCA AES cipher key support") Reported-by: Markus Elfring Reported-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit d0198ab3a28fc7b0ae8199f44e151af9ddf09ee2 Author: Jesse Brandeburg Date: Fri Nov 8 06:23:21 2019 -0800 ice: fix stack leakage commit 949375de945f7042df2b6488228a1a2b36e69f35 upstream. In the case of an invalid virtchannel request the driver would return uninitialized data to the VF from the PF stack which is a bug. Fix by initializing the stack variable earlier in the function before any return paths can be taken. Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support") Signed-off-by: Jesse Brandeburg Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 2bc814d98e92f94b03ce51aa588491935d46c642 Author: Lorenzo Bianconi Date: Sat Sep 21 10:44:01 2019 +0200 mt7601u: fix bbp version check in mt7601u_wait_bbp_ready commit 15e14f76f85f4f0eab3b8146e1cd3c58ce272823 upstream. Fix bbp ready check in mt7601u_wait_bbp_ready. The issue is reported by coverity with the following error: Logical vs. bitwise operator The expression's value does not depend on the operands; inadvertent use of the wrong operator is a likely logic error. Addresses-Coverity-ID: 1309441 ("Logical vs. bitwise operator") Fixes: c869f77d6abb ("add mt7601u driver") Acked-by: Jakub Kicinski Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 1de9dd61f0e0cdaf25fa6e9f7f3eba046687b23c Author: Lorenzo Bianconi Date: Sun Nov 17 14:26:14 2019 +0200 mt76: mt76u: fix endpoint definition order commit 23cb16d2ccb5f819d7acff602e5a153157bf2884 upstream. Even if they are not currently used fix BK/BE endpoint definition order. Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 162854d6dd706d08b73e108ccd925e3da4045d31 Author: Grygorii Strashko Date: Wed Oct 23 17:47:44 2019 +0300 phy: ti: gmii-sel: fix mac tx internal delay for rgmii-rxid commit 316b429459066215abb50060873ec0832efc4044 upstream. Now phy-gmii-sel will disable MAC TX internal delay for PHY interface mode "rgmii-rxid" which is incorrect. Hence, fix it by enabling MAC TX internal delay in the case of "rgmii-rxid" mode. Fixes: 92b58b34741f ("phy: ti: introduce phy-gmii-sel driver") Signed-off-by: Grygorii Strashko Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit 52fa627e20df2ea352bf1ecec636d8f81a196bbd Author: Florian Fainelli Date: Thu Oct 3 11:43:51 2019 -0700 net: phy: broadcom: Fix RGMII delays configuration for BCM54210E commit fea7fda7f50a6059220f83251e70709e45cc8040 upstream. Commit 0fc9ae107669 ("net: phy: broadcom: add support for BCM54210E") added support for BCM54210E but also unconditionally cleared the RXC to RXD skew and the TXD to TXC skew, thus only making PHY_INTERFACE_MODE_RGMII a possible configuration. Use bcm54xx_config_clock_delay() which correctly sets the registers depending on the 4 possible PHY interface values that exist for RGMII. Fixes: 0fc9ae107669 ("net: phy: broadcom: add support for BCM54210E") Reported-by: Manasa Mudireddy Reported-by: Ray Jui Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1f51f661fd2be6349441a2aa8e558409d37b6aab Author: Wei Yongjun Date: Wed Sep 4 11:40:14 2019 +0000 phy: lantiq: vrx200-pcie: fix error return code in ltq_vrx200_pcie_phy_power_on() commit 82b5d164415549e74cfa1f9156ffd4463d0a76e2 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: e52a632195bf ("phy: lantiq: vrx200-pcie: add a driver for the Lantiq VRX200 PCIe PHY") Signed-off-by: Wei Yongjun Reviewed-by: Martin Blumenstingl Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Greg Kroah-Hartman commit 142cb2bd612d0dfe7ef5d5fa788bcb7b10d6b4f2 Author: Roi Dayan Date: Mon Dec 2 19:19:47 2019 +0200 net/mlx5e: Fix free peer_flow when refcount is 0 commit eb252c3a24fc5856fa62140c2f8269ddce6ce4e5 upstream. It could be neigh update flow took a refcount on peer flow so sometimes we cannot release peer flow even if parent flow is being freed now. Fixes: 5a7e5bcb663d ("net/mlx5e: Extend tc flow struct with reference counter") Signed-off-by: Roi Dayan Reviewed-by: Eli Britstein Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 9bc7663b711a6f3c46f35f6b7e1d53449f451b2f Author: Tung Nguyen Date: Thu Nov 28 10:10:07 2019 +0700 tipc: fix wrong timeout input for tipc_wait_for_cond() commit 12db3c8083fcab4270866a88191933f2d9f24f89 upstream. In function __tipc_shutdown(), the timeout value passed to tipc_wait_for_cond() is not jiffies. This commit fixes it by converting that value from milliseconds to jiffies. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Signed-off-by: Tung Nguyen Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 58e007884a7bf7ad34552f266e7bb51cc9a7273b Author: Tung Nguyen Date: Thu Nov 28 10:10:06 2019 +0700 tipc: fix wrong socket reference counter after tipc_sk_timeout() returns commit 91a4a3eb433e4d786420c41f3c08d1d16c605962 upstream. When tipc_sk_timeout() is executed but user space is grabbing ownership, this function rearms itself and returns. However, the socket reference counter is not reduced. This causes potential unexpected behavior. This commit fixes it by calling sock_put() before tipc_sk_timeout() returns in the above-mentioned case. Fixes: afe8792fec69 ("tipc: refactor function tipc_sk_timeout()") Signed-off-by: Tung Nguyen Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 55a0b2c95fd47db2adfeae50840c4b3a87c56179 Author: Tung Nguyen Date: Thu Nov 28 10:10:05 2019 +0700 tipc: fix potential memory leak in __tipc_sendmsg() commit 2fe97a578d7bad3116a89dc8a6692a51e6fc1d9c upstream. When initiating a connection message to a server side, the connection message is cloned and added to the socket write queue. However, if the cloning is failed, only the socket write queue is purged. It causes memory leak because the original connection message is not freed. This commit fixes it by purging the list of connection message when it cannot be cloned. Fixes: 6787927475e5 ("tipc: buffer overflow handling in listener socket") Reported-by: Hoang Le Signed-off-by: Tung Nguyen Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 28845c28f842e9e55e75b2c116bff714bb039055 Author: Hoang Le Date: Tue Nov 12 07:40:04 2019 +0700 tipc: update mon's self addr when node addr generated commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 upstream. In commit 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values"), the 32-bit node address only generated after one second trial period expired. However the self's addr in struct tipc_monitor do not update according to node address generated. This lead to it is always zero as initial value. As result, sorting algorithm using this value does not work as expected, neither neighbor monitoring framework. In this commit, we add a fix to update self's addr when 32-bit node address generated. Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values") Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b3182a666aea23ef14cc7e1df5baa712b02f87bd Author: Hoang Le Date: Wed Nov 6 13:26:10 2019 +0700 tipc: reduce sensitive to retransmit failures commit 426071f1f3995d7e9603246bffdcbf344cd31719 upstream. With huge cluster (e.g >200nodes), the amount of that flow: gap -> retransmit packet -> acked will take time in case of STATE_MSG dropped/delayed because a lot of traffic. This lead to 1.5 sec tolerance value criteria made link easy failure around 2nd, 3rd of failed retransmission attempts. Instead of re-introduced criteria of 99 faled retransmissions to fix the issue, we increase failure detection timer to ten times tolerance value. Fixes: 77cf8edbc0e7 ("tipc: simplify stale link failure criteria") Acked-by: Jon Maloy Signed-off-by: Hoang Le Acked-by: Jon Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81c13f38975dd1f51538cde88584eed3f2c0c928 Author: Ard Biesheuvel Date: Wed Dec 4 11:50:15 2019 +0000 powerpc/archrandom: fix arch_get_random_seed_int() commit b6afd1234cf93aa0d71b4be4788c47534905f0be upstream. Commit 01c9348c7620ec65 powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_* updated arch_get_random_[int|long]() to be NOPs, and moved the hardware RNG backing to arch_get_random_seed_[int|long]() instead. However, it failed to take into account that arch_get_random_int() was implemented in terms of arch_get_random_long(), and so we ended up with a version of the former that is essentially a NOP as well. Fix this by calling arch_get_random_seed_long() from arch_get_random_seed_int() instead. Fixes: 01c9348c7620ec65 ("powerpc: Use hardware RNG for arch_get_random_seed_* not arch_get_random_*") Signed-off-by: Ard Biesheuvel Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191204115015.18015-1-ardb@kernel.org Signed-off-by: Greg Kroah-Hartman commit 618e593b090202383d5dc5336e4aa7692c0e2d61 Author: Christophe Leroy Date: Fri Nov 29 14:26:41 2019 +0000 powerpc/kasan: Fix boot failure with RELOCATABLE && FSL_BOOKE commit 71eb40fc53371bc247c8066ae76ad9e22ae1e18d upstream. When enabling CONFIG_RELOCATABLE and CONFIG_KASAN on FSL_BOOKE, the kernel doesn't boot. relocate_init() requires KASAN early shadow area to be set up because it needs access to the device tree through generic functions. Call kasan_early_init() before calling relocate_init() Reported-by: Lexi Shao Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/b58426f1664a4b344ff696d18cacf3b3e8962111.1575036985.git.christophe.leroy@c-s.fr Signed-off-by: Greg Kroah-Hartman commit 0254daa0aebbb27f777e1423e535dcae37f7a191 Author: Tyrel Datwyler Date: Sun Nov 10 23:21:37 2019 -0600 powerpc/pseries: Enable support for ibm,drc-info property commit 0a87ccd3699983645f54cafd2258514a716b20b8 upstream. Advertise client support for the PAPR architected ibm,drc-info device tree property during CAS handshake. Fixes: c7a3275e0f9e ("powerpc/pseries: Revert support for ibm,drc-info devtree property") Signed-off-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1573449697-5448-11-git-send-email-tyreld@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit d5c4594b2043c4eefaae3dbf6f5deb198e33b89f Author: Geert Uytterhoeven Date: Mon Oct 21 16:23:09 2019 +0200 powerpc/security: Fix debugfs data leak on 32-bit commit 3b05a1e517e1a8cfda4866ec31d28b2bc4fee4c4 upstream. "powerpc_security_features" is "unsigned long", i.e. 32-bit or 64-bit, depending on the platform (PPC_FSL_BOOK3E or PPC_BOOK3S_64). Hence casting its address to "u64 *", and calling debugfs_create_x64() is wrong, and leaks 32-bit of nearby data to userspace on 32-bit platforms. While all currently defined SEC_FTR_* security feature flags fit in 32-bit, they all have "ULL" suffixes to make them 64-bit constants. Hence fix the leak by changing the type of "powerpc_security_features" (and the parameter types of its accessors) to "u64". This also allows to drop the cast. Fixes: 398af571128fe75f ("powerpc/security: Show powerpc_security_features in debugfs") Signed-off-by: Geert Uytterhoeven Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191021142309.28105-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman commit 46fabfd623a88fc1f4695cff420a7855e4078010 Author: Chuck Lever Date: Wed Nov 20 16:25:46 2019 -0500 SUNRPC: Fix backchannel latency metrics commit 8729aaba74626c4ebce3abf1b9e96bb62d2958ca upstream. I noticed that for callback requests, the reported backlog latency is always zero, and the rtt value is crazy big. The problem was that rqst->rq_xtime is never set for backchannel requests. Fixes: 78215759e20d ("SUNRPC: Make RTT measurement more ... ") Signed-off-by: Chuck Lever Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 7be8c165dc81564705e8e0b72d398ef708f67eaa Author: Chuck Lever Date: Thu Oct 24 09:34:16 2019 -0400 SUNRPC: Fix svcauth_gss_proxy_init() commit 5866efa8cbfbadf3905072798e96652faf02dbe8 upstream. gss_read_proxy_verf() assumes things about the XDR buffer containing the RPC Call that are not true for buffers generated by svc_rdma_recv(). RDMA's buffers look more like what the upper layer generates for sending: head is a kmalloc'd buffer; it does not point to a page whose contents are contiguous with the first page in the buffers' page array. The result is that ACCEPT_SEC_CONTEXT via RPC/RDMA has stopped working on Linux NFS servers that use gssproxy. This does not affect clients that use only TCP to send their ACCEPT_SEC_CONTEXT operation (that's all Linux clients). Other clients, like Solaris NFS clients, send ACCEPT_SEC_CONTEXT on the same transport as they send all other NFS operations. Such clients can send ACCEPT_SEC_CONTEXT via RPC/RDMA. I thought I had found every direct reference in the server RPC code to the rqstp->rq_pages field. Bug found at the 2019 Westford NFS bake-a-thon. Fixes: 3316f0631139 ("svcrdma: Persistently allocate and DMA- ... ") Signed-off-by: Chuck Lever Tested-by: Bill Baker Reviewed-by: Simo Sorce Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit f8120a689b71dabf356f6120eddd272ca2f0f22f Author: Jarkko Nikula Date: Wed Sep 4 08:56:25 2019 +0300 mfd: intel-lpss: Add default I2C device properties for Gemini Lake commit 3f31bc67e4dc6a555341dffefe328ddd58e8b431 upstream. It turned out Intel Gemini Lake doesn't use the same I2C timing parameters as Broxton. I got confirmation from the Windows team that Gemini Lake systems should use updated timing parameters that differ from those used in Broxton based systems. Fixes: f80e78aa11ad ("mfd: intel-lpss: Add Intel Gemini Lake PCI IDs") Tested-by: Chris Chiu Signed-off-by: Jarkko Nikula Acked-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 45f884c2adfec0bc6543612b2f4cc3d13ba05262 Author: Alain Volmat Date: Tue Nov 12 09:19:44 2019 +0100 i2c: i2c-stm32f7: fix 10-bits check in slave free id search loop commit 7787657d7ee55a9ecf4aea4907b46b87a44eda67 upstream. Fix a typo in the free slave id search loop. Instead of I2C_CLIENT_PEC, it should have been I2C_CLIENT_TEN. The slave id 1 can only handle 7-bit addresses and thus is not eligible in case of 10-bit addresses. As a matter of fact none of the slave id support I2C_CLIENT_PEC, overall check is performed at the beginning of the stm32f7_i2c_reg_slave function. Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit cd1061bc2bc6eca48da633053d521742ce025b96 Author: Alain Volmat Date: Tue Oct 15 15:03:09 2019 +0200 i2c: stm32f7: rework slave_id allocation commit 52d3be711e065a97a57c2f2ffba3098748855bd6 upstream. The IP can handle two slave addresses. One address can either be 7 bits or 10 bits while the other can only be 7 bits. In order to ensure that a 10 bits address can always be allocated (assuming there is only one 7 bits address already allocated), pick up the 7-bits only address slot in priority when performing a 7-bits address allocation. Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit dc08e4455a169ac18c7dfba3879aeceaf089f7c8 Author: Jan Kara Date: Wed Oct 23 17:00:45 2019 -0700 xfs: Sanity check flags of Q_XQUOTARM call commit 3dd4d40b420846dd35869ccc8f8627feef2cff32 upstream. Flags passed to Q_XQUOTARM were not sanity checked for invalid values. Fix that. Fixes: 9da93f9b7cdf ("xfs: fix Q_XQUOTARM ioctl") Reported-by: Yang Xu Signed-off-by: Jan Kara Reviewed-by: Eric Sandeen Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit da22b367d9bda32dd77168bd71d028f3182cfd21 Author: Markus Elfring Date: Sat Nov 9 17:19:35 2019 +0100 ARM: OMAP2+: Add missing put_device() call in omapdss_init_of() commit 0b491904f053e41685162af5c5411b85b18c97a7 upstream. A coccicheck run provided information like the following. arch/arm/mach-omap2/display.c:268:2-8: ERROR: missing put_device; call of_find_device_by_node on line 258, but without a corresponding object release within this function. Generated by: scripts/coccinelle/free/put_device.cocci Thus add the missed function call to fix the exception handling for this function implementation. Fixes: e0c827aca0730b51f38081aa4e8ecf0912aab55f ("drm/omap: Populate DSS children in omapdss driver") Signed-off-by: Markus Elfring Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 7b9014d17cbe3bfe6c7a830ed6061a3de9aafc56 Author: Adam Ford Date: Wed Oct 16 08:51:47 2019 -0500 ARM: dts: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel commit a177057a95f6a3f1e0e52a17eea2178c15073648 upstream. With the removal of the panel-dpi from the omap drivers, the LCD no longer works. This patch points the device tree to a newly created panel named "logicpd,type28" Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver") Signed-off-by: Adam Ford Acked-by: Sam Ravnborg Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 634813e41f85355a5dc7e032a0933495694f8b1a Author: Jesper Dangaard Brouer Date: Mon Dec 2 13:37:31 2019 +0100 samples/bpf: Fix broken xdp_rxq_info due to map order assumptions commit edbca120a8cdfa5a5793707e33497aa5185875ca upstream. In the days of using bpf_load.c the order in which the 'maps' sections were defines in BPF side (*_kern.c) file, were used by userspace side to identify the map via using the map order as an index. In effect the order-index is created based on the order the maps sections are stored in the ELF-object file, by the LLVM compiler. This have also carried over in libbpf via API bpf_map__next(NULL, obj) to extract maps in the order libbpf parsed the ELF-object file. When BTF based maps were introduced a new section type ".maps" were created. I found that the LLVM compiler doesn't create the ".maps" sections in the order they are defined in the C-file. The order in the ELF file is based on the order the map pointer is referenced in the code. This combination of changes lead to xdp_rxq_info mixing up the map file-descriptors in userspace, resulting in very broken behaviour, but without warning the user. This patch fix issue by instead using bpf_object__find_map_by_name() to find maps via their names. (Note, this is the ELF name, which can be longer than the name the kernel retains). Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157529025128.29832.5953245340679936909.stgit@firesoul Signed-off-by: Greg Kroah-Hartman commit 76aff568ee2df8d7f86713391f48ca6aa5cfa260 Author: Daniel T. Lee Date: Thu Nov 7 09:51:53 2019 +0900 samples: bpf: update map definition to new syntax BTF-defined map commit 451d1dc886b548d6e18c933adca326c1307023c9 upstream. Since, the new syntax of BTF-defined map has been introduced, the syntax for using maps under samples directory are mixed up. For example, some are already using the new syntax, and some are using existing syntax by calling them as 'legacy'. As stated at commit abd29c931459 ("libbpf: allow specifying map definitions using BTF"), the BTF-defined map has more compatablility with extending supported map definition features. The commit doesn't replace all of the map to new BTF-defined map, because some of the samples still use bpf_load instead of libbpf, which can't properly create BTF-defined map. This will only updates the samples which uses libbpf API for loading bpf program. (ex. bpf_prog_load_xattr) Signed-off-by: Daniel T. Lee Acked-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit c2227983d535bf4ac8444ad72c0b4be244dce9d3 Author: Stanislav Fomichev Date: Wed Nov 27 14:57:59 2019 -0800 bpf: Force .BTF section start to zero when dumping from vmlinux commit df786c9b947639aedbc7bb44b5dae2a7824af360 upstream. While trying to figure out why fentry_fexit selftest doesn't pass for me (old pahole, broken BTF), I found out that my latest patch can break vmlinux .BTF generation. objcopy preserves section start when doing --only-section, so there is a chance (depending on where pahole inserts .BTF section) to have leading empty zeroes. Let's explicitly force section offset to zero. Before: $ objcopy --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ After: $ objcopy --change-section-address .BTF=0 \ --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 9feb 0100 1800 0000 0000 0000 80e1 1c00 ................ ^BTF magic As part of this change, I'm also dropping '2>/dev/null' from objcopy invocation to be able to catch possible other issues (objcopy doesn't produce any warnings for me anymore, it did before with --dump-section). Fixes: da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for vmlinux BTF") Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Cc: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191127225759.39923-1-sdf@google.com Signed-off-by: Greg Kroah-Hartman commit 2948fecb0e3f2364b79b1d306712468014d135dd Author: Andrii Nakryiko Date: Wed Nov 6 18:08:54 2019 -0800 libbpf: Make btf__resolve_size logic always check size error condition commit 994021a7e08477f7e51285920aac99fc967fae8a upstream. Perform size check always in btf__resolve_size. Makes the logic a bit more robust against corrupted BTF and silences LGTM/Coverity complaining about always true (size < 0) check. Fixes: 69eaab04c675 ("btf: extract BTF type size calculation") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191107020855.3834758-5-andriin@fb.com Signed-off-by: Greg Kroah-Hartman commit 5a3c8e037978e963469395b091e553a479f576c0 Author: Andrii Nakryiko Date: Wed Nov 6 18:08:53 2019 -0800 libbpf: Fix another potential overflow issue in bpf_prog_linfo commit dd3ab126379ec040b3edab8559f9c72de6ef9d29 upstream. Fix few issues found by Coverity and LGTM. Fixes: b053b439b72a ("bpf: libbpf: bpftool: Print bpf_line_info during prog dump") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191107020855.3834758-4-andriin@fb.com Signed-off-by: Greg Kroah-Hartman commit 02d3c2fb209ff786e844cbe062e942eba5401bf4 Author: Andrii Nakryiko Date: Wed Nov 6 18:08:52 2019 -0800 libbpf: Fix potential overflow issue commit 4ee1135615713387b869dfd099ffdf8656be6784 upstream. Fix a potential overflow issue found by LGTM analysis, based on Github libbpf source code. Fixes: 3d65014146c6 ("bpf: libbpf: Add btf_line_info support to libbpf") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191107020855.3834758-3-andriin@fb.com Signed-off-by: Greg Kroah-Hartman commit 2bc794f2038e1cbb0c39b6f2c462e75e49c9bccc Author: Andrii Nakryiko Date: Wed Nov 6 18:08:51 2019 -0800 libbpf: Fix memory leak/double free issue commit 3dc5e059821376974177cc801d377e3fcdac6712 upstream. Coverity scan against Github libbpf code found the issue of not freeing memory and leaving already freed memory still referenced from bpf_program. Fix it by re-assigning successfully reallocated memory sooner. Fixes: 2993e0515bb4 ("tools/bpf: add support to read .BTF.ext sections") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191107020855.3834758-2-andriin@fb.com Signed-off-by: Greg Kroah-Hartman commit 8fb2e3c739228e932d3fc99c272b75f37bd3b5ee Author: Magnus Karlsson Date: Fri Oct 25 11:17:15 2019 +0200 libbpf: Fix compatibility for kernels without need_wakeup commit 94ff9ebb49a546b7f009ed840bafa235c96d4c4b upstream. When the need_wakeup flag was added to AF_XDP, the format of the XDP_MMAP_OFFSETS getsockopt was extended. Code was added to the kernel to take care of compatibility issues arrising from running applications using any of the two formats. However, libbpf was not extended to take care of the case when the application/libbpf uses the new format but the kernel only supports the old format. This patch adds support in libbpf for parsing the old format, before the need_wakeup flag was added, and emulating a set of static need_wakeup flags that will always work for the application. v2 -> v3: * Incorporated code improvements suggested by Jonathan Lemon v1 -> v2: * Rebased to bpf-next * Rewrote the code as the previous version made you blind Fixes: a4500432c2587cb2a ("libbpf: add support for need_wakeup flag in AF_XDP part") Reported-by: Eloy Degen Signed-off-by: Magnus Karlsson Signed-off-by: Alexei Starovoitov Acked-by: Jonathan Lemon Link: https://lore.kernel.org/bpf/1571995035-21889-1-git-send-email-magnus.karlsson@intel.com Signed-off-by: Greg Kroah-Hartman commit e380176dad397656d3315c1a72c1f057750154a0 Author: Tvrtko Ursulin Date: Tue Dec 17 17:09:33 2019 +0000 drm/i915: Fix pid leak with banned clients commit f0f3a6cecf3b98990985cd42f7bf5a0313894822 upstream. Get_pid_task() needs to be paired with a put_pid or we leak a pid reference every time a banned client tries to create a context. v2: * task_pid_nr helper exists! (Chris) Signed-off-by: Tvrtko Ursulin Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit") Cc: Chris Wilson Cc: Mika Kuoppala Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20191217170933.8108-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit ba16a48af797db124ac100417f9229b1650ce1fb) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman