commit e073346387ab794b06409f0708bbc0aa6b99a4fb Author: Greg Kroah-Hartman Date: Thu Mar 4 12:15:45 2021 +0100 Linux 5.11.3 Tested-by: Shuah Khan Reported-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Jason Self Link: https://lore.kernel.org/r/20210301161201.679371205@linuxfoundation.org Link: https://lore.kernel.org/r/20210301193729.179652916@linuxfoundation.org Link: https://lore.kernel.org/r/20210302192719.741064351@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 53c88efbcc09eb9e430b056936165c29396f82f1 Author: John Wang Date: Wed Dec 2 13:16:34 2020 +0800 ARM: dts: aspeed: Add LCLK to lpc-snoop commit d050d049f8b8077025292c1ecf456c4ee7f96861 upstream. Signed-off-by: John Wang Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20201202051634.490-2-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman commit ad9ed727ac8e78f5e024a6d7b961116955e40056 Author: Cong Wang Date: Sat Jan 16 16:56:57 2021 -0800 net_sched: fix RTNL deadlock again caused by request_module() commit d349f997686887906b1183b5be96933c5452362a upstream. tcf_action_init_1() loads tc action modules automatically with request_module() after parsing the tc action names, and it drops RTNL lock and re-holds it before and after request_module(). This causes a lot of troubles, as discovered by syzbot, because we can be in the middle of batch initializations when we create an array of tc actions. One of the problem is deadlock: CPU 0 CPU 1 rtnl_lock(); for (...) { tcf_action_init_1(); -> rtnl_unlock(); -> request_module(); rtnl_lock(); for (...) { tcf_action_init_1(); -> tcf_idr_check_alloc(); // Insert one action into idr, // but it is not committed until // tcf_idr_insert_many(), then drop // the RTNL lock in the _next_ // iteration -> rtnl_unlock(); -> rtnl_lock(); -> a_o->init(); -> tcf_idr_check_alloc(); // Now waiting for the same index // to be committed -> request_module(); -> rtnl_lock() // Now waiting for RTNL lock } rtnl_unlock(); } rtnl_unlock(); This is not easy to solve, we can move the request_module() before this loop and pre-load all the modules we need for this netlink message and then do the rest initializations. So the loop breaks down to two now: for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) { struct tc_action_ops *a_o; a_o = tc_action_load_ops(name, tb[i]...); ops[i - 1] = a_o; } for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) { act = tcf_action_init_1(ops[i - 1]...); } Although this looks serious, it only has been reported by syzbot, so it seems hard to trigger this by humans. And given the size of this patch, I'd suggest to make it to net-next and not to backport to stable. This patch has been tested by syzbot and tested with tdc.py by me. Fixes: 0fedc63fadf0 ("net_sched: commit action insertions together") Reported-and-tested-by: syzbot+82752bc5331601cf4899@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+b3b63b6bff456bd95294@syzkaller.appspotmail.com Reported-by: syzbot+ba67b12b1ca729912834@syzkaller.appspotmail.com Cc: Jiri Pirko Signed-off-by: Cong Wang Tested-by: Jamal Hadi Salim Acked-by: Jamal Hadi Salim Link: https://lore.kernel.org/r/20210117005657.14810-1-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 750942f0a11da5b803362c751ad5d3fcde2606b8 Author: Takeshi Misawa Date: Mon Feb 22 08:44:27 2021 +0900 net: qrtr: Fix memory leak in qrtr_tun_open commit fc0494ead6398609c49afa37bc949b61c5c16b91 upstream. If qrtr_endpoint_register() failed, tun is leaked. Fix this, by freeing tun in error path. syzbot report: BUG: memory leak unreferenced object 0xffff88811848d680 (size 64): comm "syz-executor684", pid 10171, jiffies 4294951561 (age 26.070s) hex dump (first 32 bytes): 80 dd 0a 84 ff ff ff ff 00 00 00 00 00 00 00 00 ................ 90 d6 48 18 81 88 ff ff 90 d6 48 18 81 88 ff ff ..H.......H..... backtrace: [<0000000018992a50>] kmalloc include/linux/slab.h:552 [inline] [<0000000018992a50>] kzalloc include/linux/slab.h:682 [inline] [<0000000018992a50>] qrtr_tun_open+0x22/0x90 net/qrtr/tun.c:35 [<0000000003a453ef>] misc_open+0x19c/0x1e0 drivers/char/misc.c:141 [<00000000dec38ac8>] chrdev_open+0x10d/0x340 fs/char_dev.c:414 [<0000000079094996>] do_dentry_open+0x1e6/0x620 fs/open.c:817 [<000000004096d290>] do_open fs/namei.c:3252 [inline] [<000000004096d290>] path_openat+0x74a/0x1b00 fs/namei.c:3369 [<00000000b8e64241>] do_filp_open+0xa0/0x190 fs/namei.c:3396 [<00000000a3299422>] do_sys_openat2+0xed/0x230 fs/open.c:1172 [<000000002c1bdcef>] do_sys_open fs/open.c:1188 [inline] [<000000002c1bdcef>] __do_sys_openat fs/open.c:1204 [inline] [<000000002c1bdcef>] __se_sys_openat fs/open.c:1199 [inline] [<000000002c1bdcef>] __x64_sys_openat+0x7f/0xe0 fs/open.c:1199 [<00000000f3a5728f>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<000000004b38b7ec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 28fb4e59a47d ("net: qrtr: Expose tunneling endpoint to user space") Reported-by: syzbot+5d6e4af21385f5cfc56a@syzkaller.appspotmail.com Signed-off-by: Takeshi Misawa Link: https://lore.kernel.org/r/20210221234427.GA2140@DESKTOP Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8a0666e14620939a961b4597e60cd6a40efde242 Author: Vlad Buslov Date: Tue Feb 16 18:22:00 2021 +0200 net: sched: fix police ext initialization commit 396d7f23adf9e8c436dd81a69488b5b6a865acf8 upstream. When police action is created by cls API tcf_exts_validate() first conditional that calls tcf_action_init_1() directly, the action idr is not updated according to latest changes in action API that require caller to commit newly created action to idr with tcf_idr_insert_many(). This results such action not being accessible through act API and causes crash reported by syzbot: ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:71 [inline] BUG: KASAN: null-ptr-deref in atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] BUG: KASAN: null-ptr-deref in __tcf_idr_release net/sched/act_api.c:178 [inline] BUG: KASAN: null-ptr-deref in tcf_idrinfo_destroy+0x129/0x1d0 net/sched/act_api.c:598 Read of size 4 at addr 0000000000000010 by task kworker/u4:5/204 CPU: 0 PID: 204 Comm: kworker/u4:5 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 __kasan_report mm/kasan/report.c:400 [inline] kasan_report.cold+0x5f/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 instrument_atomic_read include/linux/instrumented.h:71 [inline] atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] __tcf_idr_release net/sched/act_api.c:178 [inline] tcf_idrinfo_destroy+0x129/0x1d0 net/sched/act_api.c:598 tc_action_net_exit include/net/act_api.h:151 [inline] police_exit_net+0x168/0x360 net/sched/act_police.c:390 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:190 cleanup_net+0x4ea/0xb10 net/core/net_namespace.c:604 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 ================================================================== Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 204 Comm: kworker/u4:5 Tainted: G B 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 panic+0x306/0x73d kernel/panic.c:231 end_report+0x58/0x5e mm/kasan/report.c:100 __kasan_report mm/kasan/report.c:403 [inline] kasan_report.cold+0x67/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 instrument_atomic_read include/linux/instrumented.h:71 [inline] atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] __tcf_idr_release net/sched/act_api.c:178 [inline] tcf_idrinfo_destroy+0x129/0x1d0 net/sched/act_api.c:598 tc_action_net_exit include/net/act_api.h:151 [inline] police_exit_net+0x168/0x360 net/sched/act_police.c:390 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:190 cleanup_net+0x4ea/0xb10 net/core/net_namespace.c:604 process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Kernel Offset: disabled Fix the issue by calling tcf_idr_insert_many() after successful action initialization. Fixes: 0fedc63fadf0 ("net_sched: commit action insertions together") Reported-by: syzbot+151e3e714d34ae4ce7e8@syzkaller.appspotmail.com Signed-off-by: Vlad Buslov Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2e4f53852c2da465b19bcc604a678a68c275622f Author: Jason A. Donenfeld Date: Mon Feb 22 17:25:48 2021 +0100 wireguard: queueing: get rid of per-peer ring buffers commit 8b5553ace83cced775eefd0f3f18b5c6214ccf7a upstream. Having two ring buffers per-peer means that every peer results in two massive ring allocations. On an 8-core x86_64 machine, this commit reduces the per-peer allocation from 18,688 bytes to 1,856 bytes, which is an 90% reduction. Ninety percent! With some single-machine deployments approaching 500,000 peers, we're talking about a reduction from 7 gigs of memory down to 700 megs of memory. In order to get rid of these per-peer allocations, this commit switches to using a list-based queueing approach. Currently GSO fragments are chained together using the skb->next pointer (the skb_list_* singly linked list approach), so we form the per-peer queue around the unused skb->prev pointer (which sort of makes sense because the links are pointing backwards). Use of skb_queue_* is not possible here, because that is based on doubly linked lists and spinlocks. Multiple cores can write into the queue at any given time, because its writes occur in the start_xmit path or in the udp_recv path. But reads happen in a single workqueue item per-peer, amounting to a multi-producer, single-consumer paradigm. The MPSC queue is implemented locklessly and never blocks. However, it is not linearizable (though it is serializable), with a very tight and unlikely race on writes, which, when hit (some tiny fraction of the 0.15% of partial adds on a fully loaded 16-core x86_64 system), causes the queue reader to terminate early. However, because every packet sent queues up the same workqueue item after it is fully added, the worker resumes again, and stopping early isn't actually a problem, since at that point the packet wouldn't have yet been added to the encryption queue. These properties allow us to avoid disabling interrupts or spinning. The design is based on Dmitry Vyukov's algorithm [1]. Performance-wise, ordinarily list-based queues aren't preferable to ringbuffers, because of cache misses when following pointers around. However, we *already* have to follow the adjacent pointers when working through fragments, so there shouldn't actually be any change there. A potential downside is that dequeueing is a bit more complicated, but the ptr_ring structure used prior had a spinlock when dequeueing, so all and all the difference appears to be a wash. Actually, from profiling, the biggest performance hit, by far, of this commit winds up being atomic_add_unless(count, 1, max) and atomic_ dec(count), which account for the majority of CPU time, according to perf. In that sense, the previous ring buffer was superior in that it could check if it was full by head==tail, which the list-based approach cannot do. But all and all, this enables us to get massive memory savings, allowing WireGuard to scale for real world deployments, without taking much of a performance hit. [1] http://www.1024cores.net/home/lock-free-algorithms/queues/intrusive-mpsc-node-based-queue Reviewed-by: Dmitry Vyukov Reviewed-by: Toke Høiland-Jørgensen Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 71717fb2fca0afffc37d6c976ee65fc5f3b07914 Author: Jason A. Donenfeld Date: Mon Feb 22 17:25:45 2021 +0100 wireguard: selftests: test multiple parallel streams commit d5a49aa6c3e264a93a7d08485d66e346be0969dd upstream. In order to test ndo_start_xmit being called in parallel, explicitly add separate tests, which should all run on different cores. This should help tease out bugs associated with queueing up packets from different cores in parallel. Currently, it hasn't found those types of bugs, but given future planned work, this is a useful regression to avoid. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 939540ca629211d548ffc22e8ba64c6fbadaf5e7 Author: Jason A. Donenfeld Date: Tue Feb 23 14:18:58 2021 +0100 net: icmp: pass zeroed opts from icmp{,v6}_ndo_send before sending commit ee576c47db60432c37e54b1e2b43a8ca6d3a8dca upstream. The icmp{,v6}_send functions make all sorts of use of skb->cb, casting it with IPCB or IP6CB, assuming the skb to have come directly from the inet layer. But when the packet comes from the ndo layer, especially when forwarded, there's no telling what might be in skb->cb at that point. As a result, the icmp sending code risks reading bogus memory contents, which can result in nasty stack overflows such as this one reported by a user: panic+0x108/0x2ea __stack_chk_fail+0x14/0x20 __icmp_send+0x5bd/0x5c0 icmp_ndo_send+0x148/0x160 In icmp_send, skb->cb is cast with IPCB and an ip_options struct is read from it. The optlen parameter there is of particular note, as it can induce writes beyond bounds. There are quite a few ways that can happen in __ip_options_echo. For example: // sptr/skb are attacker-controlled skb bytes sptr = skb_network_header(skb); // dptr/dopt points to stack memory allocated by __icmp_send dptr = dopt->__data; // sopt is the corrupt skb->cb in question if (sopt->rr) { optlen = sptr[sopt->rr+1]; // corrupt skb->cb + skb->data soffset = sptr[sopt->rr+2]; // corrupt skb->cb + skb->data // this now writes potentially attacker-controlled data, over // flowing the stack: memcpy(dptr, sptr+sopt->rr, optlen); } In the icmpv6_send case, the story is similar, but not as dire, as only IP6CB(skb)->iif and IP6CB(skb)->dsthao are used. The dsthao case is worse than the iif case, but it is passed to ipv6_find_tlv, which does a bit of bounds checking on the value. This is easy to simulate by doing a `memset(skb->cb, 0x41, sizeof(skb->cb));` before calling icmp{,v6}_ndo_send, and it's only by good fortune and the rarity of icmp sending from that context that we've avoided reports like this until now. For example, in KASAN: BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0xa0e/0x12b0 Write of size 38 at addr ffff888006f1f80e by task ping/89 CPU: 2 PID: 89 Comm: ping Not tainted 5.10.0-rc7-debug+ #5 Call Trace: dump_stack+0x9a/0xcc print_address_description.constprop.0+0x1a/0x160 __kasan_report.cold+0x20/0x38 kasan_report+0x32/0x40 check_memory_region+0x145/0x1a0 memcpy+0x39/0x60 __ip_options_echo+0xa0e/0x12b0 __icmp_send+0x744/0x1700 Actually, out of the 4 drivers that do this, only gtp zeroed the cb for the v4 case, while the rest did not. So this commit actually removes the gtp-specific zeroing, while putting the code where it belongs in the shared infrastructure of icmp{,v6}_ndo_send. This commit fixes the issue by passing an empty IPCB or IP6CB along to the functions that actually do the work. For the icmp_send, this was already trivial, thanks to __icmp_send providing the plumbing function. For icmpv6_send, this required a tiny bit of refactoring to make it behave like the v4 case, after which it was straight forward. Fixes: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port MTUs") Reported-by: SinYu Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/netdev/CAF=yD-LOF116aHub6RMe8vB8ZpnrrnoTdqhobEx+bvoA8AsP0w@mail.gmail.com/T/ Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20210223131858.72082-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e3d9e8a7478fc2311f545e32f410301b7ccca4f1 Author: Leon Romanovsky Date: Wed Feb 3 15:51:09 2021 +0200 ipv6: silence compilation warning for non-IPV6 builds commit 1faba27f11c8da244e793546a1b35a9b1da8208e upstream. The W=1 compilation of allmodconfig generates the following warning: net/ipv6/icmp.c:448:6: warning: no previous prototype for 'icmp6_send' [-Wmissing-prototypes] 448 | void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info, | ^~~~~~~~~~ Fix it by providing function declaration for builds with ipv6 as a module. Signed-off-by: Leon Romanovsky Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c80eb9b228daf5e2172d5cec1b9a474d4a46be13 Author: Sumit Garg Date: Thu Feb 25 17:22:38 2021 -0800 kgdb: fix to kill breakpoints on initmem after boot commit d54ce6158e354f5358a547b96299ecd7f3725393 upstream. Currently breakpoints in kernel .init.text section are not handled correctly while allowing to remove them even after corresponding pages have been freed. Fix it via killing .init.text section breakpoints just prior to initmem pages being freed. Doug: "HW breakpoints aren't handled by this patch but it's probably not such a big deal". Link: https://lkml.kernel.org/r/20210224081652.587785-1-sumit.garg@linaro.org Signed-off-by: Sumit Garg Suggested-by: Doug Anderson Acked-by: Doug Anderson Acked-by: Daniel Thompson Tested-by: Daniel Thompson Cc: Masami Hiramatsu Cc: Steven Rostedt (VMware) Cc: Jason Wessel Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6af898a31934a4dbeb4a5017d14807dcae8899ed Author: Ville Syrjälä Date: Wed Feb 3 11:30:44 2021 +0200 drm/i915: Reject 446-480MHz HDMI clock on GLK commit 7a6c6243b44a439bda4bf099032be35ebcf53406 upstream. The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola (cherry picked from commit 41751b3e5c1ac656a86f8d45a8891115281b729e) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit d8c727db8d815b10bfd7ebdd0655ff51f2e2435a Author: Nikos Tsironis Date: Thu Feb 11 16:22:43 2021 +0200 dm era: only resize metadata in preresume commit cca2c6aebe86f68103a8615074b3578e854b5016 upstream. Metadata resize shouldn't happen in the ctr. The ctr loads a temporary (inactive) table that will only become active upon resume. That is why resize should always be done in terms of resume. Otherwise a load (ctr) whose inactive table never becomes active will incorrectly resize the metadata. Also, perform the resize directly in preresume, instead of using the worker to do it. The worker might run other metadata operations, e.g., it could start digestion, before resizing the metadata. These operations will end up using the old size. This could lead to errors, like: device-mapper: era: metadata_digest_transcribe_writeset: dm_array_set_value failed device-mapper: era: process_old_eras: digest step failed, stopping digestion The reason of the above error is that the worker started the digestion of the archived writeset using the old, larger size. As a result, metadata_digest_transcribe_writeset tried to write beyond the end of the era array. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 755cae33e2fff782c8a950446112016170fc6be0 Author: Nikos Tsironis Date: Fri Jan 22 17:22:04 2021 +0200 dm era: Reinitialize bitset cache before digesting a new writeset commit 2524933307fd0036d5c32357c693c021ab09a0b0 upstream. In case of devices with at most 64 blocks, the digestion of consecutive eras uses the writeset of the first era as the writeset of all eras to digest, leading to lost writes. That is, we lose the information about what blocks were written during the affected eras. The digestion code uses a dm_disk_bitset object to access the archived writesets. This structure includes a one word (64-bit) cache to reduce the number of array lookups. This structure is initialized only once, in metadata_digest_start(), when we kick off digestion. But, when we insert a new writeset into the writeset tree, before the digestion of the previous writeset is done, or equivalently when there are multiple writesets in the writeset tree to digest, then all these writesets are digested using the same cache and the cache is not re-initialized when moving from one writeset to the next. For devices with more than 64 blocks, i.e., the size of the cache, the cache is indirectly invalidated when we move to a next set of blocks, so we avoid the bug. But for devices with at most 64 blocks we end up using the same cached data for digesting all archived writesets, i.e., the cache is loaded when digesting the first writeset and it never gets reloaded, until the digestion is done. As a result, the writeset of the first era to digest is used as the writeset of all the following archived eras, leading to lost writes. Fix this by reinitializing the dm_disk_bitset structure, and thus invalidating the cache, every time the digestion code starts digesting a new writeset. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit e355781d77ace56020fb9085f30d59bb06a83d13 Author: Nikos Tsironis Date: Fri Jan 22 17:25:55 2021 +0200 dm era: Use correct value size in equality function of writeset tree commit 64f2d15afe7b336aafebdcd14cc835ecf856df4b upstream. Fix the writeset tree equality test function to use the right value size when comparing two btree values. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Reviewed-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 89f7565bef6b5ac4235772ab7c06702a1fc549cb Author: Nikos Tsironis Date: Fri Jan 22 17:25:54 2021 +0200 dm era: Fix bitset memory leaks commit 904e6b266619c2da5c58b5dce14ae30629e39645 upstream. Deallocate the memory allocated for the in-core bitsets when destroying the target and in error paths. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Reviewed-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f1a4a3cdeb444d56649e54746890dac5745a2209 Author: Nikos Tsironis Date: Fri Jan 22 17:25:53 2021 +0200 dm era: Verify the data block size hasn't changed commit c8e846ff93d5eaa5384f6f325a1687ac5921aade upstream. dm-era doesn't support changing the data block size of existing devices, so check explicitly that the requested block size for a new target matches the one stored in the metadata. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Reviewed-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit da27b481f08a7955f22c2283e1a0da642aaa620c Author: Nikos Tsironis Date: Fri Jan 22 17:19:31 2021 +0200 dm era: Update in-core bitset after committing the metadata commit 2099b145d77c1d53f5711f029c37cc537897cee6 upstream. In case of a system crash, dm-era might fail to mark blocks as written in its metadata, although the corresponding writes to these blocks were passed down to the origin device and completed successfully. Consider the following sequence of events: 1. We write to a block that has not been yet written in the current era 2. era_map() checks the in-core bitmap for the current era and sees that the block is not marked as written. 3. The write is deferred for submission after the metadata have been updated and committed. 4. The worker thread processes the deferred write (process_deferred_bios()) and marks the block as written in the in-core bitmap, **before** committing the metadata. 5. The worker thread starts committing the metadata. 6. We do more writes that map to the same block as the write of step (1) 7. era_map() checks the in-core bitmap and sees that the block is marked as written, **although the metadata have not been committed yet**. 8. These writes are passed down to the origin device immediately and the device reports them as completed. 9. The system crashes, e.g., power failure, before the commit from step (5) finishes. When the system recovers and we query the dm-era target for the list of written blocks it doesn't report the aforementioned block as written, although the writes of step (6) completed successfully. The issue is that era_map() decides whether to defer or not a write based on non committed information. The root cause of the bug is that we update the in-core bitmap, **before** committing the metadata. Fix this by updating the in-core bitmap **after** successfully committing the metadata. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a586531ff59f4498898e29a126df0bcd035e0024 Author: Nikos Tsironis Date: Fri Jan 22 17:19:30 2021 +0200 dm era: Recover committed writeset after crash commit de89afc1e40fdfa5f8b666e5d07c43d21a1d3be0 upstream. Following a system crash, dm-era fails to recover the committed writeset for the current era, leading to lost writes. That is, we lose the information about what blocks were written during the affected era. dm-era assumes that the writeset of the current era is archived when the device is suspended. So, when resuming the device, it just moves on to the next era, ignoring the committed writeset. This assumption holds when the device is properly shut down. But, when the system crashes, the code that suspends the target never runs, so the writeset for the current era is not archived. There are three issues that cause the committed writeset to get lost: 1. dm-era doesn't load the committed writeset when opening the metadata 2. The code that resizes the metadata wipes the information about the committed writeset (assuming it was loaded at step 1) 3. era_preresume() starts a new era, without taking into account that the current era might not have been archived, due to a system crash. To fix this: 1. Load the committed writeset when opening the metadata 2. Fix the code that resizes the metadata to make sure it doesn't wipe the loaded writeset 3. Fix era_preresume() to check for a loaded writeset and archive it, before starting a new era. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ce4d46a4cc14eb710624be2f8138ed4a82d68d1e Author: Mikulas Patocka Date: Tue Feb 9 10:56:20 2021 -0500 dm writecache: fix writing beyond end of underlying device when shrinking commit 4134455f2aafdfeab50cabb4cccb35e916034b93 upstream. Do not attempt to write any data beyond the end of the underlying data device while shrinking it. The DM writecache device must be suspended when the underlying data device is shrunk. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f66e8b855696571f2210e9131635cece2db84bee Author: Mikulas Patocka Date: Thu Feb 4 05:20:52 2021 -0500 dm writecache: return the exact table values that were set commit 054bee16163df023e2589db09fd27d81f7ad9e72 upstream. LVM doesn't like it when the target returns different values from what was set in the constructor. Fix dm-writecache so that the returned table values are exactly the same as requested values. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 2ee52af239996bc1e07ec4aecb74f9999e6be381 Author: Mikulas Patocka Date: Sat Jan 23 09:19:56 2021 -0500 dm writecache: fix performance degradation in ssd mode commit cb728484a7710c202f02b96aa0962ce9b07aa5c2 upstream. Fix a thinko in ssd_commit_superblock. region.count is in sectors, not bytes. This bug doesn't corrupt data, but it causes performance degradation. Signed-off-by: Mikulas Patocka Fixes: dc8a01ae1dbd ("dm writecache: optimize superblock write") Cc: stable@vger.kernel.org # v5.7+ Reported-by: J. Bruce Fields Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4353580918d99d4899795259b5facdcaadb19a1d Author: Jeffle Xu Date: Mon Feb 8 22:46:38 2021 -0500 dm table: fix zoned iterate_devices based device capability checks commit 24f6b6036c9eec21191646930ad42808e6180510 upstream. Fix dm_table_supports_zoned_model() and invert logic of both iterate_devices_callout_fn so that all devices' zoned capabilities are properly checked. Add one more parameter to dm_table_any_dev_attr(), which is actually used as the @data parameter of iterate_devices_callout_fn, so that dm_table_matches_zone_sectors() can be replaced by dm_table_any_dev_attr(). Fixes: dd88d313bef02 ("dm table: add zoned block devices validation") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 9f40d19d95d3a8d7d7552832ea62ea24c9b64ac2 Author: Jeffle Xu Date: Mon Feb 8 22:34:36 2021 -0500 dm table: fix DAX iterate_devices based device capability checks commit 5b0fab508992c2e120971da658ce80027acbc405 upstream. Fix dm_table_supports_dax() and invert logic of both iterate_devices_callout_fn so that all devices' DAX capabilities are properly checked. Fixes: 545ed20e6df6 ("dm: add infrastructure for DAX support") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 1f84b7f89ee0f72edab3c8a5e3b63af1514512a3 Author: Jeffle Xu Date: Tue Feb 2 11:35:28 2021 +0800 dm table: fix iterate_devices based device capability checks commit a4c8dd9c2d0987cf542a2a0c42684c9c6d78a04e upstream. According to the definition of dm_iterate_devices_fn: * This function must iterate through each section of device used by the * target until it encounters a non-zero return code, which it then returns. * Returns zero if no callout returned non-zero. For some target type (e.g. dm-stripe), one call of iterate_devices() may iterate multiple underlying devices internally, in which case a non-zero return code returned by iterate_devices_callout_fn will stop the iteration in advance. No iterate_devices_callout_fn should return non-zero unless device iteration should stop. Rename dm_table_requires_stable_pages() to dm_table_any_dev_attr() and elevate it for reuse to stop iterating (and return non-zero) on the first device that causes iterate_devices_callout_fn to return non-zero. Use dm_table_any_dev_attr() to properly iterate through devices. Rename device_is_nonrot() to device_is_rotational() and invert logic accordingly to fix improper disposition. Fixes: c3c4555edd10 ("dm table: clear add_random unless all devices have it set") Fixes: 4693c9668fdc ("dm table: propagate non rotational flag") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 535909761e2a46bbf7cf5066f17797ac55eb9770 Author: Mikulas Patocka Date: Wed Feb 10 15:26:23 2021 -0500 dm: fix deadlock when swapping to encrypted device commit a666e5c05e7c4aaabb2c5d58117b0946803d03d2 upstream. The system would deadlock when swapping to a dm-crypt device. The reason is that for each incoming write bio, dm-crypt allocates memory that holds encrypted data. These excessive allocations exhaust all the memory and the result is either deadlock or OOM trigger. This patch limits the number of in-flight swap bios, so that the memory consumed by dm-crypt is limited. The limit is enforced if the target set the "limit_swap_bios" variable and if the bio has REQ_SWAP set. Non-swap bios are not affected becuase taking the semaphore would cause performance degradation. This is similar to request-based drivers - they will also block when the number of requests is over the limit. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f798dbfaa59bd1fa3d5fdde22e90193ccd211b32 Author: Andreas Gruenbacher Date: Tue Feb 9 18:32:32 2021 +0100 gfs2: Recursive gfs2_quota_hold in gfs2_iomap_end commit 7009fa9cd9a5262944b30eb7efb1f0561d074b68 upstream. When starting an iomap write, gfs2_quota_lock_check -> gfs2_quota_lock -> gfs2_quota_hold is called from gfs2_iomap_begin. At the end of the write, before unlocking the quotas, punch_hole -> gfs2_quota_hold can be called again in gfs2_iomap_end, which is incorrect and leads to a failed assertion. Instead, move the call to gfs2_quota_unlock before the call to punch_hole to fix that. Fixes: 64bc06bb32ee ("gfs2: iomap buffered write support") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit ce2a8c838ce693f236c2c12e81bd610820562f0e Author: Andreas Gruenbacher Date: Fri Feb 5 18:11:28 2021 +0100 gfs2: Lock imbalance on error path in gfs2_recover_one commit 834ec3e1ee65029029225a86c12337a6cd385af7 upstream. In gfs2_recover_one, fix a sd_log_flush_lock imbalance when a recovery pass fails. Fixes: c9ebc4b73799 ("gfs2: allow journal replay to hold sd_log_flush_lock") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit cd9ba057a84c5e8b0437a44c6a2c7ac04161b9ff Author: Bob Peterson Date: Fri Feb 5 13:50:41 2021 -0500 gfs2: Don't skip dlm unlock if glock has an lvb commit 78178ca844f0eb88f21f31c7fde969384be4c901 upstream. Patch fb6791d100d1 was designed to allow gfs2 to unmount quicker by skipping the step where it tells dlm to unlock glocks in EX with lvbs. This was done because when gfs2 unmounts a file system, it destroys the dlm lockspace shortly after it destroys the glocks so it doesn't need to unlock them all: the unlock is implied when the lockspace is destroyed by dlm. However, that patch introduced a use-after-free in dlm: as part of its normal dlm_recoverd process, it can call ls_recovery to recover dead locks. In so doing, it can call recover_rsbs which calls recover_lvb for any mastered rsbs. Func recover_lvb runs through the list of lkbs queued to the given rsb (if the glock is cached but unlocked, it will still be queued to the lkb, but in NL--Unlocked--mode) and if it has an lvb, copies it to the rsb, thus trying to preserve the lkb. However, when gfs2 skips the dlm unlock step, it frees the glock and its lvb, which means dlm's function recover_lvb references the now freed lvb pointer, copying the freed lvb memory to the rsb. This patch changes the check in gdlm_put_lock so that it calls dlm_unlock for all glocks that contain an lvb pointer. Fixes: fb6791d100d1 ("GFS2: skip dlm_unlock calls in unmount") Cc: stable@vger.kernel.org # v3.8+ Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit b2b81c5f83ababd09b852af592f998d2139eec84 Author: Bob Peterson Date: Mon Jan 18 15:18:59 2021 -0500 gfs2: fix glock confusion in function signal_our_withdraw commit f5f02fde9f52b2d769c1c2ddfd3d9c4a1fe739a7 upstream. If go_free is defined, function signal_our_withdraw is supposed to synchronize on the GLF_FREEING flag of the inode glock, but it accidentally does that on the live glock. Fix that and disambiguate the glock variables. Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish") Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Bob Peterson Signed-off-by: Greg Kroah-Hartman commit 5df2257601c1aaf85b0802448304520a45a06d69 Author: Masahisa Kojima Date: Mon Feb 1 01:31:09 2021 -0600 spi: spi-synquacer: fix set_cs handling commit 1c9f1750f0305bf605ff22686fc0ac89c06deb28 upstream. When the slave chip select is deasserted, DMSTOP bit must be set. Fixes: b0823ee35cf9 ("spi: Add spi driver for Socionext SynQuacer platform") Signed-off-by: Masahisa Kojima Signed-off-by: Jassi Brar Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210201073109.9036-1-jassisinghbrar@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 351adebe01b21af066ae398787c42940ed77940d Author: Rasmus Villemoes Date: Sat Jan 30 15:35:45 2021 +0100 spi: fsl: invert spisel_boot signal on MPC8309 commit 9d2aa6dbf87af89c13cac2d1b4cccad83fb14a7e upstream. Commit 7a2da5d7960a ("spi: fsl: Fix driver breakage when SPI_CS_HIGH is not set in spi->mode") broke our MPC8309 board by effectively inverting the boolean value passed to fsl_spi_cs_control. The SPISEL_BOOT signal is used as chipselect, but it's not a gpio, so we cannot rely on gpiolib handling the polarity. Adapt to the new world order by inverting the logic here. This does assume that the slave sitting at the SPISEL_BOOT is active low, but should that ever turn out not to be the case, one can create a stub gpiochip driver controlling a single gpio (or rather, a single "spo", special-purpose output). Fixes: 7a2da5d7960a ("spi: fsl: Fix driver breakage when SPI_CS_HIGH is not set in spi->mode") Cc: stable@vger.kernel.org Signed-off-by: Rasmus Villemoes Link: https://lore.kernel.org/r/20210130143545.505613-1-rasmus.villemoes@prevas.dk Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e34c5063a7104a7ad0c32be45d7c851025f89678 Author: Paul Cercueil Date: Mon Feb 8 18:11:57 2021 +0000 perf stat: Use nftw() instead of ftw() commit a81fbb8771a3810a58d657763fde610bf2c33286 upstream. ftw() has been obsolete for about 12 years now. Committer notes: Further notes provided by the patch author: "NOTE: Not runtime-tested, I have no idea what I need to do in perf to test this. But at least it compiles now with my uClibc-based toolchain." I looked at the nftw()/ftw() man page and for the use made with cgroups in 'perf stat' the end result is equivalent. Fixes: bb1c15b60b98 ("perf stat: Support regex pattern in --for-each-cgroup") Signed-off-by: Paul Cercueil Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: od@zcrc.me Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20210208181157.1324550-1-paul@crapouillou.net Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 3575886d32a89c8791627c39b37d1ecf5e1e9d01 Author: Al Viro Date: Mon Jul 20 02:21:51 2020 +0100 sparc32: fix a user-triggerable oops in clear_user() commit 7780918b36489f0b2f9a3749d7be00c2ceaec513 upstream. Back in 2.1.29 the clear_user() guts (__bzero()) had been merged with memset(). Unfortunately, while all exception handlers had been copied, one of the exception table entries got lost. As the result, clear_user() starting at 128*n bytes before the end of page and spanning between 8 and 127 bytes into the next page would oops when the second page is unmapped. It's trivial to reproduce - all it takes is main() { int fd = open("/dev/zero", O_RDONLY); char *p = mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0); munmap(p + 8192, 8192); read(fd, p + 8192 - 128, 192); } which had been oopsing since March 1997. Says something about the quality of test coverage... ;-/ And while today sparc32 port is nearly dead, back in '97 it had been very much alive; in fact, sparc64 had only been in mainline for 3 months by that point... Cc: stable@kernel.org Fixes: v2.1.29 Signed-off-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 859ca138ea38e74e98659426c08edc57a9ef9c83 Author: Ronnie Sahlberg Date: Thu Feb 25 17:36:27 2021 +1000 cifs: fix handling of escaped ',' in the password mount argument commit d08395a3f2f473c6ceeb316a1aeb7fad5b43014f upstream. Passwords can contain ',' which are also used as the separator between mount options. Mount.cifs will escape all ',' characters as the string ",,". Update parsing of the mount options to detect ",," and treat it as a single 'c' character. Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api") Cc: stable@vger.kernel.org # 5.11 Reported-by: Simon Taylor Tested-by: Simon Taylor Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6770207dc50991e34439c021531b72d06a7a2ce9 Author: Paulo Alcantara Date: Wed Feb 24 20:59:24 2021 -0300 cifs: fix nodfs mount option commit d01132ae50207bb6fd94e08e80c2d7b839408086 upstream. Skip DFS resolving when mounting with 'nodfs' even if CONFIG_CIFS_DFS_UPCALL is enabled. Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org # 5.11 Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5fb72729ea1feb215ed30b33f08b59582dcd72e0 Author: Paulo Alcantara Date: Wed Feb 24 20:59:23 2021 -0300 cifs: introduce helper for finding referral server to improve DFS target resolution commit 5ff2836ed3a5c24420a7235be25a462594cdc4ea upstream. Some servers seem to mistakenly report different values for capabilities and share flags, so we can't always rely on those values to decide whether the resolved target can handle any new DFS referrals. Add a new helper is_referral_server() to check if all resolved targets can handle new DFS referrals by directly looking at the GET_DFS_REFERRAL.ReferralHeaderFlags value as specified in MS-DFSC 2.2.4 RESP_GET_DFS_REFERRAL in addition to is_tcon_dfs(). Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org # 5.11 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 05c3fe13d121386b5dc2966943e102d30810e3ac Author: Paulo Alcantara Date: Wed Feb 24 20:59:22 2021 -0300 cifs: check all path components in resolved dfs target commit ff2c54a04097dee0b8899c485360719844d923f8 upstream. Handle the case where a resolved target share is like //server/users/dir, and the user "foo" has no read permission to access the parent folder "users" but has access to the final path component "dir". is_path_remote() already implements that, so call it directly. Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org # 5.11 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 423f064a786d1ebe5a8657fdf272e04005a68e2b Author: Paulo Alcantara Date: Wed Feb 24 20:59:21 2021 -0300 cifs: fix DFS failover commit 8513222b9ef2709ba40cbda07b55d5fbcfdd4bc7 upstream. In do_dfs_failover(), the mount_get_conns() function requires the full fs context in order to get new connection to server, so clone the original context and change it accordingly when retrying the DFS targets in the referral. If failover was successful, then update original context with the new UNC, prefix path and ip address. Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org # 5.11 Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d737c8594720ad3dde7ba3fa3e9366c882fef788 Author: Jaegeuk Kim Date: Tue Jan 26 17:00:42 2021 -0800 f2fs: flush data when enabling checkpoint back commit b0ff4fe746fd028eef920ddc8c7b0361c1ede6ec upstream. During checkpoint=disable period, f2fs bypasses all the synchronous IOs such as sync and fsync. So, when enabling it back, we must flush all of them in order to keep the data persistent. Otherwise, suddern power-cut right after enabling checkpoint will cause data loss. Fixes: 4354994f097d ("f2fs: checkpoint disabling") Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ac518012943e0b3aef50e37c9875f2854c587174 Author: Chao Yu Date: Sat Dec 26 18:07:01 2020 +0800 f2fs: enforce the immutable flag on open files commit e0fcd01510ad025c9bbce704c5c2579294056141 upstream. This patch ports commit 02b016ca7f99 ("ext4: enforce the immutable flag on open files") to f2fs. According to the chattr man page, "a file with the 'i' attribute cannot be modified..." Historically, this was only enforced when the file was opened, per the rest of the description, "... and the file can not be opened in write mode". There is general agreement that we should standardize all file systems to prevent modifications even for files that were opened at the time the immutable flag is set. Eventually, a change to enforce this at the VFS layer should be landing in mainline. Cc: stable@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 2a9a3fbb8d1b889ad5d64898069ffab4c9f09f65 Author: Chao Yu Date: Wed Dec 16 17:15:23 2020 +0800 f2fs: fix out-of-repair __setattr_copy() commit 2562515f0ad7342bde6456602c491b64c63fe950 upstream. __setattr_copy() was copied from setattr_copy() in fs/attr.c, there is two missing patches doesn't cover this inner function, fix it. Commit 7fa294c8991c ("userns: Allow chown and setgid preservation") Commit 23adbe12ef7d ("fs,userns: Change inode_capable to capable_wrt_inode_uidgid") Fixes: fbfa2cc58d53 ("f2fs: add file operations") Cc: stable@vger.kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ea2263e8687d830b0d1b1876738f02c097b8cb69 Author: Huacai Chen Date: Tue Feb 9 15:10:51 2021 +0800 irqchip/loongson-pch-msi: Use bitmap_zalloc() to allocate bitmap commit c1f664d2400e73d5ca0fcd067fa5847d2c789c11 upstream. Currently we use bitmap_alloc() to allocate msi bitmap which should be initialized with zero. This is obviously wrong but it works because msi can fallback to legacy interrupt mode. So use bitmap_zalloc() instead. Fixes: 632dcc2c75ef6de3272aa ("irqchip: Add Loongson PCH MSI controller") Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210209071051.2078435-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman commit e7c48947aefa0d2d36aa346c69aecba86a969fd8 Author: Johannes Berg Date: Wed Jan 13 22:08:03 2021 +0100 um: defer killing userspace on page table update failures commit a7d48886cacf8b426e0079bca9639d2657cf2d38 upstream. In some cases we can get to fix_range_common() with mmap_sem held, and in others we get there without it being held. For example, we get there with it held from sys_mprotect(), and without it held from fork_handler(). Avoid any issues in this and simply defer killing the task until it runs the next time. Do it on the mm so that another task that shares the same mm can't continue running afterwards. Cc: stable@vger.kernel.org Fixes: 468f65976a8d ("um: Fix hung task in fix_range_common()") Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 010b9853b75f6a30e825c4622396afe5fdd5c831 Author: Johannes Berg Date: Wed Jan 13 22:08:02 2021 +0100 um: mm: check more comprehensively for stub changes commit 47da29763ec9a153b9b685bff9db659e4e09e494 upstream. If userspace tries to change the stub, we need to kill it, because otherwise it can escape the virtual machine. In a few cases the stub checks weren't good, e.g. if userspace just tries to mmap(0x100000 - 0x1000, 0x3000, ...) it could succeed to get a new private/anonymous mapping replacing the stubs. Fix this by checking everywhere, and checking for _overlap_, not just direct changes. Cc: stable@vger.kernel.org Fixes: 3963333fe676 ("uml: cover stubs with a VMA") Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 51d733f0525aa58b3ad6efcc696a9443d519a268 Author: Cornelia Huck Date: Tue Feb 16 12:06:45 2021 +0100 virtio/s390: implement virtio-ccw revision 2 correctly commit 182f709c5cff683e6732d04c78e328de0532284f upstream. CCW_CMD_READ_STATUS was introduced with revision 2 of virtio-ccw, and drivers should only rely on it being implemented when they negotiated at least that revision with the device. However, virtio_ccw_get_status() issued READ_STATUS for any device operating at least at revision 1. If the device accepts READ_STATUS regardless of the negotiated revision (which some implementations like QEMU do, even though the spec currently does not allow it), everything works as intended. While a device rejecting the command should also be handled gracefully, we will not be able to see any changes the device makes to the status, such as setting NEEDS_RESET or setting the status to zero after a completed reset. We negotiated the revision to at most 1, as we never bumped the maximum revision; let's do that now and properly send READ_STATUS only if we are operating at least at revision 2. Cc: stable@vger.kernel.org Fixes: 7d3ce5ab9430 ("virtio/s390: support READ_STATUS command for virtio-ccw") Reviewed-by: Halil Pasic Signed-off-by: Cornelia Huck Signed-off-by: Vasily Gorbik Link: https://lore.kernel.org/r/20210216110645.1087321-1-cohuck@redhat.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit bf643e3dcda0a71ff4ed834f04530c291e14d7fc Author: Heiko Carstens Date: Tue Feb 2 16:45:37 2021 +0100 s390/vtime: fix inline assembly clobber list commit b29c5093820d333eef22f58cd04ec0d089059c39 upstream. The stck/stckf instruction used within the inline assembly within do_account_vtime() changes the condition code. This is not reflected with the clobber list, and therefore might result in incorrect code generation. It seems unlikely that the compiler could generate incorrect code considering the surrounding C code, but it must still be fixed. Cc: Reviewed-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit d918c87e744cd63bacea2f6b080d47886148edd9 Author: Jens Axboe Date: Sun Feb 14 13:21:43 2021 -0700 proc: don't allow async path resolution of /proc/thread-self components commit 0d4370cfe36b7f1719123b621a4ec4d9c7a25f89 upstream. If this is attempted by an io-wq kthread, then return -EOPNOTSUPP as we don't currently support that. Once we can get task_pid_ptr() doing the right thing, then this can go away again. Use PF_IO_WORKER for this to speciically target the io_uring workers. Modify the /proc/self/ check to use PF_IO_WORKER as well. Cc: stable@vger.kernel.org Fixes: 8d4c3e76e3be ("proc: don't allow async path resolution of /proc/self components") Reported-by: Eric W. Biederman Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9dcb3e36fb23c0ef607b7249feb500b88330fc40 Author: Chen Yu Date: Tue Jan 12 13:21:27 2021 +0800 cpufreq: intel_pstate: Get per-CPU max freq via MSR_HWP_CAPABILITIES if available commit 6f67e060083a84a4cc364eab6ae40c717165fb0c upstream. Currently, when turbo is disabled (either by BIOS or by the user), the intel_pstate driver reads the max non-turbo frequency from the package-wide MSR_PLATFORM_INFO(0xce) register. However, on asymmetric platforms it is possible in theory that small and big core with HWP enabled might have different max non-turbo CPU frequency, because MSR_HWP_CAPABILITIES is per-CPU scope according to Intel Software Developer Manual. The turbo max freq is already per-CPU in current code, so make similar change to the max non-turbo frequency as well. Reported-by: Wendy Wang Signed-off-by: Chen Yu [ rjw: Subject and changelog edits ] Cc: 4.18+ # 4.18+: a45ee4d4e13b: cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 91eb52a822c9aaa46aa2ad2ea13f3d0e6861cfe0 Author: Rafael J. Wysocki Date: Thu Jan 7 19:43:30 2021 +0100 cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument commit a45ee4d4e13b0e35a8ec7ea0bf9267243d57b302 upstream. All of the callers of intel_pstate_get_hwp_max() access the struct cpudata object that corresponds to the given CPU already and the function itself needs to access that object (in order to update hwp_cap_cached), so modify the code to pass a struct cpudata pointer to it instead of the CPU number. Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu Signed-off-by: Greg Kroah-Hartman commit 5293abbc9fa332482f652f64ba5090f5b4256a94 Author: Shawn Guo Date: Tue Jan 19 10:39:25 2021 +0800 cpufreq: qcom-hw: drop devm_xxx() calls from init/exit hooks commit 67fc209b527d023db4d087c68e44e9790aa089ef upstream. Commit f17b3e44320b ("cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify code") introduces a regression on platforms using the driver, by failing to initialise a policy, when one is created post hotplug. When all the CPUs of a policy are hoptplugged out, the call to .exit() and later to devm_iounmap() does not release the memory region that was requested during devm_platform_ioremap_resource(). Therefore, a subsequent call to .init() will result in the following error, which will prevent a new policy to be initialised: [ 3395.915416] CPU4: shutdown [ 3395.938185] psci: CPU4 killed (polled 0 ms) [ 3399.071424] CPU5: shutdown [ 3399.094316] psci: CPU5 killed (polled 0 ms) [ 3402.139358] CPU6: shutdown [ 3402.161705] psci: CPU6 killed (polled 0 ms) [ 3404.742939] CPU7: shutdown [ 3404.765592] psci: CPU7 killed (polled 0 ms) [ 3411.492274] Detected VIPT I-cache on CPU4 [ 3411.492337] GICv3: CPU4: found redistributor 400 region 0:0x0000000017ae0000 [ 3411.492448] CPU4: Booted secondary processor 0x0000000400 [0x516f802d] [ 3411.503654] qcom-cpufreq-hw 17d43000.cpufreq: can't request region for resource [mem 0x17d45800-0x17d46bff] With that being said, the original code was tricky and skipping memory region request intentionally to hide this issue. The true cause is that those devm_xxx() device managed functions shouldn't be used for cpufreq init/exit hooks, because &pdev->dev is alive across the hooks and will not trigger auto resource free-up. Let's drop the use of device managed functions and manually allocate/free resources, so that the issue can be fixed properly. Cc: v5.10+ # v5.10+ Fixes: f17b3e44320b ("cpufreq: qcom-hw: Use devm_platform_ioremap_resource() to simplify code") Suggested-by: Bjorn Andersson Signed-off-by: Shawn Guo Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 5bf24e069ed2861a4ce3cd7a237f1892155cd5cd Author: Viresh Kumar Date: Wed Feb 17 11:18:58 2021 +0530 thermal: cpufreq_cooling: freq_qos_update_request() returns < 0 on error commit a51afb13311cd85b2f638c691b2734622277d8f5 upstream. freq_qos_update_request() returns 1 if the effective constraint value has changed, 0 if the effective constraint value has not changed, or a negative error code on failures. The frequency constraints for CPUs can be set by different parts of the kernel. If the maximum frequency constraint set by other parts of the kernel are set at a lower value than the one corresponding to cooling state 0, then we will never be able to cool down the system as freq_qos_update_request() will keep on returning 0 and we will skip updating cpufreq_state and thermal pressure. Fix that by doing the updates even in the case where freq_qos_update_request() returns 0, as we have effectively set the constraint to a new value even if the consolidated value of the actual constraint is unchanged because of external factors. Cc: v5.7+ # v5.7+ Reported-by: Thara Gopinath Fixes: f12e4f66ab6a ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Viresh Kumar Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Reviewed-by: Rafael J. Wysocki Tested-by: Thara Gopinath Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/b2b7e84944937390256669df5a48ce5abba0c1ef.1613540713.git.viresh.kumar@linaro.org Signed-off-by: Greg Kroah-Hartman commit ff9831a02d7335d6a97e52a44163a1d76f40118d Author: Chris Wilson Date: Fri Feb 5 22:00:12 2021 +0000 kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE commit bfe3911a91047557eb0e620f95a370aee6a248c7 upstream. Userspace has discovered the functionality offered by SYS_kcmp and has started to depend upon it. In particular, Mesa uses SYS_kcmp for os_same_file_description() in order to identify when two fd (e.g. device or dmabuf) point to the same struct file. Since they depend on it for core functionality, lift SYS_kcmp out of the non-default CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. Rasmus Villemoes also pointed out that systemd uses SYS_kcmp to deduplicate the per-service file descriptor store. Note that some distributions such as Ubuntu are already enabling CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp. References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046 Signed-off-by: Chris Wilson Cc: Kees Cook Cc: Andy Lutomirski Cc: Will Drewry Cc: Andrew Morton Cc: Dave Airlie Cc: Daniel Vetter Cc: Lucas Stach Cc: Rasmus Villemoes Cc: Cyrill Gorcunov Cc: stable@vger.kernel.org Acked-by: Daniel Vetter # DRM depends on kcmp Acked-by: Rasmus Villemoes # systemd uses kcmp Reviewed-by: Cyrill Gorcunov Reviewed-by: Kees Cook Acked-by: Thomas Zimmermann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210205220012.1983-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit f9d49b366ef6292c06182fc9b230033b86ed2e6a Author: Shin'ichiro Kawasaki Date: Wed Feb 17 18:58:11 2021 +0900 zonefs: Fix file size of zones in full condition commit 059c01039c0185dbee7ed080f1f2bd22cb1e4dab upstream. Per ZBC/ZAC/ZNS specifications, write pointers may not have valid values when zones are in full condition. However, when zonefs mounts a zoned block device, zonefs refers write pointers to set file size even when the zones are in full condition. This results in wrong file size. To fix this, refer maximum file size in place of write pointers for zones in full condition. Signed-off-by: Shin'ichiro Kawasaki Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system") Cc: # 5.6+ Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit d696415dc1498b53ee9f9907ef71124d012a53cd Author: Namjae Jeon Date: Mon Feb 1 09:23:37 2021 +0900 exfat: fix shift-out-of-bounds in exfat_fill_super() commit 78c276f5495aa53a8beebb627e5bf6a54f0af34f upstream. syzbot reported a warning which could cause shift-out-of-bounds issue. Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x183/0x22e lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395 exfat_read_boot_sector fs/exfat/super.c:471 [inline] __exfat_fill_super fs/exfat/super.c:556 [inline] exfat_fill_super+0x2acb/0x2d00 fs/exfat/super.c:624 get_tree_bdev+0x406/0x630 fs/super.c:1291 vfs_get_tree+0x86/0x270 fs/super.c:1496 do_new_mount fs/namespace.c:2881 [inline] path_mount+0x1937/0x2c50 fs/namespace.c:3211 do_mount fs/namespace.c:3224 [inline] __do_sys_mount fs/namespace.c:3432 [inline] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3409 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 exfat specification describe sect_per_clus_bits field of boot sector could be at most 25 - sect_size_bits and at least 0. And sect_size_bits can also affect this calculation, It also needs validation. This patch add validation for sect_per_clus_bits and sect_size_bits field of boot sector. Fixes: 719c1e182916 ("exfat: add super block operations") Cc: stable@vger.kernel.org # v5.9+ Reported-by: syzbot+da4fe66aaadd3c2e2d1c@syzkaller.appspotmail.com Reviewed-by: Sungjong Seo Tested-by: Randy Dunlap Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 6690cbf2f23a3fbabbceb1b4b8d993da0bdb0835 Author: Muchun Song Date: Wed Feb 10 11:48:23 2021 +0800 printk: fix deadlock when kernel panic commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream. printk_safe_flush_on_panic() caused the following deadlock on our server: CPU0: CPU1: panic rcu_dump_cpu_stacks kdump_nmi_shootdown_cpus nmi_trigger_cpumask_backtrace register_nmi_handler(crash_nmi_callback) printk_safe_flush __printk_safe_flush raw_spin_lock_irqsave(&read_lock) // send NMI to other processors apic_send_IPI_allbutself(NMI_VECTOR) // NMI interrupt, dead loop crash_nmi_callback printk_safe_flush_on_panic printk_safe_flush __printk_safe_flush // deadlock raw_spin_lock_irqsave(&read_lock) DEADLOCK: read_lock is taken on CPU1 and will never get released. It happens when panic() stops a CPU by NMI while it has been in the middle of printk_safe_flush(). Handle the lock the same way as logbuf_lock. The printk_safe buffers are flushed only when both locks can be safely taken. It can avoid the deadlock _in this particular case_ at expense of losing contents of printk_safe buffers. Note: It would actually be safe to re-init the locks when all CPUs were stopped by NMI. But it would require passing this information from arch-specific code. It is not worth the complexity. Especially because logbuf_lock and printk_safe buffers have been obsoleted by the lockless ring buffer. Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic") Signed-off-by: Muchun Song Reviewed-by: Petr Mladek Cc: Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210210034823.64867-1-songmuchun@bytedance.com Signed-off-by: Greg Kroah-Hartman commit a461fc0135d66818e62c25999f27b1f3f9c5cd03 Author: Tim Harvey Date: Mon Dec 28 13:10:04 2020 -0800 mfd: gateworks-gsc: Fix interrupt type commit 8d9bf3c3e1451fc8de7b590040a868ade26d6b22 upstream. The Gateworks System Controller has an active-low interrupt. Fix the interrupt request type. Cc: Fixes: d85234994b2f ("mfd: Add Gateworks System Controller core driver") Signed-off-by: Tim Harvey Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit b81946ec1157346545f682e3c742d47d2d554333 Author: Maxim Kiselev Date: Wed Feb 17 14:10:00 2021 +0100 gpio: pcf857x: Fix missing first interrupt commit a8002a35935aaefcd6a42ad3289f62bab947f2ca upstream. If no n_latch value will be provided at driver probe then all pins will be used as an input: gpio->out = ~n_latch; In that case initial state for all pins is "one": gpio->status = gpio->out; So if pcf857x IRQ happens with change pin value from "zero" to "one" then we miss it, because of "one" from IRQ and "one" from initial state leaves corresponding pin unchanged: change = (gpio->status ^ status) & gpio->irq_enabled; The right solution will be to read actual state at driver probe. Cc: stable@vger.kernel.org Fixes: 6e20a0a429bd ("gpio: pcf857x: enable gpio_to_irq() support") Signed-off-by: Maxim Kiselev Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 155796e9519cdcd0afb0ce758a26e714a13628e0 Author: Alexander Usyskin Date: Fri Jan 29 14:07:52 2021 +0200 mei: me: add adler lake point LP DID commit 930c922a987a02936000f15ea62988b7a39c27f5 upstream. Add Adler Lake LP device id. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210129120752.850325-7-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit 4429542ffa79156975654cb5582834c545e9134f Author: Alexander Usyskin Date: Fri Jan 29 14:07:51 2021 +0200 mei: me: add adler lake point S DID commit f7545efaf7950b240de6b8a20b9c3ffd7278538e upstream. Add Adler Lake S device id. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210129120752.850325-6-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit 2b215535c9e504a8e0a879bb226a49e5fd9de43f Author: Tomas Winkler Date: Fri Jan 29 14:07:50 2021 +0200 mei: me: emmitsburg workstation DID commit 372726cb3957dbd69ded9a4e3419d5c6c3bc648e upstream. Add Emmitsburg workstation DID. Cc: Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210129120752.850325-5-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit aa07b9d6c0b6f16d4c84e9eb94f5953b99da5b94 Author: Alexander Usyskin Date: Fri Jan 29 14:07:46 2021 +0200 mei: fix transfer over dma with extended header commit 1309ecc90f16ee9cc3077761e7f4474369747e6e upstream. The size in header field for packet transferred over DMA includes size of the extended header. Include extended header in size check. Add size and sanity checks on extended header. Cc: # v5.10+ Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210129120752.850325-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit a2e835360ff7366a1d8e92d9b7929492e0f348be Author: Alexander Usyskin Date: Mon Feb 8 17:06:48 2021 +0200 mei: bus: block send with vtag on non-conformat FW commit b398d53cd421454d64850f8b1f6d609ede9042d9 upstream. Block data send with vtag if either transport layer or FW client are not supporting vtags. Cc: # v5.10+ Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210208150649.141358-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit 5a6ad2931096719897ab99e27279acf0f9a8bf1c Author: Subbaraman Narayanamurthy Date: Thu Feb 11 19:14:17 2021 -0800 spmi: spmi-pmic-arb: Fix hw_irq overflow commit d19db80a366576d3ffadf2508ed876b4c1faf959 upstream. Currently, when handling the SPMI summary interrupt, the hw_irq number is calculated based on SID, Peripheral ID, IRQ index and APID. This is then passed to irq_find_mapping() to see if a mapping exists for this hw_irq and if available, invoke the interrupt handler. Since the IRQ index uses an "int" type, hw_irq which is of unsigned long data type can take a large value when SID has its MSB set to 1 and the type conversion happens. Because of this, irq_find_mapping() returns 0 as there is no mapping for this hw_irq. This ends up invoking cleanup_irq() as if the interrupt is spurious whereas it is actually a valid interrupt. Fix this by using the proper data type (u32) for id. Cc: stable@vger.kernel.org Signed-off-by: Subbaraman Narayanamurthy Link: https://lore.kernel.org/r/1612812784-26369-1-git-send-email-subbaram@codeaurora.org Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210212031417.3148936-1-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9d3526c51935650b4d644d3971a940c0c9fd87a1 Author: Christophe Leroy Date: Mon Feb 8 15:10:20 2021 +0000 powerpc/32s: Add missing call to kuep_lock on syscall entry commit 57fdfbce89137ae85cd5cef48be168040a47dd13 upstream. Userspace Execution protection and fast syscall entry were implemented independently from each other and were both merged in kernel 5.2, leading to syscall entry missing userspace execution protection. On syscall entry, execution of user space memory must be locked in the same way as on exception entry. Fixes: b86fb88855ea ("powerpc/32: implement fast entry for syscalls on non BOOKE") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/c65e105b63aaf74f91a14f845bc77192350b84a6.1612796617.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 75092840ea2d49c0ee8612a266b90e3e09712221 Author: Hari Bathini Date: Thu Feb 4 17:01:10 2021 +0530 powerpc/kexec_file: fix FDT size estimation for kdump kernel commit 2377c92e37fe97bc5b365f55cf60f56dfc4849f5 upstream. On systems with large amount of memory, loading kdump kernel through kexec_file_load syscall may fail with the below error: "Failed to update fdt with linux,drconf-usable-memory property" This happens because the size estimation for kdump kernel's FDT does not account for the additional space needed to setup usable memory properties. Fix it by accounting for the space needed to include linux,usable-memory & linux,drconf-usable-memory properties while estimating kdump kernel's FDT size. Fixes: 6ecd0163d360 ("powerpc/kexec_file: Add appropriate regions for memory reserve map") Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161243826811.119001.14083048209224609814.stgit@hbathini Signed-off-by: Greg Kroah-Hartman commit 44dee376e030c6ba1b11865ec27b0bd9925c37a4 Author: Christophe Leroy Date: Mon Feb 8 07:17:40 2021 +0000 powerpc/32: Preserve cr1 in exception prolog stack check to fix build error commit 3642eb21256a317ac14e9ed560242c6d20cf06d9 upstream. THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1 Maximum PAGE_SHIFT is 18 for 256k pages so THREAD_ALIGN_SHIFT is 19 at the maximum. No need to clobber cr1, it can be preserved when moving r1 into CR when we check stack overflow. This reduces the number of instructions in Machine Check Exception prolog and fixes a build failure reported by the kernel test robot on v5.10 stable when building with RTAS + VMAP_STACK + KVM. That build failure is due to too many instructions in the prolog hence not fitting between 0x200 and 0x300. Allthough the problem doesn't show up in mainline, it is still worth the change. Fixes: 98bf2d3f4970 ("powerpc/32s: Fix RTAS machine check with VMAP stack") Cc: stable@vger.kernel.org Reported-by: kernel test robot Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/5ae4d545e3ac58e133d2599e0deb88843cb494fc.1612768623.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 02da4584572eb11864411313bb57eccc07e58e74 Author: Shirley Her Date: Fri Feb 5 17:40:51 2021 -0800 mmc: sdhci-pci-o2micro: Bug fix for SDR104 HW tuning failure commit 1ad9f88014ae1d5abccb6fe930bc4c5c311bdc05 upstream. Force chip enter L0 power state during SDR104 HW tuning to avoid tuning failure Signed-off-by: Shirley Her Link: https://lore.kernel.org/r/20210206014051.3418-1-shirley.her@bayhubtech.com Fixes: 7b7d897e8898 ("mmc: sdhci-pci-o2micro: Add HW tuning for SDR104 mode") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2571e59c09ca6bfa631b468a14d7b5e8964bdd8a Author: Frank Li Date: Wed Feb 10 12:19:33 2021 -0600 mmc: sdhci-esdhc-imx: fix kernel panic when remove module commit a56f44138a2c57047f1ea94ea121af31c595132b upstream. In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some circumstances, this may be done while the device is runtime suspended, triggering the below splat. Fix the problem by adding a pm_runtime_get_sync(), before reading the register, which will turn on clocks etc making the device accessible again. [ 1811.323148] mmc1: card aaaa removed [ 1811.347483] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 1811.354988] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core [last unloaded: mmc_core] [ 1811.365726] CPU: 0 PID: 3464 Comm: rmmod Not tainted 5.10.1-sd-99871-g53835a2e8186 #5 [ 1811.373559] Hardware name: Freescale i.MX8DXL EVK (DT) [ 1811.378705] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 1811.384723] pc : sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx] [ 1811.391090] lr : platform_drv_remove+0x2c/0x50 [ 1811.395536] sp : ffff800012c7bcb0 [ 1811.398855] x29: ffff800012c7bcb0 x28: ffff00002c72b900 [ 1811.404181] x27: 0000000000000000 x26: 0000000000000000 [ 1811.409497] x25: 0000000000000000 x24: 0000000000000000 [ 1811.414814] x23: ffff0000042b3890 x22: ffff800009127120 [ 1811.420131] x21: ffff00002c4c9580 x20: ffff0000042d0810 [ 1811.425456] x19: ffff0000042d0800 x18: 0000000000000020 [ 1811.430773] x17: 0000000000000000 x16: 0000000000000000 [ 1811.436089] x15: 0000000000000004 x14: ffff000004019c10 [ 1811.441406] x13: 0000000000000000 x12: 0000000000000020 [ 1811.446723] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f [ 1811.452040] x9 : fefefeff6364626d x8 : 7f7f7f7f7f7f7f7f [ 1811.457356] x7 : 78725e6473607372 x6 : 0000000080808080 [ 1811.462673] x5 : 0000000000000000 x4 : 0000000000000000 [ 1811.467990] x3 : ffff800011ac1cb0 x2 : 0000000000000000 [ 1811.473307] x1 : ffff8000091214d4 x0 : ffff8000133a0030 [ 1811.478624] Call trace: [ 1811.481081] sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx] [ 1811.487098] platform_drv_remove+0x2c/0x50 [ 1811.491198] __device_release_driver+0x188/0x230 [ 1811.495818] driver_detach+0xc0/0x14c [ 1811.499487] bus_remove_driver+0x5c/0xb0 [ 1811.503413] driver_unregister+0x30/0x60 [ 1811.507341] platform_driver_unregister+0x14/0x20 [ 1811.512048] sdhci_esdhc_imx_driver_exit+0x1c/0x3a8 [sdhci_esdhc_imx] [ 1811.518495] __arm64_sys_delete_module+0x19c/0x230 [ 1811.523291] el0_svc_common.constprop.0+0x78/0x1a0 [ 1811.528086] do_el0_svc+0x24/0x90 [ 1811.531405] el0_svc+0x14/0x20 [ 1811.534461] el0_sync_handler+0x1a4/0x1b0 [ 1811.538474] el0_sync+0x174/0x180 [ 1811.541801] Code: a9025bf5 f9403e95 f9400ea0 9100c000 (b9400000) [ 1811.547902] ---[ end trace 3fb1a3bd48ff7be5 ]--- Signed-off-by: Frank Li Cc: stable@vger.kernel.org # v4.0+ Link: https://lore.kernel.org/r/20210210181933.29263-1-Frank.Li@nxp.com [Ulf: Clarified the commit message a bit] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit eaf8bdc9bfa28cd3749a41315a4ec10a90d244e7 Author: Fangrui Song Date: Fri Jan 15 11:52:22 2021 -0800 module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols commit ebfac7b778fac8b0e8e92ec91d0b055f046b4604 upstream. clang-12 -fno-pic (since https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6) can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail` on x86. The two forms should have identical behaviors on x86-64 but the former causes GNU as<2.37 to produce an unreferenced undefined symbol _GLOBAL_OFFSET_TABLE_. (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the linker behavior is identical as far as Linux kernel is concerned.) Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for external function calls on x86. Note: ld -z defs and dynamic loaders do not error for unreferenced undefined symbols so the module loader is reading too much. If we ever need to ignore more symbols, the code should be refactored to ignore unreferenced symbols. Cc: Link: https://github.com/ClangBuiltLinux/linux/issues/1250 Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27178 Reported-by: Marco Elver Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Tested-by: Marco Elver Signed-off-by: Fangrui Song Signed-off-by: Jessica Yu Signed-off-by: Greg Kroah-Hartman commit 5c24934661f7850de425810703829020c50e8b57 Author: Subbaraman Narayanamurthy Date: Fri Feb 5 10:08:53 2021 +0000 nvmem: qcom-spmi-sdam: Fix uninitialized pdev pointer commit e2057ee29973b9741d43d3f475a6b02fb46a0e61 upstream. "sdam->pdev" is uninitialized and it is used to print error logs. Fix it. Since device pointer can be used from sdam_config, use it directly thereby removing pdev pointer. Fixes: 40ce9798794f ("nvmem: add QTI SDAM driver") Cc: stable@vger.kernel.org Signed-off-by: Subbaraman Narayanamurthy Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210205100853.32372-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fb0143a9a28d30fef34ce2f604eedb2ed2a4c68b Author: Paolo Bonzini Date: Thu Feb 18 07:16:59 2021 -0500 KVM: nSVM: fix running nested guests when npt=0 commit a04aead144fd938c2d9869eb187e5b9ea0009bae upstream. In case of npt=0 on host, nSVM needs the same .inject_page_fault tweak as VMX has, to make sure that shadow mmu faults are injected as vmexits. It is not clear why this is needed at all, but for now keep the same code as VMX and we'll fix it for both. Based on a patch by Maxim Levitsky . Fixes: 7c86663b68ba ("KVM: nSVM: inject exceptions via svm_check_nested_events") Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 104c153a2605a22c4b44351ad809d886e2bf3fc9 Author: Vlastimil Babka Date: Wed Feb 24 12:09:39 2021 -0800 mm, compaction: make fast_isolate_freepages() stay within zone commit 6e2b7044c199229a3d20cefbd3184968238c4184 upstream. Compaction always operates on pages from a single given zone when isolating both pages to migrate and freepages. Pageblock boundaries are intersected with zone boundaries to be safe in case zone starts or ends in the middle of pageblock. The use of pageblock_pfn_to_page() protects against non-contiguous pageblocks. The functions fast_isolate_freepages() and fast_isolate_around() don't currently protect the fast freepage isolation thoroughly enough against these corner cases, and can result in freepage isolation operate outside of zone boundaries: - in fast_isolate_freepages() if we get a pfn from the first pageblock of a zone that starts in the middle of that pageblock, 'highest' can be a pfn outside of the zone. If we fail to isolate anything in this function, we may then call fast_isolate_around() on a pfn outside of the zone and there effectively do a set_pageblock_skip(page_to_pfn(highest)) which may currently hit a VM_BUG_ON() in some configurations - fast_isolate_around() checks only the zone end boundary and not beginning, nor that the pageblock is contiguous (with pageblock_pfn_to_page()) so it's possible that we end up calling isolate_freepages_block() on a range of pfn's from two different zones and end up e.g. isolating freepages under the wrong zone's lock. This patch should fix the above issues. Link: https://lkml.kernel.org/r/20210217173300.6394-1-vbabka@suse.cz Fixes: 5a811889de10 ("mm, compaction: use free lists to quickly locate a migration target") Signed-off-by: Vlastimil Babka Acked-by: David Rientjes Acked-by: Mel Gorman Cc: Andrea Arcangeli Cc: David Hildenbrand Cc: Michal Hocko Cc: Mike Rapoport Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 979bdb8f933857788c9cee2fe40b310c6ba14630 Author: Dave Hansen Date: Wed Feb 24 12:09:15 2021 -0800 mm/vmscan: restore zone_reclaim_mode ABI commit 519983645a9f2ec339cabfa0c6ef7b09be985dd0 upstream. I went to go add a new RECLAIM_* mode for the zone_reclaim_mode sysctl. Like a good kernel developer, I also went to go update the documentation. I noticed that the bits in the documentation didn't match the bits in the #defines. The VM never explicitly checks the RECLAIM_ZONE bit. The bit is, however implicitly checked when checking 'node_reclaim_mode==0'. The RECLAIM_ZONE #define was removed in a cleanup. That, by itself is fine. But, when the bit was removed (bit 0) the _other_ bit locations also got changed. That's not OK because the bit values are documented to mean one specific thing. Users surely do not expect the meaning to change from kernel to kernel. The end result is that if someone had a script that did: sysctl vm.zone_reclaim_mode=1 it would have gone from enabling node reclaim for clean unmapped pages to writing out pages during node reclaim after the commit in question. That's not great. Put the bits back the way they were and add a comment so something like this is a bit harder to do again. Update the documentation to make it clear that the first bit is ignored. Link: https://lkml.kernel.org/r/20210219172555.FF0CDF23@viggo.jf.intel.com Signed-off-by: Dave Hansen Fixes: 648b5cf368e0 ("mm/vmscan: remove unused RECLAIM_OFF/RECLAIM_ZONE") Reviewed-by: Ben Widawsky Reviewed-by: Oscar Salvador Acked-by: David Rientjes Acked-by: Christoph Lameter Cc: Alex Shi Cc: Daniel Wagner Cc: "Tobin C. Harding" Cc: Christoph Lameter Cc: Andrew Morton Cc: Huang Ying Cc: Dan Williams Cc: Qian Cai Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 96c4916bc3ba8c9663867e20a69431781bc21d85 Author: Mike Kravetz Date: Wed Feb 24 12:07:54 2021 -0800 hugetlb: fix copy_huge_page_from_user contig page struct assumption commit 3272cfc2525b3a2810a59312d7a1e6f04a0ca3ef upstream. page structs are not guaranteed to be contiguous for gigantic pages. The routine copy_huge_page_from_user can encounter gigantic pages, yet it assumes page structs are contiguous when copying pages from user space. Since page structs for the target gigantic page are not contiguous, the data copied from user space could overwrite other pages not associated with the gigantic page and cause data corruption. Non-contiguous page structs are generally not an issue. However, they can exist with a specific kernel configuration and hotplug operations. For example: Configure the kernel with CONFIG_SPARSEMEM and !CONFIG_SPARSEMEM_VMEMMAP. Then, hotplug add memory for the area where the gigantic page will be allocated. Link: https://lkml.kernel.org/r/20210217184926.33567-2-mike.kravetz@oracle.com Fixes: 8fb5debc5fcd ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support") Signed-off-by: Mike Kravetz Cc: Zi Yan Cc: Davidlohr Bueso Cc: "Kirill A . Shutemov" Cc: Andrea Arcangeli Cc: Matthew Wilcox Cc: Oscar Salvador Cc: Joao Martins Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 82f4f3c9abaac832452902dc87af1447d455048f Author: Mike Kravetz Date: Wed Feb 24 12:07:50 2021 -0800 hugetlb: fix update_and_free_page contig page struct assumption commit dbfee5aee7e54f83d96ceb8e3e80717fac62ad63 upstream. page structs are not guaranteed to be contiguous for gigantic pages. The routine update_and_free_page can encounter a gigantic page, yet it assumes page structs are contiguous when setting page flags in subpages. If update_and_free_page encounters non-contiguous page structs, we can see “BUG: Bad page state in process …” errors. Non-contiguous page structs are generally not an issue. However, they can exist with a specific kernel configuration and hotplug operations. For example: Configure the kernel with CONFIG_SPARSEMEM and !CONFIG_SPARSEMEM_VMEMMAP. Then, hotplug add memory for the area where the gigantic page will be allocated. Zi Yan outlined steps to reproduce here [1]. [1] https://lore.kernel.org/linux-mm/16F7C58B-4D79-41C5-9B64-A1A1628F4AF2@nvidia.com/ Link: https://lkml.kernel.org/r/20210217184926.33567-1-mike.kravetz@oracle.com Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at runtime") Signed-off-by: Zi Yan Signed-off-by: Mike Kravetz Cc: Zi Yan Cc: Davidlohr Bueso Cc: "Kirill A . Shutemov" Cc: Andrea Arcangeli Cc: Matthew Wilcox Cc: Oscar Salvador Cc: Joao Martins Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f8880ddb29b4a6933c7909a67b79cf04977a68cd Author: Muchun Song Date: Wed Feb 24 12:04:22 2021 -0800 mm: memcontrol: fix get_active_memcg return value commit 1685bde6b9af55923180a76152036c7fb7176db0 upstream. We use a global percpu int_active_memcg variable to store the remote memcg when we are in the interrupt context. But get_active_memcg always return the current->active_memcg or root_mem_cgroup. The remote memcg (set in the interrupt context) is ignored. This is not what we want. So fix it. Link: https://lkml.kernel.org/r/20210223091101.42150-1-songmuchun@bytedance.com Fixes: 37d5985c003d ("mm: kmem: prepare remote memcg charging infra for interrupt contexts") Signed-off-by: Muchun Song Reviewed-by: Shakeel Butt Reviewed-by: Roman Gushchin Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d96466f96de3b9c0484d1eb0ec89c34a908f9937 Author: Muchun Song Date: Wed Feb 24 12:04:19 2021 -0800 mm: memcontrol: fix swap undercounting in cgroup2 commit cae3af62b33aa931427a0f211e04347b22180b36 upstream. When pages are swapped in, the VM may retain the swap copy to avoid repeated writes in the future. It's also retained if shared pages are faulted back in some processes, but not in others. During that time we have an in-memory copy of the page, as well as an on-swap copy. Cgroup1 and cgroup2 handle these overlapping lifetimes slightly differently due to the nature of how they account memory and swap: Cgroup1 has a unified memory+swap counter that tracks a data page regardless whether it's in-core or swapped out. On swapin, we transfer the charge from the swap entry to the newly allocated swapcache page, even though the swap entry might stick around for a while. That's why we have a mem_cgroup_uncharge_swap() call inside mem_cgroup_charge(). Cgroup2 tracks memory and swap as separate, independent resources and thus has split memory and swap counters. On swapin, we charge the newly allocated swapcache page as memory, while the swap slot in turn must remain charged to the swap counter as long as its allocated too. The cgroup2 logic was broken by commit 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control"), because it accidentally removed the do_memsw_account() check in the branch inside mem_cgroup_uncharge() that was supposed to tell the difference between the charge transfer in cgroup1 and the separate counters in cgroup2. As a result, cgroup2 currently undercounts retained swap to varying degrees: swap slots are cached up to 50% of the configured limit or total available swap space; partially faulted back shared pages are only limited by physical capacity. This in turn allows cgroups to significantly overconsume their alloted swap space. Add the do_memsw_account() check back to fix this problem. Link: https://lkml.kernel.org/r/20210217153237.92484-1-songmuchun@bytedance.com Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") Signed-off-by: Muchun Song Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Cc: Vladimir Davydov Cc: [5.8+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0eafbca6c4aa1c0689fcc000e6fa3e2f9267c642 Author: NeilBrown Date: Thu Feb 25 17:22:29 2021 -0800 x86: fix seq_file iteration for pat/memtype.c commit 3d2fc4c082448e9c05792f9b2a11c1d5db408b85 upstream. The memtype seq_file iterator allocates a buffer in the ->start and ->next functions and frees it in the ->show function. The preferred handling for such resources is to free them in the subsequent ->next or ->stop function call. Since Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") there is no guarantee that ->show will be called after ->next, so this function can now leak memory. So move the freeing of the buffer to ->next and ->stop. Link: https://lkml.kernel.org/r/161248539022.21478.13874455485854739066.stgit@noble1 Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: NeilBrown Cc: Xin Long Cc: Alexander Viro Cc: Andy Lutomirski Cc: Dave Hansen Cc: "David S. Miller" Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Marcelo Ricardo Leitner Cc: Neil Horman Cc: Peter Zijlstra Cc: Vlad Yasevich Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a3330d359bdc3cf944c081aabf6bffbd43645e0a Author: NeilBrown Date: Thu Feb 25 17:22:25 2021 -0800 seq_file: document how per-entry resources are managed. commit b3656d8227f4c45812c6b40815d8f4e446ed372a upstream. Patch series "Fix some seq_file users that were recently broken". A recent change to seq_file broke some users which were using seq_file in a non-"standard" way ... though the "standard" isn't documented, so they can be excused. The result is a possible leak - of memory in one case, of references to a 'transport' in the other. These three patches: 1/ document and explain the problem 2/ fix the problem user in x86 3/ fix the problem user in net/sctp This patch (of 3): Users of seq_file will sometimes find it convenient to take a resource, such as a lock or memory allocation, in the ->start or ->next operations. These are per-entry resources, distinct from per-session resources which are taken in ->start and released in ->stop. The preferred management of these is release the resource on the subsequent call to ->next or ->stop. However prior to Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") it happened that ->show would always be called after ->start or ->next, and a few users chose to release the resource in ->show. This is no longer reliable. Since the mentioned commit, ->next will always come after a successful ->show (to ensure m->index is updated correctly), so the original ordering cannot be maintained. This patch updates the documentation to clearly state the required behaviour. Other patches will fix the few problematic users. [akpm@linux-foundation.org: fix typo, per Willy] Link: https://lkml.kernel.org/r/161248518659.21478.2484341937387294998.stgit@noble1 Link: https://lkml.kernel.org/r/161248539020.21478.3147971477400875336.stgit@noble1 Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: NeilBrown Cc: Xin Long Cc: Alexander Viro Cc: Jonathan Corbet Cc: Ingo Molnar Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Vlad Yasevich Cc: Neil Horman Cc: Marcelo Ricardo Leitner Cc: "David S. Miller" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4fd6cdae24accd1ea87d247312b4ac1ead00e8ff Author: Pan Bian Date: Wed Jan 20 00:51:13 2021 -0800 fs/affs: release old buffer head on error path commit 70779b897395b330ba5a47bed84f94178da599f9 upstream. The reference count of the old buffer head should be decremented on path that fails to get the new buffer head. Fixes: 6b4657667ba0 ("fs/affs: add rename exchange") CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Pan Bian Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 3eb627806cce28fb984b7807097caa0a6f233cba Author: Pan Bian Date: Thu Jan 21 01:18:47 2021 -0800 mtd: spi-nor: hisi-sfc: Put child node np on error path commit fe6653460ee7a7dbe0cd5fd322992af862ce5ab0 upstream. Put the child node np when it fails to get or register device. Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver") Cc: stable@vger.kernel.org Signed-off-by: Pan Bian [ta: Add Fixes tag and Cc stable] Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210121091847.85362-1-bianpan2016@163.com Signed-off-by: Greg Kroah-Hartman commit 5ca1b3b48b7e05ae2e5a7fad82c1d93f1a0310f1 Author: Takahiro Kuwano Date: Fri Oct 2 14:18:02 2020 +0900 mtd: spi-nor: core: Add erase size check for erase command initialization commit 58fa22f68fcaff20ce4d08a6adffa64f65ccd37d upstream. Even if erase type is same as previous region, erase size can be different if the previous region is overlaid region. Since 'region->size' is assigned to 'cmd->size' for overlaid region, comparing 'erase->size' and 'cmd->size' can detect previous overlaid region. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/13d47e8d8991b8a7fd8cc7b9e2a5319c56df35cc.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman commit 0bea6d489bb0b5a21eb297a302e843fd31d1c6e1 Author: Takahiro Kuwano Date: Fri Oct 2 14:18:01 2020 +0900 mtd: spi-nor: core: Fix erase type discovery for overlaid region commit 969b276718de37dfe66fce3a5633f611e8cd58fd upstream. In case of overlaid regions in which their biggest erase size command overpasses in size the region's size, only the non-overlaid portion of the sector gets erased. For example, if a Sector Erase command is applied to a 256-kB range that is overlaid by 4-kB sectors, the overlaid 4-kB sectors are not affected by the erase. For overlaid regions, 'region->size' is assigned to 'cmd->size' later in spi_nor_init_erase_cmd(), so 'erase->size' can be greater than 'len'. Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano [ta: Update commit description, add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/fa5d8b944a5cca488ac54ba37c95e775ac2deb34.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman commit d2e6bc2a0dffd74eb438852dc64be52fce40d49c Author: Takahiro Kuwano Date: Fri Oct 2 14:17:59 2020 +0900 mtd: spi-nor: sfdp: Fix wrong erase type bitmask for overlaid region commit abdf5a5ef9652bad4d58058bc22ddf23543ba3e1 upstream. At the time spi_nor_region_check_overlay() is called, the erase types are sorted in ascending order of erase size. The 'erase_type' should be masked with 'BIT(erase[i].idx)' instead of 'BIT(i)'. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/fd90c40d5b626a1319a78fc2bcee79a8871d4d57.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman commit 68ce45e518423cf21dd60374713212d26b0f01fa Author: Takahiro Kuwano Date: Fri Oct 2 14:18:00 2020 +0900 mtd: spi-nor: sfdp: Fix last erase region marking commit 9166f4af32db74e1544a2149aef231ff24515ea3 upstream. The place of spi_nor_region_mark_end() must be moved, because 'i' is re-used for the index of erase[]. Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table") Cc: stable@vger.kernel.org Signed-off-by: Takahiro Kuwano [ta: Add Fixes tag and Cc to stable] Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/02ce8d84b7989ebee33382f6494df53778dd508e.1601612872.git.Takahiro.Kuwano@infineon.com Signed-off-by: Greg Kroah-Hartman commit 1e303019d0841f08a4a3a739c558e9e76e3f3b19 Author: Suzuki K Poulose Date: Mon Feb 1 11:13:51 2021 -0700 coresight: etm4x: Handle accesses to TRCSTALLCTLR commit f72896063396b0cb205cbf0fd76ec6ab3ca11c8a upstream. TRCSTALLCTLR register is only implemented if TRCIDR3.STALLCTL == 0b1 Make sure the driver touches the register only it is implemented. Link: https://lore.kernel.org/r/20210127184617.3684379-1-suzuki.poulose@arm.com Cc: stable@vger.kernel.org Cc: Mathieu Poirier Cc: Mike Leach Cc: Leo Yan Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20210201181351.1475223-32-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman commit eb5f5a70cbf568601db140c799cef9dd6ffa1db8 Author: Alexander Usyskin Date: Sun Jan 24 13:49:38 2021 +0200 watchdog: mei_wdt: request stop on unregister commit 740c0a57b8f1e36301218bf549f3c9cc833a60be upstream. The MEI bus has a special behavior on suspend it destroys all the attached devices, this is due to the fact that also firmware context is not persistent across power flows. If watchdog on MEI bus is ticking before suspending the firmware times out and reports that the OS is missing watchdog tick. Send the stop command to the firmware on watchdog unregistered to eliminate the false event on suspend. This does not make the things worse from the user-space perspective as a user-space should re-open watchdog device after suspending before this patch. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210124114938.373885-1-tomas.winkler@intel.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 11859b15fbc2376545277ee18cf01ec9e7dc4e5f Author: Sai Prakash Ranjan Date: Tue Jan 26 20:32:41 2021 +0530 watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ commit a4f3407c41605d14f09e490045d0609990cd5d94 upstream. As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1) of watchdog control register is wakeup interrupt enable bit and not related to bark interrupt at all, BIT(0) is used for that. So remove incorrect usage of this bit when supporting bark irq for pre-timeout notification. Currently with this bit set and bark interrupt specified, pre-timeout notification and/or watchdog reset/bite does not occur. Fixes: 36375491a439 ("watchdog: qcom: support pre-timeout when the bark irq is available") Cc: stable@vger.kernel.org Signed-off-by: Sai Prakash Ranjan Reviewed-by: Guenter Roeck Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20210126150241.10009-1-saiprakash.ranjan@codeaurora.org Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit b1bac3e102523f4db1de401f208b704223f83268 Author: Tobias Klauser Date: Tue Feb 16 18:33:05 2021 +0100 riscv: Disable KSAN_SANITIZE for vDSO commit f3d60f2a25e4417e1676161fe42115de3e3f98a2 upstream. We use the generic C VDSO implementations of a handful of clock-related functions. When kasan is enabled this results in asan stub calls that are unlikely to be resolved by userspace, this just disables KASAN when building the VDSO. Verified the fix on a kernel with KASAN enabled using vDSO selftests. Link: https://lore.kernel.org/lkml/CACT4Y+ZNJBnkKHXUf=tm_yuowvZvHwN=0rmJ=7J+xFd+9r_6pQ@mail.gmail.com/ Tested-by: Tobias Klauser Signed-off-by: Tobias Klauser Tested-by: Dmitry Vyukov [Palmer: commit text] Fixes: ad5d1122b82f ("riscv: use vDSO common flow to reduce the latency of the time-related functions") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 1dd5a56bac03b7f4c681a553f1c9f5c26e4fc0a7 Author: Will Deacon Date: Thu Feb 18 14:03:46 2021 +0000 arm64: spectre: Prevent lockdep splat on v4 mitigation enable path commit a2c42bbabbe260b7626d8459093631a6e16ee0ee upstream. The Spectre-v4 workaround is re-configured when resuming from suspend, as the firmware may have re-enabled the mitigation despite the user previously asking for it to be disabled. Enabling or disabling the workaround can result in an undefined instruction exception on CPUs which implement PSTATE.SSBS but only allow it to be configured by adjusting the SPSR on exception return. We handle this by installing an 'undef hook' which effectively emulates the access. Installing this hook requires us to take a couple of spinlocks both to avoid corrupting the internal list of hooks but also to ensure that we don't run into an unhandled exception. Unfortunately, when resuming from suspend, we haven't yet called rcu_idle_exit() and so lockdep gets angry about "suspicious RCU usage". In doing so, it tries to print a warning, which leads it to get even more suspicious, this time about itself: | rcu_scheduler_active = 2, debug_locks = 1 | RCU used illegally from extended quiescent state! | 1 lock held by swapper/0: | #0: (logbuf_lock){-.-.}-{2:2}, at: vprintk_emit+0x88/0x198 | | Call trace: | dump_backtrace+0x0/0x1d8 | show_stack+0x18/0x24 | dump_stack+0xe0/0x17c | lockdep_rcu_suspicious+0x11c/0x134 | trace_lock_release+0xa0/0x160 | lock_release+0x3c/0x290 | _raw_spin_unlock+0x44/0x80 | vprintk_emit+0xbc/0x198 | vprintk_default+0x44/0x6c | vprintk_func+0x1f4/0x1fc | printk+0x54/0x7c | lockdep_rcu_suspicious+0x30/0x134 | trace_lock_acquire+0xa0/0x188 | lock_acquire+0x50/0x2fc | _raw_spin_lock+0x68/0x80 | spectre_v4_enable_mitigation+0xa8/0x30c | __cpu_suspend_exit+0xd4/0x1a8 | cpu_suspend+0xa0/0x104 | psci_cpu_suspend_enter+0x3c/0x5c | psci_enter_idle_state+0x44/0x74 | cpuidle_enter_state+0x148/0x2f8 | cpuidle_enter+0x38/0x50 | do_idle+0x1f0/0x2b4 Prevent these splats by running __cpu_suspend_exit() with RCU watching. Cc: Mark Rutland Cc: Lorenzo Pieralisi Cc: Peter Zijlstra Cc: Boqun Feng Cc: Marc Zyngier Cc: Saravana Kannan Suggested-by: "Paul E . McKenney" Reported-by: Sami Tolvanen Fixes: c28762070ca6 ("arm64: Rewrite Spectre-v4 mitigation code") Cc: Acked-by: Paul E. McKenney Acked-by: Marc Zyngier Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210218140346.5224-1-will@kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit a3c13d2352a272670649c375138e3ec274144574 Author: Shaoying Xu Date: Tue Feb 16 18:32:34 2021 +0000 arm64 module: set plt* section addresses to 0x0 commit f5c6d0fcf90ce07ee0d686d465b19b247ebd5ed7 upstream. These plt* and .text.ftrace_trampoline sections specified for arm64 have non-zero addressses. Non-zero section addresses in a relocatable ELF would confuse GDB when it tries to compute the section offsets and it ends up printing wrong symbol addresses. Therefore, set them to zero, which mirrors the change in commit 5d8591bc0fba ("module: set ksymtab/kcrctab* section addresses to 0x0"). Reported-by: Frank van der Linden Signed-off-by: Shaoying Xu Cc: Link: https://lore.kernel.org/r/20210216183234.GA23876@amazon.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 862208a73422ef70860791fd0a155a11aaaeb7c2 Author: He Zhe Date: Tue Feb 23 16:25:34 2021 +0800 arm64: uprobe: Return EOPNOTSUPP for AARCH32 instruction probing commit d47422d953e258ad587b5edf2274eb95d08bdc7d upstream. As stated in linux/errno.h, ENOTSUPP should never be seen by user programs. When we set up uprobe with 32-bit perf and arm64 kernel, we would see the following vague error without useful hint. The sys_perf_event_open() syscall returned with 524 (INTERNAL ERROR: strerror_r(524, [buf], 128)=22) Use EOPNOTSUPP instead to indicate such cases. Signed-off-by: He Zhe Link: https://lore.kernel.org/r/20210223082535.48730-1-zhe.he@windriver.com Cc: Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit aeeb2a40c7656240348b60eefef81d1320a84ea8 Author: qiuguorui1 Date: Thu Feb 18 20:59:00 2021 +0800 arm64: kexec_file: fix memory leakage in create_dtb() when fdt_open_into() fails commit 656d1d58d8e0958d372db86c24f0b2ea36f50888 upstream. in function create_dtb(), if fdt_open_into() fails, we need to vfree buf before return. Fixes: 52b2a8af7436 ("arm64: kexec_file: load initrd and device-tree") Cc: stable@vger.kernel.org # v5.0 Signed-off-by: qiuguorui1 Link: https://lore.kernel.org/r/20210218125900.6810-1-qiuguorui1@huawei.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 233ad7f315400693bdbd745869d17ee9184496ba Author: Viresh Kumar Date: Mon Feb 22 12:48:06 2021 +0530 mailbox: arm_mhuv2: Skip calling kfree() with invalid pointer commit 6b50df2b8c208a04d44b8df5b7baaf668ceb8fc3 upstream. It is possible that 'data' passed to kfree() is set to a error value instead of allocated space. Make sure it doesn't get called with invalid pointer. Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver") Cc: v5.11 # v5.11 Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Viresh Kumar Signed-off-by: Jassi Brar Signed-off-by: Greg Kroah-Hartman commit b66c08042560ff1ed9901bcd2481118dc9ad3e70 Author: Isaac J. Manjarres Date: Mon Jan 25 13:52:25 2021 -0800 iommu/arm-smmu-qcom: Fix mask extraction for bootloader programmed SMRs commit dead723e6f049e9fb6b05e5b93456982798ea961 upstream. When extracting the mask for a SMR that was programmed by the bootloader, the SMR's valid bit is also extracted and is treated as part of the mask, which is not correct. Consider the scenario where an SMMU master whose context is determined by a bootloader programmed SMR is removed (omitting parts of device/driver core): ->iommu_release_device() -> arm_smmu_release_device() -> arm_smmu_master_free_smes() -> arm_smmu_free_sme() /* Assume that the SME is now free */ -> arm_smmu_write_sme() -> arm_smmu_write_smr() /* Construct SMR value using mask and SID */ Since the valid bit was considered as part of the mask, the SMR will be programmed as valid. Fix the SMR mask extraction step for bootloader programmed SMRs by masking out the valid bit when we know that we're already working with a valid SMR. Fixes: 07a7f2caaa5a ("iommu/arm-smmu-qcom: Read back stream mappings") Signed-off-by: Isaac J. Manjarres Cc: stable@vger.kernel.org Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/1611611545-19055-1-git-send-email-isaacm@codeaurora.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 68bc92d007bba77617a0d1f440ef0ac95586afcb Author: Suzuki K Poulose Date: Wed Feb 3 23:00:57 2021 +0000 arm64: Extend workaround for erratum 1024718 to all versions of Cortex-A55 commit c0b15c25d25171db4b70cc0b7dbc1130ee94017d upstream. The erratum 1024718 affects Cortex-A55 r0p0 to r2p0. However we apply the work around for r0p0 - r1p0. Unfortunately this won't be fixed for the future revisions for the CPU. Thus extend the work around for all versions of A55, to cover for r2p0 and any future revisions. Cc: stable@vger.kernel.org Cc: Catalin Marinas Cc: Will Deacon Cc: James Morse Cc: Kunihiko Hayashi Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20210203230057.3961239-1-suzuki.poulose@arm.com [will: Update Kconfig help text] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit e870809d0ba82748a8ff58508386bc32a769b3be Author: Masami Hiramatsu Date: Thu Feb 18 23:29:23 2021 +0900 kprobes: Fix to delay the kprobes jump optimization commit c85c9a2c6e368dc94907e63babb18a9788e5c9b6 upstream. Commit 36dadef23fcc ("kprobes: Init kprobes in early_initcall") moved the kprobe setup in early_initcall(), which includes kprobe jump optimization. The kprobes jump optimizer involves synchronize_rcu_tasks() which depends on the ksoftirqd and rcu_spawn_tasks_*(). However, since those are setup in core_initcall(), kprobes jump optimizer can not run at the early_initcall(). To avoid this issue, make the kprobe optimization disabled in the early_initcall() and enables it in subsys_initcall(). Note that non-optimized kprobes is still available after early_initcall(). Only jump optimization is delayed. Link: https://lkml.kernel.org/r/161365856280.719838.12423085451287256713.stgit@devnote2 Fixes: 36dadef23fcc ("kprobes: Init kprobes in early_initcall") Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: RCU Cc: Michael Ellerman Cc: Andrew Morton Cc: Daniel Axtens Cc: Frederic Weisbecker Cc: Neeraj Upadhyay Cc: Joel Fernandes Cc: Michal Hocko Cc: "Theodore Y . Ts'o" Cc: Oleksiy Avramchenko Cc: stable@vger.kernel.org Reported-by: Paul E. McKenney Reported-by: Sebastian Andrzej Siewior Reported-by: Uladzislau Rezki Acked-by: Paul E. McKenney Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 4d5fe992200b63342a42893862ee09af55c254ca Author: Frederic Weisbecker Date: Mon Feb 1 00:05:48 2021 +0100 entry/kvm: Explicitly flush pending rcuog wakeup before last rescheduling point commit 4ae7dc97f726ea95c58ac58af71cc034ad22d7de upstream. Following the idle loop model, cleanly check for pending rcuog wakeup before the last rescheduling point upon resuming to guest mode. This way we can avoid to do it from rcu_user_enter() with the last resort self-IPI hack that enforces rescheduling. Suggested-by: Peter Zijlstra Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210131230548.32970-6-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit e868ddb4381e3b1d24860a040e552fe9a5cf26dc Author: Frederic Weisbecker Date: Mon Feb 1 00:05:47 2021 +0100 entry: Explicitly flush pending rcuog wakeup before last rescheduling point commit 47b8ff194c1fd73d58dc339b597d466fe48c8958 upstream. Following the idle loop model, cleanly check for pending rcuog wakeup before the last rescheduling point on resuming to user mode. This way we can avoid to do it from rcu_user_enter() with the last resort self-IPI hack that enforces rescheduling. Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210131230548.32970-5-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 23e600cc996fb66a2f99550d6d730b051d379dc6 Author: Frederic Weisbecker Date: Mon Feb 1 00:05:46 2021 +0100 rcu/nocb: Trigger self-IPI on late deferred wake up before user resume commit f8bb5cae9616224a39cbb399de382d36ac41df10 upstream. Entering RCU idle mode may cause a deferred wake up of an RCU NOCB_GP kthread (rcuog) to be serviced. Unfortunately the call to rcu_user_enter() is already past the last rescheduling opportunity before we resume to userspace or to guest mode. We may escape there with the woken task ignored. The ultimate resort to fix every callsites is to trigger a self-IPI (nohz_full depends on arch to implement arch_irq_work_raise()) that will trigger a reschedule on IRQ tail or guest exit. Eventually every site that want a saner treatment will need to carefully place a call to rcu_nocb_flush_deferred_wakeup() before the last explicit need_resched() check upon resume. Fixes: 96d3fd0d315a (rcu: Break call_rcu() deadlock involving scheduler and perf) Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210131230548.32970-4-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3b7f1cc4be2bf8c192b5bc89c1ad697df061aa4b Author: Frederic Weisbecker Date: Mon Feb 1 00:05:45 2021 +0100 rcu/nocb: Perform deferred wake up before last idle's need_resched() check commit 43789ef3f7d61aa7bed0cb2764e588fc990c30ef upstream. Entering RCU idle mode may cause a deferred wake up of an RCU NOCB_GP kthread (rcuog) to be serviced. Usually a local wake up happening while running the idle task is handled in one of the need_resched() checks carefully placed within the idle loop that can break to the scheduler. Unfortunately the call to rcu_idle_enter() is already beyond the last generic need_resched() check and we may halt the CPU with a resched request unhandled, leaving the task hanging. Fix this with splitting the rcuog wakeup handling from rcu_idle_enter() and place it before the last generic need_resched() check in the idle loop. It is then assumed that no call to call_rcu() will be performed after that in the idle loop until the CPU is put in low power mode. Fixes: 96d3fd0d315a (rcu: Break call_rcu() deadlock involving scheduler and perf) Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210131230548.32970-3-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 487e35b007b33dcb33366b4857a4f55772f5274e Author: Frederic Weisbecker Date: Mon Feb 1 00:05:44 2021 +0100 rcu: Pull deferred rcuog wake up to rcu_eqs_enter() callers commit 54b7429efffc99e845ba9381bee3244f012a06c2 upstream. Deferred wakeup of rcuog kthreads upon RCU idle mode entry is going to be handled differently whether initiated by idle, user or guest. Prepare with pulling that control up to rcu_eqs_enter() callers. Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210131230548.32970-2-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3546595217067838fff0dd49b3bf33577382bd9b Author: Cédric Le Goater Date: Fri Jan 22 08:50:29 2021 +0100 powerpc/prom: Fix "ibm,arch-vec-5-platform-support" scan commit ed5b00a05c2ae95b59adc3442f45944ec632e794 upstream. The "ibm,arch-vec-5-platform-support" property is a list of pairs of bytes representing the options and values supported by the platform firmware. At boot time, Linux scans this list and activates the available features it recognizes : Radix and XIVE. A recent change modified the number of entries to loop on and 8 bytes, 4 pairs of { options, values } entries are always scanned. This is fine on KVM but not on PowerVM which can advertises less. As a consequence on this platform, Linux reads extra entries pointing to random data, interprets these as available features and tries to activate them, leading to a firmware crash in ibm,client-architecture-support. Fix that by using the property length of "ibm,arch-vec-5-platform-support". Fixes: ab91239942a9 ("powerpc/prom: Remove VLA in prom_check_platform_support()") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Cédric Le Goater Reviewed-by: Fabiano Rosas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210122075029.797013-1-clg@kaod.org Signed-off-by: Greg Kroah-Hartman commit f553b5f7758de82ade7ebcef8f80233362e33350 Author: Thomas Gleixner Date: Wed Feb 10 00:40:42 2021 +0100 x86/entry: Fix instrumentation annotation commit 15f720aabe71a5662c4198b22532d95bbeec80ef upstream. Embracing a callout into instrumentation_begin() / instrumentation_begin() does not really make sense. Make the latter instrumentation_end(). Fixes: 2f6474e4636b ("x86/entry: Switch XEN/PV hypercall entry to IDTENTRY") Signed-off-by: Thomas Gleixner Reviewed-by: Kees Cook Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210210002512.106502464@linutronix.de Signed-off-by: Greg Kroah-Hartman commit caece2c8d7827154d9e55c42c951f1d54a7a67c3 Author: Andy Lutomirski Date: Tue Feb 9 18:33:33 2021 -0800 x86/fault: Fix AMD erratum #91 errata fixup for user code commit 35f1c89b0cce247bf0213df243ed902989b1dcda upstream. The recent rework of probe_kernel_address() and its conversion to get_kernel_nofault() inadvertently broke is_prefetch(). Before this change, probe_kernel_address() was used as a sloppy "read user or kernel memory" helper, but it doesn't do that any more. The new get_kernel_nofault() reads *kernel* memory only, which completely broke is_prefetch() for user access. Adjust the code to the correct accessor based on access mode. The manual address bounds check is no longer necessary, since the accessor helpers (get_user() / get_kernel_nofault()) do the right thing all by themselves. As a bonus, by using the correct accessor, the open-coded address bounds check is not needed anymore. [ bp: Massage commit message. ] Fixes: eab0c6089b68 ("maccess: unify the probe kernel arch hooks") Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Reviewed-by: Christoph Hellwig Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/b91f7f92f3367d2d3a88eec3b09c6aab1b2dc8ef.1612924255.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit d77cfb50ff0ac544f877991ad28e3e29f3a61487 Author: Sean Christopherson Date: Wed Dec 30 16:26:55 2020 -0800 x86/reboot: Force all cpus to exit VMX root if VMX is supported commit ed72736183c45a413a8d6974dd04be90f514cb6b upstream. Force all CPUs to do VMXOFF (via NMI shootdown) during an emergency reboot if VMX is _supported_, as VMX being off on the current CPU does not prevent other CPUs from being in VMX root (post-VMXON). This fixes a bug where a crash/panic reboot could leave other CPUs in VMX root and prevent them from being woken via INIT-SIPI-SIPI in the new kernel. Fixes: d176720d34c7 ("x86: disable VMX on all CPUs on reboot") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: David P. Reed [sean: reworked changelog and further tweaked comment] Signed-off-by: Sean Christopherson Message-Id: <20201231002702.2223707-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bc0c95d5843fb72d28fa629897a08950affac198 Author: Sean Christopherson Date: Wed Dec 30 16:26:54 2020 -0800 x86/virt: Eat faults on VMXOFF in reboot flows commit aec511ad153556640fb1de38bfe00c69464f997f upstream. Silently ignore all faults on VMXOFF in the reboot flows as such faults are all but guaranteed to be due to the CPU not being in VMX root. Because (a) VMXOFF may be executed in NMI context, e.g. after VMXOFF but before CR4.VMXE is cleared, (b) there's no way to query the CPU's VMX state without faulting, and (c) the whole point is to get out of VMX root, eating faults is the simplest way to achieve the desired behaior. Technically, VMXOFF can fault (or fail) for other reasons, but all other fault and failure scenarios are mode related, i.e. the kernel would have to magically end up in RM, V86, compat mode, at CPL>0, or running with the SMI Transfer Monitor active. The kernel is beyond hosed if any of those scenarios are encountered; trying to do something fancy in the error path to handle them cleanly is pointless. Fixes: 1e9931146c74 ("x86: asm/virtext.h: add cpu_vmxoff() inline function") Reported-by: David P. Reed Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20201231002702.2223707-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b0de4140008fae3e9eb4f299d1d1858aeb895e3a Author: Sean Young Date: Fri Jan 29 11:54:53 2021 +0100 media: smipcie: fix interrupt handling and IR timeout commit 6532923237b427ed30cc7b4486f6f1ccdee3c647 upstream. After the first IR message, interrupts are no longer received. In addition, the code generates a timeout IR message of 10ms but sets the timeout value to 100ms, so no timeout was ever generated. Link: https://bugzilla.kernel.org/show_bug.cgi?id=204317 Fixes: a49a7a4635de ("media: smipcie: add universal ir capability") Tested-by: Laz Lev Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3932cb2105dcc450b8827d21c1d1ab7bbcd2a58f Author: Lubomir Rintel Date: Wed Jan 27 19:01:43 2021 +0100 media: marvell-ccic: power up the device on mclk enable commit 655ae29da72a693cf294bba3c3322e662ff75bd3 upstream. Writing to REG_CLKCTRL with the power off causes a hang. Enable the device first. Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Lubomir Rintel Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1eeeee77678105d94b6f1c675473830e2e4a3be5 Author: Pavel Machek Date: Wed Dec 30 13:55:50 2020 +0100 media: ipu3-cio2: Fix mbus_code processing in cio2_subdev_set_fmt() commit 334de4b45892f7e67074e1b1b2ac36fd3e091118 upstream. Loop was useless as it would always exit on the first iteration. Fix it with right condition. Signed-off-by: Pavel Machek (CIP) Fixes: a86cf9b29e8b ("media: ipu3-cio2: Validate mbus format in setting subdev format") Tested-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Cc: stable@vger.kernel.org # v4.16 and up Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3468c69ad8425f4b6097c16f31da434b5668fb02 Author: Sean Young Date: Sun Dec 27 14:45:01 2020 +0100 media: ir_toy: add another IR Droid device commit 4487e0215560392bd11c9de08d60824d72c89cd9 upstream. This device is also supported. Cc: stable@vger.kernel.org Tested-by: Georgi Bakalski Reported-by: Georgi Bakalski Signed-off-by: Sean Young Reviewed-by: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f2523d1008b1f5ab5aed3cf1f0c435a1cb719150 Author: Sakari Ailus Date: Sat Dec 19 23:29:58 2020 +0100 media: v4l: ioctl: Fix memory leak in video_usercopy commit fb18802a338b36f675a388fc03d2aa504a0d0899 upstream. When an IOCTL with argument size larger than 128 that also used array arguments were handled, two memory allocations were made but alas, only the latter one of them was released. This happened because there was only a single local variable to hold such a temporary allocation. Fix this by adding separate variables to hold the pointers to the temporary allocations. Reported-by: Arnd Bergmann Reported-by: syzbot+1115e79c8df6472c612b@syzkaller.appspotmail.com Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Acked-by: Arnd Bergmann Acked-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e34a775a8e83f79e2319627caead1de1618e2c74 Author: Tomi Valkeinen Date: Mon Jan 18 09:14:46 2021 +0100 media: i2c: max9286: fix access to unallocated memory commit e88ccf09e79cf33cac40316ba69c820d9eebc82b upstream. The asd allocated with v4l2_async_notifier_add_fwnode_subdev() must be of size max9286_asd, otherwise access to max9286_asd->source will go to unallocated memory. Fixes: 86d37bf31af6 ("media: i2c: max9286: Allocate v4l2_async_subdev dynamically") Signed-off-by: Tomi Valkeinen Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Tested-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0d4781df9b1292d453962cdab6bf1374393bc899 Author: Jiri Kosina Date: Fri Jan 22 12:13:20 2021 +0100 floppy: reintroduce O_NDELAY fix commit 8a0c014cd20516ade9654fc13b51345ec58e7be8 upstream. This issue was originally fixed in 09954bad4 ("floppy: refactor open() flags handling"). The fix as a side-effect, however, introduce issue for open(O_ACCMODE) that is being used for ioctl-only open. I wrote a fix for that, but instead of it being merged, full revert of 09954bad4 was performed, re-introducing the O_NDELAY / O_NONBLOCK issue, and it strikes again. This is a forward-port of the original fix to current codebase; the original submission had the changelog below: ==== Commit 09954bad4 ("floppy: refactor open() flags handling"), as a side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that this is being used setfdprm userspace for ioctl-only open(). Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) modes, while still keeping the original O_NDELAY bug fixed. Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2101221209060.5622@cbobk.fhfr.pm Cc: stable@vger.kernel.org Reported-by: Wim Osterholt Tested-by: Wim Osterholt Reported-and-tested-by: Kurt Garloff Fixes: 09954bad4 ("floppy: refactor open() flags handling") Fixes: f2791e7ead ("Revert "floppy: refactor open() flags handling"") Signed-off-by: Jiri Kosina Signed-off-by: Denis Efremov Signed-off-by: Greg Kroah-Hartman commit f145260583422454d84ae7c651d8fca4bd62916b Author: Martin Kaiser Date: Thu Feb 4 09:52:17 2021 +0100 staging: rtl8188eu: Add Edimax EW-7811UN V2 to device table commit 7a8d2f1908a59003e55ef8691d09efb7fbc51625 upstream. The Edimax EW-7811UN V2 uses an RTL8188EU chipset and works with this driver. Signed-off-by: Martin Kaiser Cc: stable Link: https://lore.kernel.org/r/20210204085217.9743-1-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman commit f957b8f84b907bee847b21c7428bd140e69e29c3 Author: Amey Narkhede Date: Thu Feb 11 11:08:19 2021 +0530 staging: gdm724x: Fix DMA from stack commit 7c3a0635cd008eaca9a734dc802709ee0b81cac5 upstream. Stack allocated buffers cannot be used for DMA on all architectures so allocate hci_packet buffer using kmalloc. Reviewed-by: Dan Carpenter Signed-off-by: Amey Narkhede Link: https://lore.kernel.org/r/20210211053819.34858-1-ameynarkhede03@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 953f6c202a6075af513f855f5b46f4020111f196 Author: Ilya Lipnitskiy Date: Fri Jan 29 19:45:07 2021 -0800 staging/mt7621-dma: mtk-hsdma.c->hsdma-mt7621.c commit 1f92798cbe7fe923479cff754dd06dd23d352e36 upstream. Also use KBUILD_MODNAME for module name. This driver is only used by RALINK MIPS MT7621 SoCs. Tested by building against that target using OpenWrt with Linux 5.10.10. Fixes the following error: error: the following would cause module name conflict: drivers/dma/mediatek/mtk-hsdma.ko drivers/staging/mt7621-dma/mtk-hsdma.ko Cc: stable@vger.kernel.org Cc: Masahiro Yamada Signed-off-by: Ilya Lipnitskiy Link: https://lore.kernel.org/r/20210130034507.2115280-1-ilya.lipnitskiy@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9b23d5cfb829afd880218943eacfc6dd55a92ebb Author: Dinh Nguyen Date: Thu Feb 4 14:24:33 2021 -0600 arm64: dts: agilex: fix phy interface bit shift for gmac1 and gmac2 commit b7ff3a447d100c999d9848353ef8a4046831d893 upstream. The shift for the phy_intf_sel bit in the system manager for gmac1 and gmac2 should be 0. Fixes: 2f804ba7aa9ee ("arm64: dts: agilex: Add SysMgr to Ethernet nodes") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 863481a00158e799f87164b5074729a3656c40a7 Author: Frank Wunderlich Date: Wed Jan 13 19:09:19 2021 +0100 dts64: mt7622: fix slow sd card access commit dc2e76175417e69c41d927dba75a966399f18354 upstream. Fix extreme slow speed (200MB takes ~20 min) on writing sdcard on bananapi-r64 by adding reset-control for mmc1 like it's done for mmc0/emmc. Fixes: 2c002a3049f7 ("arm64: dts: mt7622: add mmc related device nodes") Signed-off-by: Frank Wunderlich Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210113180919.49523-1-linux@fw-web.de Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit fd3d9ef021aec72da92e068971020b92b6053271 Author: Jiri Bohac Date: Thu Feb 18 12:15:47 2021 +0100 pstore: Fix typo in compression option name commit 19d8e9149c27b689c6224f5c84b96a159342195a upstream. Both pstore_compress() and decompress_record() use a mistyped config option name ("PSTORE_COMPRESSION" instead of "PSTORE_COMPRESS"). As a result compression and decompression of pstore records was always disabled. Use the correct config option name. Signed-off-by: Jiri Bohac Fixes: fd49e03280e5 ("pstore: Fix linking when crypto API disabled") Acked-by: Matteo Croce Signed-off-by: Kees Cook Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210218111547.johvp5klpv3xrpnn@dwarf.suse.cz Signed-off-by: Greg Kroah-Hartman commit 2ebad25fa27eb4da6c0f58479cd5a73754d58312 Author: Sabyrzhan Tasbolatov Date: Tue Feb 9 16:26:12 2021 +0600 drivers/misc/vmw_vmci: restrict too big queue size in qp_host_alloc_queue commit 2fd10bcf0310b9525b2af9e1f7aa9ddd87c3772e upstream. syzbot found WARNING in qp_broker_alloc[1] in qp_host_alloc_queue() when num_pages is 0x100001, giving queue_size + queue_page_size bigger than KMALLOC_MAX_SIZE for kzalloc(), resulting order >= MAX_ORDER condition. queue_size + queue_page_size=0x8000d8, where KMALLOC_MAX_SIZE=0x400000. [1] Call Trace: alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x40/0x130 mm/slab_common.c:837 kmalloc_order_trace+0x15/0x70 mm/slab_common.c:853 kmalloc_large include/linux/slab.h:481 [inline] __kmalloc+0x257/0x330 mm/slub.c:3959 kmalloc include/linux/slab.h:557 [inline] kzalloc include/linux/slab.h:682 [inline] qp_host_alloc_queue drivers/misc/vmw_vmci/vmci_queue_pair.c:540 [inline] qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline] qp_broker_alloc+0x936/0x2740 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739 Reported-by: syzbot+15ec7391f3d6a1a7cc7d@syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov Link: https://lore.kernel.org/r/20210209102612.2112247-1-snovitoll@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit d1d3fa5c0dc5404659311a24a46f4cac13a176d9 Author: Ricky Wu Date: Thu Feb 4 16:31:15 2021 +0800 misc: rtsx: init of rts522a add OCP power off when no card is present commit 920fd8a70619074eac7687352c8f1c6f3c2a64a5 upstream. Power down OCP for power consumption when no SD/MMC card is present Cc: stable@vger.kernel.org Signed-off-by: Ricky Wu Link: https://lore.kernel.org/r/20210204083115.9471-1-ricky_wu@realtek.com Signed-off-by: Greg Kroah-Hartman commit 77a9d8f7799c1a5f845d13d162fd923e6b6d81e0 Author: Timothy E Baldwin Date: Sat Jan 16 15:18:54 2021 +0000 arm64: ptrace: Fix seccomp of traced syscall -1 (NO_SYSCALL) commit df84fe94708985cdfb78a83148322bcd0a699472 upstream. Since commit f086f67485c5 ("arm64: ptrace: add support for syscall emulation"), if system call number -1 is called and the process is being traced with PTRACE_SYSCALL, for example by strace, the seccomp check is skipped and -ENOSYS is returned unconditionally (unless altered by the tracer) rather than carrying out action specified in the seccomp filter. The consequence of this is that it is not possible to reliably strace a seccomp based implementation of a foreign system call interface in which r7/x8 is permitted to be -1 on entry to a system call. Also trace_sys_enter and audit_syscall_entry are skipped if a system call is skipped. Fix by removing the in_syscall(regs) check restoring the previous behaviour which is like AArch32, x86 (which uses generic code) and everything else. Cc: Oleg Nesterov Cc: Catalin Marinas Cc: Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation") Reviewed-by: Kees Cook Reviewed-by: Sudeep Holla Tested-by: Sudeep Holla Signed-off-by: Timothy E Baldwin Link: https://lore.kernel.org/r/90edd33b-6353-1228-791f-0336d94d5f8c@majoroak.me.uk Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 2f24823495d676692635dac2bdbab5dbca18ce33 Author: Paul Cercueil Date: Mon Jan 11 17:28:39 2021 +0000 seccomp: Add missing return in non-void function commit 04b38d012556199ba4c31195940160e0c44c64f0 upstream. We don't actually care about the value, since the kernel will panic before that; but a value should nonetheless be returned, otherwise the compiler will complain. Fixes: 8112c4f140fa ("seccomp: remove 2-phase API") Cc: stable@vger.kernel.org # 4.7+ Signed-off-by: Paul Cercueil Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210111172839.640914-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit 9ad39d6f49b601d0eafd8b5371f2c9c03c77aaf7 Author: Krzysztof Kozlowski Date: Mon Dec 7 20:05:15 2020 +0100 soc: samsung: exynos-asv: handle reading revision register error commit 4561560dfb4f847a0b327d48bdd1f45bf1b6261f upstream. If regmap_read() fails, the product_id local variable will contain random value from the stack. Do not try to parse such value and fail the ASV driver probe. Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Pankaj Dubey Link: https://lore.kernel.org/r/20201207190517.262051-3-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman commit fb4f745bf82818f94d20958950dbf0d384ac1bf5 Author: Marek Szyprowski Date: Mon Dec 7 20:05:14 2020 +0100 soc: samsung: exynos-asv: don't defer early on not-supported SoCs commit 0458b88267c637fb872b0359da9ff0b243081e9e upstream. Check if the SoC is really supported before gathering the needed resources. This fixes endless deferred probe on some SoCs other than Exynos5422 (like Exynos5410). Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver") Cc: Signed-off-by: Marek Szyprowski Reviewed-by: Pankaj Dubey Link: https://lore.kernel.org/r/20201207190517.262051-2-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 7f422fb5dfdeb8b38efc5830a01989b0675cf858 Author: Corentin Labbe Date: Mon Dec 14 20:02:29 2020 +0000 crypto: sun4i-ss - initialize need_fallback commit 4ec8977b921fd9d512701e009ce8082cb94b5c1c upstream. The need_fallback is never initialized and seem to be always true at runtime. So all hardware operations are always bypassed. Fixes: 0ae1f46c55f87 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize") Cc: Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1cdfb5b2cbad10683c0dfd5d3dce206e56445677 Author: Corentin Labbe Date: Mon Dec 14 20:02:28 2020 +0000 crypto: sun4i-ss - handle BigEndian for cipher commit 5ab6177fa02df15cd8a02a1f1fb361d2d5d8b946 upstream. Ciphers produce invalid results on BE. Key and IV need to be written in LE. Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Cc: Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9edf12a9e50c2314fb1c9a14d4efaca52a9579db Author: Corentin Labbe Date: Mon Dec 14 20:02:27 2020 +0000 crypto: sun4i-ss - IV register does not work on A10 and A13 commit b756f1c8fc9d84e3f546d7ffe056c5352f4aab05 upstream. Allwinner A10 and A13 SoC have a version of the SS which produce invalid IV in IVx register. Instead of adding a variant for those, let's convert SS to produce IV directly from data. Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Cc: Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4e8df5f65a23c952cc32f4efab2a11db8eade552 Author: Corentin Labbe Date: Mon Dec 14 20:02:26 2020 +0000 crypto: sun4i-ss - checking sg length is not sufficient commit 7bdcd851fa7eb66e8922aa7f6cba9e2f2427a7cf upstream. The optimized cipher function need length multiple of 4 bytes. But it get sometimes odd length. This is due to SG data could be stored with an offset. So the fix is to check also if the offset is aligned with 4 bytes. Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Cc: Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit dfa392f28473f888de8fcb6fdd21e4e7d9518587 Author: Ard Biesheuvel Date: Mon Feb 1 19:02:29 2021 +0100 crypto: michael_mic - fix broken misalignment handling commit e1b2d980f03b833442768c1987d5ad0b9a58cfe7 upstream. The Michael MIC driver uses the cra_alignmask to ensure that pointers presented to its update and finup/final methods are 32-bit aligned. However, due to the way the shash API works, this is no guarantee that the 32-bit reads occurring in the update method are also aligned, as the size of the buffer presented to update may be of uneven length. For instance, an update() of 3 bytes followed by a misaligned update() of 4 or more bytes will result in a misaligned access using an accessor that is not suitable for this. On most architectures, this does not matter, and so setting the cra_alignmask is pointless. On architectures where this does matter, setting the cra_alignmask does not actually solve the problem. So let's get rid of the cra_alignmask, and use unaligned accessors instead, where appropriate. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a3edcdb363c4c2a08f0d0c7cc8a8c2d4c608b347 Author: Ard Biesheuvel Date: Mon Jan 4 16:55:46 2021 +0100 crypto: aesni - prevent misaligned buffers on the stack commit a13ed1d15b07a04b1f74b2df61ff7a5e47f45dd8 upstream. The GCM mode driver uses 16 byte aligned buffers on the stack to pass the IV to the asm helpers, but unfortunately, the x86 port does not guarantee that the stack pointer is 16 byte aligned upon entry in the first place. Since the compiler is not aware of this, it will not emit the additional stack realignment sequence that is needed, and so the alignment is not guaranteed to be more than 8 bytes. So instead, allocate some padding on the stack, and realign the IV pointer by hand. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 89222033fe3d17429c5a1359212d3d55216a54eb Author: Ard Biesheuvel Date: Thu Jan 14 19:10:10 2021 +0100 crypto: arm64/sha - add missing module aliases commit 0df07d8117c3576f1603b05b84089742a118d10a upstream. The accelerated, instruction based implementations of SHA1, SHA2 and SHA3 are autoloaded based on CPU capabilities, given that the code is modest in size, and widely used, which means that resolving the algo name, loading all compatible modules and picking the one with the highest priority is taken to be suboptimal. However, if these algorithms are requested before this CPU feature based matching and autoloading occurs, these modules are not even considered, and we end up with suboptimal performance. So add the missing module aliases for the various SHA implementations. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 261c496212922b366a43ba36725443ebe179c06d Author: Chris Wilson Date: Wed Feb 10 12:27:28 2021 +0000 drm/i915/gt: Correct surface base address for renderclear commit 81ce8f04aa96f7f6cae05770f68b5d15be91f5a2 upstream. The surface_state_base is an offset into the batch, so we need to pass the correct batch address for STATE_BASE_ADDRESS. Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Prathap Kumar Valsan Cc: Akeem G Abodunrin Cc: Hans de Goede Cc: Hans de Goede Reviewed-by: Mika Kuoppala Cc: # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20210210122728.20097-1-chris@chris-wilson.co.uk (cherry picked from commit 1914911f4aa08ddc05bae71d3516419463e0c567) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 0e10796bdaf10fcc5e050a1af61b2a6edfbe1cd2 Author: Chris Wilson Date: Mon Jan 25 22:02:47 2021 +0000 drm/i915/gt: Flush before changing register state commit d5109f739c9f14a3bda249cb48b16de1065932f0 upstream. Flush; invalidate; change registers; invalidate; flush. Will this finally work on every device? Or will Baytrail complain again? On the positive side, we immediately see the benefit of having hsw-gt1 in CI. Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") Testcase: igt/gem_render_tiled_blits # hsw-gt1 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Akeem G Abodunrin Acked-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20210125220247.31701-1-chris@chris-wilson.co.uk (cherry picked from commit d30bbd62b1bfd9e0a33c3583c5a9e5d66f60cbd7) Signed-off-by: Rodrigo Vivi Cc: Diego Calleja Cc: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 0f07295392362bf11bfe7a7f50c3af4f28eaab74 Author: Filipe Manana Date: Thu Feb 4 14:35:44 2021 +0000 btrfs: fix extent buffer leak on failure to copy root commit 72c9925f87c8b74f36f8e75a4cd93d964538d3ca upstream. At btrfs_copy_root(), if the call to btrfs_inc_ref() fails we end up returning without unlocking and releasing our reference on the extent buffer named "cow" we previously allocated with btrfs_alloc_tree_block(). So fix that by unlocking the extent buffer and dropping our reference on it before returning. Fixes: be20aa9dbadc8c ("Btrfs: Add mount option to turn off data cow") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b1fcfe1d09f4582e8b876276a447072ae361d03a Author: Josef Bacik Date: Fri Jan 15 16:48:56 2021 -0500 btrfs: account for new extents being deleted in total_bytes_pinned commit 81e75ac74ecba929d1e922bf93f9fc467232e39f upstream. My recent patch set "A variety of lock contention fixes", found here https://lore.kernel.org/linux-btrfs/cover.1608319304.git.josef@toxicpanda.com/ (Tracked in https://github.com/btrfs/linux/issues/86) that reduce lock contention on the extent root by running delayed refs less often resulted in a regression in generic/371. This test fallocate()'s the fs until it's full, deletes all the files, and then tries to fallocate() until full again. Before these patches we would run all of the delayed refs during flushing, and then would commit the transaction because we had plenty of pinned space to recover in order to allocate. However my patches made it so we weren't running the delayed refs as aggressively, which meant that we appeared to have less pinned space when we were deciding to commit the transaction. We use the space_info->total_bytes_pinned to approximate how much space we have pinned. It's approximate because if we remove a reference to an extent we may free it, but there may be more references to it than we know of at that point, but we account it as pinned at the creation time, and then it's properly accounted when the delayed ref runs. The way we account for pinned space is if the delayed_ref_head->total_ref_mod is < 0, because that is clearly a freeing option. However there is another case, and that is where ->total_ref_mod == 0 && ->must_insert_reserved == 1. When we allocate a new extent, we have ->total_ref_mod == 1 and we have ->must_insert_reserved == 1. This is used to indicate that it is a brand new extent and will need to have its extent entry added before we modify any references on the delayed ref head. But if we subsequently remove that extent reference, our ->total_ref_mod will be 0, and that space will be pinned and freed. Accounting for this case properly allows for generic/371 to pass with my delayed refs patches applied. It's important to note that this problem exists without the referenced patches, it just was uncovered by them. CC: stable@vger.kernel.org # 5.10 Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 70247ec4b6787477bc40e47db06bb69e3ebb0e67 Author: Josef Bacik Date: Fri Jan 15 16:48:55 2021 -0500 btrfs: handle space_info::total_bytes_pinned inside the delayed ref itself commit 2187374f35fe9cadbddaa9fcf0c4121365d914e8 upstream. Currently we pass things around to figure out if we maybe freeing data based on the state of the delayed refs head. This makes the accounting sort of confusing and hard to follow, as it's distinctly separate from the delayed ref heads stuff, but also depends on it entirely. Fix this by explicitly adjusting the space_info->total_bytes_pinned in the delayed refs code. We now have two places where we modify this counter, once where we create the delayed and destroy the delayed refs, and once when we pin and unpin the extents. This means there is a slight overlap between delayed refs and the pin/unpin mechanisms, but this is simply used by the ENOSPC infrastructure to determine if we need to commit the transaction, so there's no adverse affect from this, we might simply commit thinking it will give us enough space when it might not. CC: stable@vger.kernel.org # 5.10 Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5f2a7af248d5fddd602c0acfe6b26910337d4966 Author: Josef Bacik Date: Thu Jan 14 14:02:43 2021 -0500 btrfs: splice remaining dirty_bg's onto the transaction dirty bg list commit 938fcbfb0cbcf532a1869efab58e6009446b1ced upstream. While doing error injection testing with my relocation patches I hit the following assert: assertion failed: list_empty(&block_group->dirty_list), in fs/btrfs/block-group.c:3356 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.h:3357! invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 PID: 24351 Comm: umount Tainted: G W 5.10.0-rc3+ #193 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:assertfail.constprop.0+0x18/0x1a RSP: 0018:ffffa09b019c7e00 EFLAGS: 00010282 RAX: 0000000000000056 RBX: ffff8f6492c18000 RCX: 0000000000000000 RDX: ffff8f64fbc27c60 RSI: ffff8f64fbc19050 RDI: ffff8f64fbc19050 RBP: ffff8f6483bbdc00 R08: 0000000000000000 R09: 0000000000000000 R10: ffffa09b019c7c38 R11: ffffffff85d70928 R12: ffff8f6492c18100 R13: ffff8f6492c18148 R14: ffff8f6483bbdd70 R15: dead000000000100 FS: 00007fbfda4cdc40(0000) GS:ffff8f64fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbfda666fd0 CR3: 000000013cf66002 CR4: 0000000000370ef0 Call Trace: btrfs_free_block_groups.cold+0x55/0x55 close_ctree+0x2c5/0x306 ? fsnotify_destroy_marks+0x14/0x100 generic_shutdown_super+0x6c/0x100 kill_anon_super+0x14/0x30 btrfs_kill_super+0x12/0x20 deactivate_locked_super+0x36/0xa0 cleanup_mnt+0x12d/0x190 task_work_run+0x5c/0xa0 exit_to_user_mode_prepare+0x1b1/0x1d0 syscall_exit_to_user_mode+0x54/0x280 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This happened because I injected an error in btrfs_cow_block() while running the dirty block groups. When we run the dirty block groups, we splice the list onto a local list to process. However if an error occurs, we only cleanup the transactions dirty block group list, not any pending block groups we have on our locally spliced list. In fact if we fail to allocate a path in this function we'll also fail to clean up the splice list. Fix this by splicing the list back onto the transaction dirty block group list so that the block groups are cleaned up. Then add a 'out' label and have the error conditions jump to out so that the errors are handled properly. This also has the side-effect of fixing a problem where we would clear 'ret' on error because we unconditionally ran btrfs_run_delayed_refs(). CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 3152f202cf519c90155c7b118549c652457c3b9d Author: Josef Bacik Date: Thu Jan 14 14:02:42 2021 -0500 btrfs: fix reloc root leak with 0 ref reloc roots on recovery commit c78a10aebb275c38d0cfccae129a803fe622e305 upstream. When recovering a relocation, if we run into a reloc root that has 0 refs we simply add it to the reloc_control->reloc_roots list, and then clean it up later. The problem with this is __del_reloc_root() doesn't do anything if the root isn't in the radix tree, which in this case it won't be because we never call __add_reloc_root() on the reloc_root. This exit condition simply isn't correct really. During normal operation we can remove ourselves from the rb tree and then we're meant to clean up later at merge_reloc_roots() time, and this happens correctly. During recovery we're depending on free_reloc_roots() to drop our references, but we're short-circuiting. Fix this by continuing to check if we're on the list and dropping ourselves from the reloc_control root list and dropping our reference appropriately. Change the corresponding BUG_ON() to an ASSERT() that does the correct thing if we aren't in the rb tree. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c244578c1bac10baf8b0847226a2e3056e52d770 Author: Josef Bacik Date: Thu Jan 14 14:02:46 2021 -0500 btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root commit 867ed321f90d06aaba84e2c91de51cd3038825ef upstream. While testing my error handling patches, I added a error injection site at btrfs_inc_extent_ref, to validate the error handling I added was doing the correct thing. However I hit a pretty ugly corruption while doing this check, with the following error injection stack trace: btrfs_inc_extent_ref btrfs_copy_root create_reloc_root btrfs_init_reloc_root btrfs_record_root_in_trans btrfs_start_transaction btrfs_update_inode btrfs_update_time touch_atime file_accessed btrfs_file_mmap This is because we do not catch the error from btrfs_inc_extent_ref, which in practice would be ENOMEM, which means we lose the extent references for a root that has already been allocated and inserted, which is the problem. Fix this by aborting the transaction if we fail to do the reference modification. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 04f02eb11431cf10c63a00223ebc584c46728164 Author: Josef Bacik Date: Thu Jan 14 14:02:45 2021 -0500 btrfs: add asserts for deleting backref cache nodes commit eddda68d97732ce05ca145f8e85e8a447f65cdad upstream. A weird KASAN problem that Zygo reported could have been easily caught if we checked for basic things in our backref freeing code. We have two methods of freeing a backref node - btrfs_backref_free_node: this just is kfree() essentially. - btrfs_backref_drop_node: this actually unlinks the node and cleans up everything and then calls btrfs_backref_free_node(). We should mostly be using btrfs_backref_drop_node(), to make sure the node is properly unlinked from the backref cache, and only use btrfs_backref_free_node() when we know the node isn't actually linked to the backref cache. We made a mistake here and thus got the KASAN splat. Make this style of issue easier to find by adding some ASSERT()'s to btrfs_backref_free_node() and adjusting our deletion stuff to properly init the list so we can rely on list_empty() checks working properly. BUG: KASAN: use-after-free in btrfs_backref_cleanup_node+0x18a/0x420 Read of size 8 at addr ffff888112402950 by task btrfs/28836 CPU: 0 PID: 28836 Comm: btrfs Tainted: G W 5.10.0-e35f27394290-for-next+ #23 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: dump_stack+0xbc/0xf9 ? btrfs_backref_cleanup_node+0x18a/0x420 print_address_description.constprop.8+0x21/0x210 ? record_print_text.cold.34+0x11/0x11 ? btrfs_backref_cleanup_node+0x18a/0x420 ? btrfs_backref_cleanup_node+0x18a/0x420 kasan_report.cold.10+0x20/0x37 ? btrfs_backref_cleanup_node+0x18a/0x420 __asan_load8+0x69/0x90 btrfs_backref_cleanup_node+0x18a/0x420 btrfs_backref_release_cache+0x83/0x1b0 relocate_block_group+0x394/0x780 ? merge_reloc_roots+0x4a0/0x4a0 btrfs_relocate_block_group+0x26e/0x4c0 btrfs_relocate_chunk+0x52/0x120 btrfs_balance+0xe2e/0x1900 ? check_flags.part.50+0x6c/0x1e0 ? btrfs_relocate_chunk+0x120/0x120 ? kmem_cache_alloc_trace+0xa06/0xcb0 ? _copy_from_user+0x83/0xc0 btrfs_ioctl_balance+0x3a7/0x460 btrfs_ioctl+0x24c8/0x4360 ? __kasan_check_read+0x11/0x20 ? check_chain_key+0x1f4/0x2f0 ? __asan_loadN+0xf/0x20 ? btrfs_ioctl_get_supported_features+0x30/0x30 ? kvm_sched_clock_read+0x18/0x30 ? check_chain_key+0x1f4/0x2f0 ? lock_downgrade+0x3f0/0x3f0 ? handle_mm_fault+0xad6/0x2150 ? do_vfs_ioctl+0xfc/0x9d0 ? ioctl_file_clone+0xe0/0xe0 ? check_flags.part.50+0x6c/0x1e0 ? check_flags.part.50+0x6c/0x1e0 ? check_flags+0x26/0x30 ? lock_is_held_type+0xc3/0xf0 ? syscall_enter_from_user_mode+0x1b/0x60 ? do_syscall_64+0x13/0x80 ? rcu_read_lock_sched_held+0xa1/0xd0 ? __kasan_check_read+0x11/0x20 ? __fget_light+0xae/0x110 __x64_sys_ioctl+0xc3/0x100 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f4c4bdfe427 RSP: 002b:00007fff33ee6df8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fff33ee6e98 RCX: 00007f4c4bdfe427 RDX: 00007fff33ee6e98 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000078 R10: fffffffffffff59d R11: 0000000000000202 R12: 0000000000000001 R13: 0000000000000000 R14: 00007fff33ee8a34 R15: 0000000000000001 Allocated by task 28836: kasan_save_stack+0x21/0x50 __kasan_kmalloc.constprop.18+0xbe/0xd0 kasan_kmalloc+0x9/0x10 kmem_cache_alloc_trace+0x410/0xcb0 btrfs_backref_alloc_node+0x46/0xf0 btrfs_backref_add_tree_node+0x60d/0x11d0 build_backref_tree+0xc5/0x700 relocate_tree_blocks+0x2be/0xb90 relocate_block_group+0x2eb/0x780 btrfs_relocate_block_group+0x26e/0x4c0 btrfs_relocate_chunk+0x52/0x120 btrfs_balance+0xe2e/0x1900 btrfs_ioctl_balance+0x3a7/0x460 btrfs_ioctl+0x24c8/0x4360 __x64_sys_ioctl+0xc3/0x100 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 28836: kasan_save_stack+0x21/0x50 kasan_set_track+0x20/0x30 kasan_set_free_info+0x1f/0x30 __kasan_slab_free+0xf3/0x140 kasan_slab_free+0xe/0x10 kfree+0xde/0x200 btrfs_backref_error_cleanup+0x452/0x530 build_backref_tree+0x1a5/0x700 relocate_tree_blocks+0x2be/0xb90 relocate_block_group+0x2eb/0x780 btrfs_relocate_block_group+0x26e/0x4c0 btrfs_relocate_chunk+0x52/0x120 btrfs_balance+0xe2e/0x1900 btrfs_ioctl_balance+0x3a7/0x460 btrfs_ioctl+0x24c8/0x4360 __x64_sys_ioctl+0xc3/0x100 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff888112402900 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 80 bytes inside of 128-byte region [ffff888112402900, ffff888112402980) The buggy address belongs to the page: page:0000000028b1cd08 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888131c810c0 pfn:0x112402 flags: 0x17ffe0000000200(slab) raw: 017ffe0000000200 ffffea000424f308 ffffea0007d572c8 ffff888100040440 raw: ffff888131c810c0 ffff888112402000 0000000100000009 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888112402800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888112402880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888112402900: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888112402980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888112402a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Link: https://lore.kernel.org/linux-btrfs/20201208194607.GI31381@hungrycats.org/ CC: stable@vger.kernel.org # 5.10+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 194a9976c05de32597fdc3fd444b3bb56306c698 Author: Josef Bacik Date: Thu Jan 14 14:02:44 2021 -0500 btrfs: do not warn if we can't find the reloc root when looking up backref commit f78743fbdae1bb31bc9c9233c3590a5048782381 upstream. The backref code is looking for a reloc_root that corresponds to the given fs root. However any number of things could have gone wrong while initializing that reloc_root, like ENOMEM while trying to allocate the root itself, or EIO while trying to write the root item. This would result in no corresponding reloc_root being in the reloc root cache, and thus would return NULL when we do the find_reloc_root() call. Because of this we do not want to WARN_ON(). This presumably was meant to catch developer errors, cases where we messed up adding the reloc root. However we can easily hit this case with error injection, and thus should not do a WARN_ON(). CC: stable@vger.kernel.org # 5.10+ Reported-by: Zygo Blaxell Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6694c18f3c92542b1f292800ff9af9987002ac58 Author: Josef Bacik Date: Wed Dec 16 11:22:16 2020 -0500 btrfs: do not cleanup upper nodes in btrfs_backref_cleanup_node commit 7e2a870a599d4699a626ec26430c7a1ab14a2a49 upstream. Zygo reported the following panic when testing my error handling patches for relocation: kernel BUG at fs/btrfs/backref.c:2545! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 3 PID: 8472 Comm: btrfs Tainted: G W 14 Hardware name: QEMU Standard PC (i440FX + PIIX, Call Trace: btrfs_backref_error_cleanup+0x4df/0x530 build_backref_tree+0x1a5/0x700 ? _raw_spin_unlock+0x22/0x30 ? release_extent_buffer+0x225/0x280 ? free_extent_buffer.part.52+0xd7/0x140 relocate_tree_blocks+0x2a6/0xb60 ? kasan_unpoison_shadow+0x35/0x50 ? do_relocation+0xc10/0xc10 ? kasan_kmalloc+0x9/0x10 ? kmem_cache_alloc_trace+0x6a3/0xcb0 ? free_extent_buffer.part.52+0xd7/0x140 ? rb_insert_color+0x342/0x360 ? add_tree_block.isra.36+0x236/0x2b0 relocate_block_group+0x2eb/0x780 ? merge_reloc_roots+0x470/0x470 btrfs_relocate_block_group+0x26e/0x4c0 btrfs_relocate_chunk+0x52/0x120 btrfs_balance+0xe2e/0x18f0 ? pvclock_clocksource_read+0xeb/0x190 ? btrfs_relocate_chunk+0x120/0x120 ? lock_contended+0x620/0x6e0 ? do_raw_spin_lock+0x1e0/0x1e0 ? do_raw_spin_unlock+0xa8/0x140 btrfs_ioctl_balance+0x1f9/0x460 btrfs_ioctl+0x24c8/0x4380 ? __kasan_check_read+0x11/0x20 ? check_chain_key+0x1f4/0x2f0 ? __asan_loadN+0xf/0x20 ? btrfs_ioctl_get_supported_features+0x30/0x30 ? kvm_sched_clock_read+0x18/0x30 ? check_chain_key+0x1f4/0x2f0 ? lock_downgrade+0x3f0/0x3f0 ? handle_mm_fault+0xad6/0x2150 ? do_vfs_ioctl+0xfc/0x9d0 ? ioctl_file_clone+0xe0/0xe0 ? check_flags.part.50+0x6c/0x1e0 ? check_flags.part.50+0x6c/0x1e0 ? check_flags+0x26/0x30 ? lock_is_held_type+0xc3/0xf0 ? syscall_enter_from_user_mode+0x1b/0x60 ? do_syscall_64+0x13/0x80 ? rcu_read_lock_sched_held+0xa1/0xd0 ? __kasan_check_read+0x11/0x20 ? __fget_light+0xae/0x110 __x64_sys_ioctl+0xc3/0x100 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This occurs because of this check if (RB_EMPTY_NODE(&upper->rb_node)) BUG_ON(!list_empty(&node->upper)); As we are dropping the backref node, if we discover that our upper node in the edge we just cleaned up isn't linked into the cache that we are now done with this node, thus the BUG_ON(). However this is an erroneous assumption, as we will look up all the references for a node first, and then process the pending edges. All of the 'upper' nodes in our pending edges won't be in the cache's rb_tree yet, because they haven't been processed. We could very well have many edges still left to cleanup on this node. The fact is we simply do not need this check, we can just process all of the edges only for this node, because below this check we do the following if (list_empty(&upper->lower)) { list_add_tail(&upper->lower, &cache->leaves); upper->lowest = 1; } If the upper node truly isn't used yet, then we add it to the cache->leaves list to be cleaned up later. If it is still used then the last child node that has it linked into its node will add it to the leaves list and then it will be cleaned up. Fix this problem by dropping this logic altogether. With this fix I no longer see the panic when testing with error injection in the backref code. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 498b8fc1cdc13b57b02dd28544b18323900fae10 Author: Jarkko Sakkinen Date: Fri Jan 29 01:56:21 2021 +0200 KEYS: trusted: Reserve TPM for seal and unseal operations commit 8c657a0590de585b1115847c17b34a58025f2f4b upstream. When TPM 2.0 trusted keys code was moved to the trusted keys subsystem, the operations were unwrapped from tpm_try_get_ops() and tpm_put_ops(), which are used to take temporarily the ownership of the TPM chip. The ownership is only taken inside tpm_send(), but this is not sufficient, as in the key load TPM2_CC_LOAD, TPM2_CC_UNSEAL and TPM2_FLUSH_CONTEXT need to be done as a one single atom. Take the TPM chip ownership before sending anything with tpm_try_get_ops() and tpm_put_ops(), and use tpm_transmit_cmd() to send TPM commands instead of tpm_send(), reverting back to the old behaviour. Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code") Reported-by: "James E.J. Bottomley" Cc: stable@vger.kernel.org Cc: David Howells Cc: Mimi Zohar Cc: Sumit Garg Acked-by Sumit Garg Tested-by: Mimi Zohar Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit f5166d96f192e3433fb3f06ad0924883552e2938 Author: Jarkko Sakkinen Date: Fri Jan 29 01:56:20 2021 +0200 KEYS: trusted: Fix migratable=1 failing commit 8da7520c80468c48f981f0b81fc1be6599e3b0ad upstream. Consider the following transcript: $ keyctl add trusted kmk "new 32 blobauth=helloworld keyhandle=80000000 migratable=1" @u add_key: Invalid argument The documentation has the following description: migratable= 0|1 indicating permission to reseal to new PCR values, default 1 (resealing allowed) The consequence is that "migratable=1" should succeed. Fix this by allowing this condition to pass instead of return -EINVAL. [*] Documentation/security/keys/trusted-encrypted.rst Cc: stable@vger.kernel.org Cc: "James E.J. Bottomley" Cc: Mimi Zohar Cc: David Howells Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 8cfc8d62942105e5df4a20a15b24da077a6b24ef Author: Jarkko Sakkinen Date: Fri Jan 29 01:56:19 2021 +0200 KEYS: trusted: Fix incorrect handling of tpm_get_random() commit 5df16caada3fba3b21cb09b85cdedf99507f4ec1 upstream. When tpm_get_random() was introduced, it defined the following API for the return value: 1. A positive value tells how many bytes of random data was generated. 2. A negative value on error. However, in the call sites the API was used incorrectly, i.e. as it would only return negative values and otherwise zero. Returning he positive read counts to the user space does not make any possible sense. Fix this by returning -EIO when tpm_get_random() returns a positive value. Fixes: 41ab999c80f1 ("tpm: Move tpm_get_random api into the TPM device driver") Cc: stable@vger.kernel.org Cc: Mimi Zohar Cc: "James E.J. Bottomley" Cc: David Howells Cc: Kent Yoder Signed-off-by: Jarkko Sakkinen Reviewed-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 58f0178ac642f9d43fa0c3c0e7ab867aa30bb66e Author: James Bottomley Date: Thu Oct 1 11:09:22 2020 -0700 tpm_tis: Clean up locality release commit e42acf104d6e0bd7ccd2f09103d5be5e6d3c637c upstream. The current release locality code seems to be based on the misunderstanding that the TPM interrupts when a locality is released: it doesn't, only when the locality is acquired. Furthermore, there seems to be no point in waiting for the locality to be released. All it does is penalize the last TPM user. However, if there's no next TPM user, this is a pointless wait and if there is a next TPM user, they'll pay the penalty waiting for the new locality (or possibly not if it's the same as the old locality). Fix the code by making release_locality as simple write to release with no waiting for completion. Cc: stable@ger.kernel.org Fixes: 33bafe90824b ("tpm_tis: verify locality released before returning from release_locality") Signed-off-by: James Bottomley Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit e544ee4364054e15a8c39cee8de2173692bb3f2a Author: James Bottomley Date: Thu Oct 1 11:09:21 2020 -0700 tpm_tis: Fix check_locality for correct locality acquisition commit 3d9ae54af1d02a7c0edc55c77d7df2b921e58a87 upstream. The TPM TIS specification says the TPM signals the acquisition of locality when the TMP_ACCESS_REQUEST_USE bit goes to one *and* the TPM_ACCESS_REQUEST_USE bit goes to zero. Currently we only check the former not the latter, so check both. Adding the check on TPM_ACCESS_REQUEST_USE should fix the case where the locality is re-requested before the TPM has released it. In this case the locality may get released briefly before it is reacquired, which causes all sorts of problems. However, with the added check, TPM_ACCESS_REQUEST_USE should remain 1 until the second request for the locality is granted. Cc: stable@ger.kernel.org Fixes: 27084efee0c3 ("[PATCH] tpm: driver for next generation TPM chips") Signed-off-by: James Bottomley Reviewed-by: Jerry Snitselaar Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 54e4d19c230d40744cc1ef891717d4b7cdf6527e Author: Gao Xiang Date: Tue Feb 9 21:06:18 2021 +0800 erofs: initialized fields can only be observed after bit is set commit ce063129181312f8781a047a50be439c5859747b upstream. Currently, although set_bit() & test_bit() pairs are used as a fast- path for initialized configurations. However, these atomic ops are actually relaxed forms. Instead, load-acquire & store-release form is needed to make sure uninitialized fields won't be observed in advance here (yet no such corresponding bitops so use full barriers instead.) Link: https://lore.kernel.org/r/20210209130618.15838-1-hsiangkao@aol.com Fixes: 62dc45979f3f ("staging: erofs: fix race of initializing xattrs of a inode at the same time") Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes support") Cc: # 5.3+ Reported-by: Huang Jianan Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit bd331e1897813e475a5a4e7859ff44ac2422df9b Author: Amir Goldstein Date: Sat Dec 19 12:05:27 2020 +0200 selinux: fix inconsistency between inode_getxattr and inode_listsecurity commit a9ffe682c58aaff643764547f5420e978b6e0830 upstream. When inode has no listxattr op of its own (e.g. squashfs) vfs_listxattr calls the LSM inode_listsecurity hooks to list the xattrs that LSMs will intercept in inode_getxattr hooks. When selinux LSM is installed but not initialized, it will list the security.selinux xattr in inode_listsecurity, but will not intercept it in inode_getxattr. This results in -ENODATA for a getxattr call for an xattr returned by listxattr. This situation was manifested as overlayfs failure to copy up lower files from squashfs when selinux is built-in but not initialized, because ovl_copy_xattr() iterates the lower inode xattrs by vfs_listxattr() and vfs_getxattr(). Match the logic of inode_listsecurity to that of inode_getxattr and do not list the security.selinux xattr if selinux is not initialized. Reported-by: Michael Labriola Tested-by: Michael Labriola Link: https://lore.kernel.org/linux-unionfs/2nv9d47zt7.fsf@aldarion.sourceruckus.org/ Fixes: c8e222616c7e ("selinux: allow reading labels before policy is loaded") Cc: stable@vger.kernel.org#v5.9+ Signed-off-by: Amir Goldstein Reviewed-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 85c4d1d9c29f1417507eb801f50d8bc71c8fab61 Author: Takashi Iwai Date: Tue Jan 26 16:47:02 2021 +0100 ASoC: siu: Fix build error by a wrong const prefix commit ae07f5c7c5e9ebca5b9d6471bb4b99a9da5c6d88 upstream. A const prefix was put wrongly in the middle at the code refactoring commit 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops"), which leads to a build error as: sound/soc/sh/siu_pcm.c:546:8: error: expected '{' before 'const' Also, another inconsistency is that the declaration of siu_component misses the const prefix. This patch corrects both failures. Fixes: 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops") Cc: Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20210126154702.3974-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 34ba36b2d705039ec6ddbf602904bea065350009 Author: Alyssa Rosenzweig Date: Tue Aug 11 16:26:31 2020 -0400 drm/rockchip: Require the YTR modifier for AFBC commit 5f94e3571459abb626077aedb65d71264c2a58c0 upstream. The AFBC decoder used in the Rockchip VOP assumes the use of the YUV-like colourspace transform (YTR). YTR is lossless for RGB(A) buffers, which covers the RGBA8 and RGB565 formats supported in vop_convert_afbc_format. Use of YTR is signaled with the AFBC_FORMAT_MOD_YTR modifier, which prior to this commit was missing. As such, a producer would have to generate buffers that do not use YTR, which the VOP would erroneously decode as YTR, leading to severe visual corruption. The upstream AFBC support was developed against a captured frame, which failed to exercise modifier support. Prior to bring-up of AFBC in Mesa (in the Panfrost driver), no open userspace respected modifier reporting. As such, this change is not expected to affect broken userspaces. Tested on RK3399 with Panfrost and Weston. Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") Cc: stable@vger.kernel.org Signed-off-by: Alyssa Rosenzweig Acked-by: Daniel Stone Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20200811202631.3603-1-alyssa.rosenzweig@collabora.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 16ae6b8fb93228f03f109fe15d4eeff241651a8a Author: Heiko Stuebner Date: Sat Feb 6 14:50:20 2021 +0100 drm/panel: kd35t133: allow using non-continuous dsi clock commit d922d58fedcd98ba625e89b625a98e222b090b10 upstream. The panel is able to work when dsi clock is non-continuous, thus the system power consumption can be reduced using such feature. Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags. Also the flag actually becomes necessary after commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for non-continuous HS clock") and without it the panel only emits stripes instead of output. Fixes: c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for non-continuous HS clock") Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Heiko Stuebner Tested-by: Ezequiel Garcia Reviewed-by: Christopher Morgan Link: https://patchwork.freedesktop.org/patch/msgid/20210206135020.1991820-1-heiko@sntech.de Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 4e4c464987b0cdb528061036d420d3a11c9f7515 Author: Andrey Grodzovsky Date: Mon Jan 18 16:01:13 2021 -0500 drm/sched: Cancel and flush all outstanding jobs before finish. commit e582951baabba3e278c97169d0acc1e09b24a72e upstream. To avoid any possible use after free. Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/414814/ CC: stable@vger.kernel.org Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 5e323c4a75c653f0a2c6569fcad2002f48f09fb7 Author: Ville Syrjälä Date: Thu Oct 22 22:42:56 2020 +0300 drm/modes: Switch to 64bit maths to avoid integer overflow commit 5b34ab52401f0f1f191bcb83a182c83b506f4763 upstream. The new >8k CEA modes have dotclocks reaching 5.94 GHz, which means our clock*1000 will now overflow the 32bit unsigned integer. Switch to 64bit maths to avoid it. Cc: stable@vger.kernel.org Reported-by: Randy Dunlap Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20201022194256.30978-1-ville.syrjala@linux.intel.com Tested-by: Randy Dunlap Reviewed-by: Chris Wilson Signed-off-by: Greg Kroah-Hartman commit d526974894d385161a361f2c2a9894916025975c Author: Karol Herbst Date: Fri Nov 27 19:39:09 2020 +0100 drm/nouveau/kms: handle mDP connectors commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream. In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs Reported-by: Mark Pearson Tested-by: Mark Pearson Signed-off-by: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 857f249c8368634497d5f687b0abe827ed90239b Author: xinhui pan Date: Fri Feb 19 12:25:47 2021 +0800 drm/ttm: Fix a memory leak commit 7a8a4b0729a8807e37196e44629b31ee03f88872 upstream. Free the memory on failure. Also no need to re-alloc memory on retry. Signed-off-by: xinhui pan Link: https://patchwork.freedesktop.org/patch/msgid/20210219042547.44855-1-xinhui.pan@amd.com Reviewed-by: Christian König CC: stable@vger.kernel.org # 5.11 Signed-off-by: Christian König Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit a6cd9494475f48e02bbfdeaf70b21130b5a5870f Author: Prike Liang Date: Mon Feb 22 14:04:12 2021 +0800 drm/amdgpu: fix shutdown and poweroff process failed with s0ix commit b092b19602cfd47de1eeeb3a1b03822afd86b136 upstream. In the shutdown and poweroff opt on the s0i3 system we still need un-gate the gfx clock gating and power gating before destory amdgpu device. Fixes: 628c36d7b238e2 ("drm/amdgpu: update amdgpu device suspend/resume sequence for s0i3 support") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1499 Signed-off-by: Alex Deucher Signed-off-by: Prike Liang Reviewed-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0c1ac097737b6616ae49f3c02ae9f95a12a5d04c Author: Alex Deucher Date: Tue Feb 16 10:57:00 2021 -0500 drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) commit 6e80fb8ab04f6c4f377e2fd422bdd1855beb7371 upstream. Fixes the rlc reference clock used for GPU timestamps. Value is 100Mhz. Confirmed with hardware team. v2: reword commit message. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1480 Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f7ab43d5fc64c1a060f45507fed399d6af7f600b Author: Marek Olšák Date: Thu Feb 4 02:46:20 2021 -0500 drm/amdgpu: fix CGTS_TCC_DISABLE register offset on gfx10.3 commit 4112c00354004cbb1bf56f0114fa9951bf6b13ed upstream. This fixes incorrect TCC harvesting info reported to userspace. The impact was a very very tiny performance degradation (unnecessary GL2 cache flushes). Signed-off-by: Marek Olšák Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b1fbce3b5bccbc335eda6ced8f1a9dbb0e9945a7 Author: Felix Kuehling Date: Thu Feb 4 00:11:17 2021 -0500 drm/amdkfd: Fix recursive lock warnings commit 1fb8b1fc4dd1035a264c81d15d41f05884cc8058 upstream. memalloc_nofs_save/restore are no longer sufficient to prevent recursive lock warnings when holding locks that can be taken in MMU notifiers. Use memalloc_noreclaim_save/restore instead. Fixes: f920e413ff9c ("mm: track mmu notifiers in fs_reclaim_acquire/release") CC: Daniel Vetter Reviewed-by: Philip Yang Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.10.x Signed-off-by: Greg Kroah-Hartman commit 1bac3a746956773a94cfdfb6e15d9e064ad97b39 Author: Anson Jacob Date: Thu Feb 18 19:42:57 2021 -0500 Revert "drm/amd/display: reuse current context instead of recreating one" commit efc8278eecfd5e6fa36c5d41e71d038f534fe107 upstream. This reverts commit 8866a67ab86cc0812e65c04f1ef02bcc41e24d68. Reason for revert: This breaks hotplug of HDMI on some systems, resulting in a blank screen. Caused general hangs on boot/hotplugs. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1487 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1492 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211649 Signed-off-by: Anson Jacob Reviewed-by: Bhawanpreet Lakha Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b0d458853ee8c93ade9345ff77404070c45182af Author: Rodrigo Siqueira Date: Fri Feb 5 14:15:11 2021 -0500 drm/amd/display: Add vupdate_no_lock interrupts for DCN2.1 commit 688f97ed3f5e339c0c2c09d9ee7ff23d5807b0a7 upstream. When run igt@kms_vrr in a device that uses DCN2.1 architecture, we noticed multiple failures. Furthermore, when we tested a VRR demo, we noticed a system hang where the mouse pointer still works, but the entire system freezes; in this case, we don't see any dmesg warning or failure messages kernel. This happens due to a lack of vupdate_no_lock interrupt, making the userspace wait eternally to get the event back. For fixing this issue, we need to add the vupdate_no_lock interrupt in the interrupt list. Signed-off-by: Rodrigo Siqueira Acked-by: Bindu Ramamurthy Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 78306880671d8642955edc7c3d34f23e33c14a86 Author: Eric Bernstein Date: Fri Feb 5 13:53:31 2021 -0500 drm/amd/display: Remove Assert from dcn10_get_dig_frontend commit 83e6667b675f101fb66659dfa72e45d08773d763 upstream. [Why] In some cases, this function is called when DIG BE is not connected to DIG FE, in which case a value of zero isn't invalid and assert should not be hit. [How] Remove assert and handle ENGINE_ID_UNKNOWN result in calling function. Signed-off-by: Eric Bernstein Acked-by: Bindu Ramamurthy Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f103ca2a3530680a7004652d0191d1ff6a85f9bd Author: Jan Kokemüller Date: Thu Feb 11 19:28:43 2021 +0100 drm/amd/display: Add FPU wrappers to dcn21_validate_bandwidth() commit 41401ac67791810dd880345962339aa1bedd3c0d upstream. dcn21_validate_bandwidth() calls functions that use floating point math. On my machine this sometimes results in simd exceptions when there are other FPU users such as KVM virtual machines running. The screen freezes completely in this case. Wrapping the function with DC_FP_START()/DC_FP_END() seems to solve the problem. This mirrors the approach used for dcn20_validate_bandwidth. Tested on a AMD Ryzen 7 PRO 4750U (Renoir). Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206987 Signed-off-by: Jan Kokemüller Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d80bf9698c573bb8996d625e995d5404713ce5a5 Author: Alex Deucher Date: Wed Feb 3 14:03:50 2021 -0500 Revert "drm/amd/display: Update NV1x SR latency values" commit 910f1601addae3e430fc7d3cd589d7622c5df693 upstream. This reverts commit 4a3dea8932d3b1199680d2056dd91d31d94d70b7. This causes blank screens for some users. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1388 Cc: Alvin Lee Cc: Jun Lei Cc: Rodrigo Siqueira Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f4da51c78b5a73ecb963ca641ecfaa8be7c9dca6 Author: Kai Krakow Date: Wed Feb 10 13:07:27 2021 +0800 bcache: Move journal work to new flush wq commit afe78ab46f638ecdf80a35b122ffc92c20d9ae5d upstream. This is potentially long running and not latency sensitive, let's get it out of the way of other latency sensitive events. As observed in the previous commit, the `system_wq` comes easily congested by bcache, and this fixes a few more stalls I was observing every once in a while. Let's not make this `WQ_MEM_RECLAIM` as it showed to reduce performance of boot and file system operations in my tests. Also, without `WQ_MEM_RECLAIM`, I no longer see desktop stalls. This matches the previous behavior as `system_wq` also does no memory reclaim: > // workqueue.c: > system_wq = alloc_workqueue("events", 0, 0); Cc: Coly Li Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Kai Krakow Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f8c5dfe5e6641c080ce64baaa62f53dbb92cc49d Author: Kai Krakow Date: Wed Feb 10 13:07:26 2021 +0800 bcache: Give btree_io_wq correct semantics again commit d797bd9897e3559eb48d68368550d637d32e468c upstream. Before killing `btree_io_wq`, the queue was allocated using `create_singlethread_workqueue()` which has `WQ_MEM_RECLAIM`. After killing it, it no longer had this property but `system_wq` is not single threaded. Let's combine both worlds and make it multi threaded but able to reclaim memory. Cc: Coly Li Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Kai Krakow Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 5e5a910f045c4c9e0bcdf7eac1a4bccd45aec073 Author: Kai Krakow Date: Wed Feb 10 13:07:25 2021 +0800 Revert "bcache: Kill btree_io_wq" commit 9f233ffe02e5cef611100cd8c5bcf4de26ca7bef upstream. This reverts commit 56b30770b27d54d68ad51eccc6d888282b568cee. With the btree using the `system_wq`, I seem to see a lot more desktop latency than I should. After some more investigation, it looks like the original assumption of 56b3077 no longer is true, and bcache has a very high potential of congesting the `system_wq`. In turn, this introduces laggy desktop performance, IO stalls (at least with btrfs), and input events may be delayed. So let's revert this. It's important to note that the semantics of using `system_wq` previously mean that `btree_io_wq` should be created before and destroyed after other bcache wqs to keep the same assumptions. Cc: Coly Li Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Kai Krakow Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0c7b495eb8440e43fa782fbc1c47bfadc94193ca Author: Alexander Lobakin Date: Mon Feb 8 12:37:42 2021 +0000 MIPS: compressed: fix build with enabled UBSAN commit fc4cac4cfc437659ce445c3c47b807e1cc625b66 upstream. Commit 1e35918ad9d1 ("MIPS: Enable Undefined Behavior Sanitizer UBSAN") added a possibility to build the entire kernel with UBSAN instrumentation for MIPS, with the exception for VDSO. However, self-extracting head wasn't been added to exceptions, so this occurs: mips-alpine-linux-musl-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_wksp': decompress.c:(.text.FSE_buildDTable_wksp+0x278): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-alpine-linux-musl-ld: decompress.c:(.text.FSE_buildDTable_wksp+0x2a8): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-alpine-linux-musl-ld: decompress.c:(.text.FSE_buildDTable_wksp+0x2c4): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-alpine-linux-musl-ld: arch/mips/boot/compressed/decompress.o: decompress.c:(.text.FSE_buildDTable_raw+0x9c): more undefined references to `__ubsan_handle_shift_out_of_bounds' follow Add UBSAN_SANITIZE := n to mips/boot/compressed/Makefile to exclude it from instrumentation scope and fix this issue. Fixes: 1e35918ad9d1 ("MIPS: Enable Undefined Behavior Sanitizer UBSAN") Cc: stable@vger.kernel.org # 5.0+ Signed-off-by: Alexander Lobakin Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit c3adddbce481ffc32b2e7eeb58f4541231032661 Author: Kevin Hao Date: Tue Jan 19 19:15:31 2021 +0800 Revert "MIPS: Octeon: Remove special handling of CONFIG_MIPS_ELF_APPENDED_DTB=y" commit fe82de91af83a9212b6c704b1ce6cf6d129a108b upstream. This reverts commit d9df9fb901d25b941ab2cfb5b570d91fb2abf7a3. For the OCTEON boards, it need to patch the built-in DTB before using it. Previously it judges if it is a built-in DTB by checking fw_passed_dtb. But after commit 37e5c69ffd41 ("MIPS: head.S: Init fw_passed_dtb to builtin DTB", the fw_passed_dtb is initialized even when using built-in DTB. This causes the OCTEON boards boot broken due to an unpatched built-in DTB is used. Revert the commit d9df9fb901d2 to restore the codes before the fw_passed_dtb is used and then fix this issue. Fixed: 37e5c69ffd41 ("MIPS: head.S: Init fw_passed_dtb to builtin DTB") Cc: stable@vger.kernel.org Suggested-by: Thomas Bogendoerfer Signed-off-by: Kevin Hao Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 592f5c45545fecd972a872a4e4466bc400238331 Author: Nathan Chancellor Date: Fri Jan 15 12:26:22 2021 -0700 MIPS: VDSO: Use CLANG_FLAGS instead of filtering out '--target=' commit 76d7fff22be3e4185ee5f9da2eecbd8188e76b2c upstream. Commit ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags") allowed the '--target=' flag from the main Makefile to filter through to the vDSO. However, it did not bring any of the other clang specific flags for controlling the integrated assembler and the GNU tools locations (--prefix=, --gcc-toolchain=, and -no-integrated-as). Without these, we will get a warning (visible with tinyconfig): arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports one section per compilation unit .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3: ^ arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports one section per compilation unit .section .mips_abiflags, "a" ^ All of these flags are bundled up under CLANG_FLAGS in the main Makefile and exported so that they can be added to Makefiles that set their own CFLAGS. Use this value instead of filtering out '--target=' so there is no warning and all of the tools are properly used. Cc: stable@vger.kernel.org Fixes: ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags") Link: https://github.com/ClangBuiltLinux/linux/issues/1256 Reported-by: Anders Roxell Signed-off-by: Nathan Chancellor Tested-by: Anders Roxell Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit ba4addbd52e127131d59fce55db3462b201906d9 Author: Aurelien Jarno Date: Sat Jan 9 20:30:47 2021 +0100 MIPS: Support binutils configured with --enable-mips-fix-loongson3-llsc=yes commit 5373ae67c3aad1ab306cc722b5a80b831eb4d4d1 upstream. From version 2.35, binutils can be configured with --enable-mips-fix-loongson3-llsc=yes, which means it defaults to -mfix-loongson3-llsc. This breaks labels which might then point at the wrong instruction. The workaround to explicitly pass -mno-fix-loongson3-llsc has been added in Linux version 5.1, but is only enabled when building a Loongson 64 kernel. As vendors might use a common toolchain for building Loongson and non-Loongson kernels, just move that workaround to arch/mips/Makefile. At the same time update the comments to reflect the current status. Cc: stable@vger.kernel.org # 5.1+ Cc: YunQiang Su Signed-off-by: Aurelien Jarno Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 26c3405a48c6354834e6cb6aa659cc0741db8002 Author: Paul Cercueil Date: Sat Dec 12 00:03:54 2020 +0000 MIPS: Ingenic: Disable HPTLB for D0 XBurst CPUs too commit a5360958a3cd1d876aae1f504ae014658513e1af upstream. The JZ4760 has the HPTLB as well, but has a XBurst CPU with a D0 CPUID. Disable the HPTLB for all XBurst CPUs with a D0 CPUID. In the case where there is no HPTLB (e.g. for older SoCs), this won't have any side effect. Fixes: b02efeb05699 ("MIPS: Ingenic: Disable abandoned HPTLB function.") Cc: # 5.4 Signed-off-by: Paul Cercueil Reviewed-by: 周琰杰 (Zhou Yanjie) Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit c015cdf2d932714a5a63603f2c812e6b52541d83 Author: Takashi Iwai Date: Mon Feb 15 09:25:40 2021 +0100 ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup commit c3bb2b521944ffbbc8c24b849f81977a9915fb5e upstream. HP Spectre x360 14 model (PCI SSID 103c:87f7) seems requiring a unique setup for its external amp: the GPIO0 needs to be toggled on and off shortly at each device initialization via runtime PM. This patch implements that workaround as well as the model option string, so that users with other devices may try the same workaround more easily. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210633 Cc: Link: https://lore.kernel.org/r/20210215082540.4520-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 145aea3f6bffac3201cda31420c21a03b26e9f48 Author: PeiSen Hou Date: Tue Feb 2 10:30:22 2021 +0100 ALSA: hda/realtek: modify EAPD in the ALC886 commit 4841b8e6318a7f0ae57c4e5ec09032ea057c97a8 upstream. Modify 0x20 index 7 bit 5 to 1, make the 0x15 EAPD the same as 0x14. Signed-off-by: PeiSen Hou Cc: Link: https://lore.kernel.org/r/e62c5058957f48d8b8953e97135ff108@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6f294e3e3ebb200fbbf15a08df14e00f11f0567d Author: Takashi Iwai Date: Thu Feb 11 09:31:39 2021 +0100 ALSA: hda/hdmi: Drop bogus check at closing a stream commit 056a3da5d07fc5d3ceacfa2cdf013c9d8df630bd upstream. Some users reported the kernel WARNING with stack traces from hdmi_pcm_close(), and it's the line checking the per_cvt->assigned flag. This used to be a valid check in the past because the flag was turned on/off only at opening and closing a PCM stream. Meanwhile, since the introduction of the silent-stream mode, this flag may be turned on/off at the monitor connection/disconnection time, which isn't always associated with the PCM open/close. Hence this may lead to the inconsistent per_cvt->assigned flag at closing. As the check itself became almost useless and confuses users as if it were a serious problem, just drop the check. Fixes: b1a5039759cb ("ALSA: hda/hdmi: fix silent stream for first playback to DP") Cc: BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210987 Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210211083139.29531-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 700a5779189ca8b4e429df8214ab8b3c1366262c Author: Kai Vehmanen Date: Fri Feb 12 17:10:22 2021 +0200 ALSA: hda: Add another CometLake-H PCI ID commit 0d3070f5e6551d8a759619e85736e49a3bf40398 upstream. Add one more HD Audio PCI ID for CometLake-H PCH. Signed-off-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Cc: Link: https://lore.kernel.org/r/20210212151022.2568567-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 16cd03e6ec42ebb8e97f39c9774c2dc11d14bab6 Author: Takashi Sakamoto Date: Mon Feb 8 00:47:36 2021 +0900 ALSA: fireface: fix to parse sync status register of latter protocol commit c50bfc8a6866775be39d7e747e83e8a5a9051e2e upstream. Fireface UCX, UFX, and FF802 are categorized for latter protocol of the series. Current support for FF802 (and UFX) includes failure to parse sync status register and results in EIO. Further investigation figures out that the content of register differs depending on models. This commit adds tables specific to FF802 and UFX to fix it. Fixes: 062bb452b078b ("ALSA: fireface: add support for RME FireFace 802") Cc: Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210207154736.229551-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit af6a6e3473ada2cb4478b119903df472357db8f0 Author: Takashi Iwai Date: Sun Feb 14 16:42:51 2021 +0100 ALSA: usb-audio: Add implicit fb quirk for BOSS GP-10 commit 15447b64789d9ade71eb374d5ae1f37d0bbce0bd upstream. BOSS GP-10 with 0582:0185 requires the similar quirk to make the implicit feedback working like other BOSS devices. Reported-by: Keith Milner Cc: Link: https://lore.kernel.org/r/20210214154251.10750-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5f9b42515d851b982ef1af09c3e3668d4adfd902 Author: Takashi Iwai Date: Sat Feb 6 21:30:52 2021 +0100 ALSA: usb-audio: Don't avoid stopping the stream at disconnection commit 257d2d7e9e798305d65825cb82b0a7d1c0511e89 upstream. In the later patch, we're going to issue the PCM sync_stop calls at disconnection. But currently the USB-audio driver can't handle it because it has a check of shutdown flag for stopping the URBs. This is basically superfluous (the stopping URBs are safe at disconnection state), so let's drop the check. Fixes: dc5eafe7787c ("ALSA: usb-audio: Support PCM sync_stop") Cc: Link: https://lore.kernel.org/r/20210206203052.15606-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3752068efe556417318723f51debce37466d9b34 Author: Takashi Iwai Date: Sat Feb 6 21:30:51 2021 +0100 ALSA: usb-audio: More strict state change in EP commit 5c2b301476ec493be15546f05e23414e2aa9d472 upstream. The endpoint management has bit flags to indicate the current state, and we're dealing two things: the running bit and the stopping bit. There is a thin window in transition from the running to the stopping in stop_urbs(), and as long as the bit flags are used, it's difficult to plug. This patch modifies the state management code to use the atomic int and follow the explicit three states, STOPPED, RUNNING and STOPPING. The state change is done via atomic_cmpxhg() for avoiding possible races, and check the state change more strictly. The unexpected state change is now handled as an error. Fixes: d0f09d1e4a88 ("ALSA: usb-audio: Refactoring endpoint URB deactivation") Cc: Link: https://lore.kernel.org/r/20210206203052.15606-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5cee450387d5a3270d08ec6d3145bf51dd905e1e Author: Takashi Iwai Date: Sat Feb 6 21:30:50 2021 +0100 ALSA: usb-audio: Handle invalid running state at releasing EP commit d6cda4655e2a7612a1e48c49795a5330abc01c5a upstream. When we stop an endpoint in release_urbs(), it ignores the inconsistent endpoint state and tries to release the resources. This shouldn't happen in theory, but it's still safer to abort the release and let the caller proper error handling. Also, stop_and_unlink_urbs() called from release_urbs() does two step works, and it's more straightforward to split this to two functions again, so that the call from the PCM trigger won't take the path with sleeping. This patch modifies the EP management code to adapt two points above. Fixes: d0f09d1e4a88 ("ALSA: usb-audio: Refactoring endpoint URB deactivation") Cc: Link: https://lore.kernel.org/r/20210206203052.15606-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 85d53977ee55ea6dd81eb4005eb477c29a1a392b Author: Takashi Iwai Date: Fri Feb 5 09:28:37 2021 +0100 ALSA: usb-audio: Correct document for snd_usb_endpoint_free_all() commit 036f90dd92bb0aac66fdeec8386401dd396c6079 upstream. The kerndoc comment for the new function snd_usb_endpoint_free_all() had a typo wrt the argument name. Fix it. Fixes: 00272c61827e ("ALSA: usb-audio: Avoid unnecessary interface re-setup") Reported-by: Pierre-Louis Bossart Cc: Link: https://lore.kernel.org/r/20210205082837.6327-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 406834c8046631a3d70a095e12c3673d718713b8 Author: Mathias Kresin Date: Thu Jan 7 23:49:01 2021 +0100 phy: lantiq: rcu-usb2: wait after clock enable commit 36acd5e24e3000691fb8d1ee31cf959cb1582d35 upstream. Commit 65dc2e725286 ("usb: dwc2: Update Core Reset programming flow.") revealed that the phy isn't ready immediately after enabling it's clocks. The dwc2_check_core_version() fails and the dwc2 usb driver errors out. Add a short delay to let the phy get up and running. There isn't any documentation how much time is required, the value was chosen based on tests. Signed-off-by: Mathias Kresin Acked-by: Hauke Mehrtens Acked-by: Martin Blumenstingl Cc: # v5.7+ Link: https://lore.kernel.org/r/20210107224901.2102479-1-dev@kresin.me Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit c686b1661d08cf187f954dc692dcada466394c15 Author: Dan Carpenter Date: Thu Jan 28 12:35:23 2021 +0300 USB: serial: mos7720: fix error code in mos7720_write() commit fea7372cbc40869876df0f045e367f6f97a1666c upstream. This code should return -ENOMEM if the kmalloc() fails but instead it returns success. Signed-off-by: Dan Carpenter Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ca255c1b2808d987389d65c6c1a94a8d5b063088 Author: Dan Carpenter Date: Tue Jan 26 13:26:54 2021 +0300 USB: serial: mos7840: fix error code in mos7840_write() commit a70aa7dc60099bbdcbd6faca42a915d80f31161e upstream. This should return -ENOMEM instead of 0 if the kmalloc() fails. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Signed-off-by: Dan Carpenter Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e8d7e0dfe225ee1cae92bfa6a3d78f6ab8a888b3 Author: Johan Hovold Date: Mon Jan 11 18:00:19 2021 +0100 USB: serial: pl2303: fix line-speed handling on newer chips commit 979d9cbe75b922ab1695b8ad5576115774f72e62 upstream. The latest chip family (HXN) apparently does not support setting the line speed using divisors and instead needs to use the direct encoding scheme for all rates. This specifically enables 50, 110, 134, 200 bps and other rates not supported by the original chip type. Fixes: ebd09f1cd417 ("USB: serial: pl2303: add support for PL2303HXN") Cc: stable@vger.kernel.org # 5.5 Cc: Charles Yeh Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9db0e850ad70e92747f34d68b7ae6adbc8f759d1 Author: Johan Hovold Date: Tue Jan 26 14:59:17 2021 +0100 USB: serial: ftdi_sio: fix FTX sub-integer prescaler commit 528222d0c8ce93e435a95cd1e476b60409dd5381 upstream. The most-significant bit of the sub-integer-prescaler index is set in the high byte of the baudrate request wIndex also for FTX devices. This fixes rates like 1152000 which got mapped to 1.2 MBd. Reported-by: Vladimir Link: https://bugzilla.kernel.org/show_bug.cgi?id=210351 Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit bcf5efdc47bca938782420e77b909d7dfcea0835 Author: Thinh Nguyen Date: Mon Feb 8 13:53:16 2021 -0800 usb: dwc3: gadget: Fix dep->interval for fullspeed interrupt commit 4b049f55ed95cd889bcdb3034fd75e1f01852b38 upstream. The dep->interval captures the number of frames/microframes per interval from bInterval. Fullspeed interrupt endpoint bInterval is the number of frames per interval and not 2^(bInterval - 1). So fix it here. This change is only for debugging purpose and should not affect the interrupt endpoint operation. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/1263b563dedc4ab8b0fb854fba06ce4bc56bd495.1612820995.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit f77b147685f44eea8b6886f42e501cecad0587c0 Author: Thinh Nguyen Date: Mon Feb 8 13:53:10 2021 -0800 usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1 commit a1679af85b2ae35a2b78ad04c18bb069c37330cc upstream. Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it must be set to 0 when the controller operates in full-speed. See the programming guide for DEPCFG command section 3.2.2.1 (v3.30a). Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/3f57026f993c0ce71498dbb06e49b3a47c4d0265.1612820995.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit f14eb95e2d5ba06389038ec812e043bc59971ee2 Author: Paul Cercueil Date: Sat Jan 23 14:24:59 2021 +0000 usb: musb: Fix runtime PM race in musb_queue_resume_work commit 0eaa1a3714db34a59ce121de5733c3909c529463 upstream. musb_queue_resume_work() would call the provided callback if the runtime PM status was 'active'. Otherwise, it would enqueue the request if the hardware was still suspended (musb->is_runtime_suspended is true). This causes a race with the runtime PM handlers, as it is possible to be in the case where the runtime PM status is not yet 'active', but the hardware has been awaken (PM resume function has been called). When hitting the race, the resume work was not enqueued, which probably triggered other bugs further down the stack. For instance, a telnet connection on Ingenic SoCs would result in a 50/50 chance of a segmentation fault somewhere in the musb code. Rework the code so that either we call the callback directly if (musb->is_runtime_suspended == 0), or enqueue the query otherwise. Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid context for hdrc glue") Cc: stable@vger.kernel.org # v4.9+ Tested-by: Tony Lindgren Reviewed-by: Tony Lindgren Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20210123142502.16980-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit 57f58fdac38869dc1e7cb2c979a3fd7298c2c547 Author: Lech Perczak Date: Sun Feb 7 01:54:43 2021 +0100 USB: serial: option: update interface mapping for ZTE P685M commit 6420a569504e212d618d4a4736e2c59ed80a8478 upstream. This patch prepares for qmi_wwan driver support for the device. Previously "option" driver mapped itself to interfaces 0 and 3 (matching ff/ff/ff), while interface 3 is in fact a QMI port. Interfaces 1 and 2 (matching ff/00/00) expose AT commands, and weren't supported previously at all. Without this patch, a possible conflict would exist if device ID was added to qmi_wwan driver for interface 3. Update and simplify device ID to match interfaces 0-2 directly, to expose QCDM (0), PCUI (1), and modem (2) ports and avoid conflict with QMI (3), and ADB (4). The modem is used inside ZTE MF283+ router and carriers identify it as such. Interface mapping is: 0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1275 Rev=f0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Technologies MSM S: SerialNumber=P685M510ZTED0000CP&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&0 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=87(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: Johan Hovold Cc: Bjørn Mork Signed-off-by: Lech Perczak Link: https://lore.kernel.org/r/20210207005443.12936-1-lech.perczak@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d3c694cfadd77ba50358fee6456b23470ece8b33 Author: James Reynolds Date: Tue Dec 22 13:07:04 2020 +0100 media: mceusb: Fix potential out-of-bounds shift commit 1b43bad31fb0e00f45baf5b05bd21eb8d8ce7f58 upstream. When processing a MCE_RSP_GETPORTSTATUS command, the bit index to set in ir->txports_cabled comes from response data, and isn't validated. As ir->txports_cabled is a u8, nothing should be done if the bit index is greater than 7. Cc: stable@vger.kernel.org Reported-by: syzbot+ec3b3128c576e109171d@syzkaller.appspotmail.com Signed-off-by: James Reynolds Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e77742a4eacdf7062e77c361faaa2c9b00bc521a Author: Marcos Paulo de Souza Date: Fri Feb 19 10:37:13 2021 -0800 Input: i8042 - add ASUS Zenbook Flip to noselftest list commit b5d6e7ab7fe7d186878142e9fc1a05e4c3b65eb9 upstream. After commit 77b425399f6d ("Input: i8042 - use chassis info to skip selftest on Asus laptops"), all modern Asus laptops have the i8042 selftest disabled. It has done by using chassys type "10" (laptop). The Asus Zenbook Flip suffers from similar suspend/resume issues, but it _sometimes_ work and sometimes it doesn't. Setting noselftest makes it work reliably. In this case, we need to add chassis type "31" (convertible) in order to avoid selftest in this device. Reported-by: Ludvig Norgren Guldhag Signed-off-by: Marcos Paulo de Souza Link: https://lore.kernel.org/r/20210219164638.761-1-mpdesouza@suse.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit c026ddcfd67948c7184a7effdfd62344f0d26644 Author: Dan Carpenter Date: Wed Feb 17 12:21:10 2021 -0800 Input: joydev - prevent potential read overflow in ioctl commit 182d679b2298d62bf42bb14b12a8067b8e17b617 upstream. The problem here is that "len" might be less than "joydev->nabs" so the loops which verfy abspam[i] and keypam[] might read beyond the buffer. Fixes: 999b874f4aa3 ("Input: joydev - validate axis/button maps before clobbering current ones") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YCyzR8WvFRw4HWw6@mwanda [dtor: additional check for len being even in joydev_handle_JSIOCSBTNMAP] Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 82f9226093321177517c2781f24b09038d0f9d2d Author: Olivier Crête Date: Fri Feb 5 11:59:08 2021 -0800 Input: xpad - add support for PowerA Enhanced Wired Controller for Xbox Series X|S commit 42ffcd1dba1796bcda386eb6f260df9fc23c90af upstream. Signed-off-by: Olivier Crête Link: https://lore.kernel.org/r/20210204005318.615647-1-olivier.crete@collabora.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 76e4640a4229094f08e0d8d24f4931a7871924a6 Author: jeffrey.lin Date: Tue Dec 15 10:50:12 2020 -0800 Input: raydium_ts_i2c - do not send zero length commit fafd320ae51b9c72d371585b2501f86640ea7b7d upstream. Add default write command package to prevent i2c quirk error of zero data length as Raydium touch firmware update is executed. Signed-off-by: jeffrey.lin Link: https://lore.kernel.org/r/1608031217-7247-1-git-send-email-jeffrey.lin@raydium.corp-partner.google.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit e4d9c4a46441b5a64b4e622479bee7d0f32df8ca Author: Jason Gerecke Date: Tue Feb 16 11:41:54 2021 -0800 HID: wacom: Ignore attempts to overwrite the touch_max value from HID commit 88f38846bfb1a452a3d47e38aeab20a4ceb74294 upstream. The `wacom_feature_mapping` function is careful to only set the the touch_max value a single time, but this care does not extend to the `wacom_wac_finger_event` function. In particular, if a device sends multiple HID_DG_CONTACTMAX items in a single feature report, the driver will end up retaining the value of last item. The HID descriptor for the Cintiq Companion 2 does exactly this. It incorrectly sets a "Report Count" of 2, which will cause the driver to process two HID_DG_CONTACTCOUNT items. The first item has the actual count, while the second item should have been declared as a constant zero. The constant zero is the value the driver ends up using, however, since it is the last HID_DG_CONTACTCOUNT in the report. Report ID (16), Usage (Contact Count Maximum), ; Contact count maximum (55h, static value) Report Count (2), Logical Maximum (10), Feature (Variable), To address this, we add a check that the touch_max is not already set within the `wacom_wac_finger_event` function that processes the HID_DG_TOUCHMAX item. We emit a warning if the value is set and ignore the updated value. This could potentially cause problems if there is a tablet which has a similar issue but requires the last item to be used. This is unlikely, however, since it would have to have a different non-zero value for HID_DG_CONTACTMAX earlier in the same report, which makes no sense except in the case of a firmware bug. Note that cases where the HID_DG_CONTACTMAX items are in different reports is already handled (and similarly ignored) by `wacom_feature_mapping` as mentioned above. Link: https://github.com/linuxwacom/input-wacom/issues/223 Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report") Signed-off-by: Jason Gerecke CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 615505e647c1a25dd49d8f9385dd9918e15d957f Author: Filipe Laíns Date: Fri Feb 5 14:34:44 2021 +0000 HID: logitech-dj: add support for keyboard events in eQUAD step 4 Gaming commit ef07c116d98772952807492bd32a61f5af172a94 upstream. In e400071a805d6229223a98899e9da8c6233704a1 I added support for the receiver that comes with the G602 device, but unfortunately I screwed up during testing and it seems the keyboard events were actually not being sent to userspace. This resulted in keyboard events being broken in userspace, please backport the fix. The receiver uses the normal 0x01 Logitech keyboard report descriptor, as expected, so it is just a matter of flagging it as supported. Reported in https://github.com/libratbag/libratbag/issues/1124 Fixes: e400071a805d6 ("HID: logitech-dj: add the G602 receiver") Cc: Signed-off-by: Filipe Laíns Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ba0bf9fb613a428ca338add75e65e548a3078695 Author: Rafael J. Wysocki Date: Mon Feb 15 20:24:46 2021 +0100 cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known commit 538b0188da4653b9f4511a114f014354fb6fb7a5 upstream. Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") attempted to address a performance issue involving acpi-cpufreq, the schedutil governor and scale-invariance on x86 by extending the frequency tables created by acpi-cpufreq to cover the entire range of "turbo" (or "boost") frequencies, but that caused frequencies reported via /proc/cpuinfo and the scaling_cur_freq attribute in sysfs to change which may confuse users and monitoring tools. For this reason, revert the part of commit 3c55e94c0ade adding the extra entry to the frequency table and use the observation that in principle cpuinfo.max_freq need not be equal to the maximum frequency listed in the frequency table for the given policy. Namely, modify cpufreq_frequency_table_cpuinfo() to allow cpufreq drivers to set their own cpuinfo.max_freq above that frequency and change acpi-cpufreq to set cpuinfo.max_freq to the maximum boost frequency found via CPPC. This should be sufficient to let all of the cpufreq subsystem know the real maximum frequency of the CPU without changing frequency reporting. Link: https://bugzilla.kernel.org/show_bug.cgi?id=211305 Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Matt McDonald Tested-by: Matt McDonald Signed-off-by: Rafael J. Wysocki Tested-by: Giovanni Gherdovich Tested-by: Michael Larabel Cc: 5.11+ # 5.11+ Signed-off-by: Greg Kroah-Hartman commit 78bb3058200d191371cbddc6926e4f1902cd6738 Author: Qinglang Miao Date: Fri Jan 15 10:22:50 2021 +0800 ACPI: configfs: add missing check after configfs_register_default_group() commit 67e40054de86aae520ddc2a072d7f6951812a14f upstream. A list_add corruption is reported by Hulk Robot like this: ============== list_add corruption. Call Trace: link_obj+0xc0/0x1c0 link_group+0x21/0x140 configfs_register_subsystem+0xdb/0x380 acpi_configfs_init+0x25/0x1000 [acpi_configfs] do_one_initcall+0x149/0x820 do_init_module+0x1ef/0x720 load_module+0x35c8/0x4380 __do_sys_finit_module+0x10d/0x1a0 do_syscall_64+0x34/0x80 It's because of the missing check after configfs_register_default_group, where configfs_unregister_subsystem should be called once failure. Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs") Reported-by: Hulk Robot Suggested-by: Hanjun Guo Signed-off-by: Qinglang Miao Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f23ca0a0fa148e5aa9fbe2f155ab181a5585f4d4 Author: Rafael J. Wysocki Date: Thu Feb 11 19:30:01 2021 +0100 ACPI: property: Fix fwnode string properties matching commit e1e6bd2995ac0e1ad0c2a2d906a06f59ce2ed293 upstream. Property matching does not work for ACPI fwnodes if the value of the given property is not represented as a package in the _DSD package containing it. For example, the "compatible" property in the _DSD below Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"compatible", "ethernet-phy-ieee802.3-c45"} } }) will not be found by fwnode_property_match_string(), because the ACPI code handling device properties does not regard the single value as a "list" in that case. Namely, fwnode_property_match_string() invoked to match a given string property value first calls fwnode_property_read_string_array() with the last two arguments equal to NULL and 0, respectively, in order to count the items in the value of the given property, with the assumption that this value may be an array. For ACPI fwnodes, that operation is carried out by acpi_node_prop_read() which calls acpi_data_prop_read() for this purpose. However, when the return (val) pointer is NULL, that function only looks for a property whose value is a package without checking the single-value case at all. To fix that, make acpi_data_prop_read() check the single-value case if its return pointer argument is NULL and modify acpi_data_prop_read_single() handling that case to attempt to read the value of the property if the return pointer is NULL and return 1 if that succeeds. Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files") Reported-by: Calvin Johnson Cc: 4.13+ # 4.13+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Sakari Ailus Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 67fe8d3ef5a41bd41a17a47c358b7db78e6eb35d Author: Marcin Ślusarz Date: Mon Feb 8 13:01:03 2021 +0100 soundwire: intel: fix possible crash when no device is detected commit 957e3f797917b36355766807b1d8a54a1ba0cfc9 upstream. acpi_walk_namespace can return success without executing our callback which initializes info->handle. If the random value in this structure is a valid address (which is on the stack, so it's quite possible), then nothing bad will happen, because: sdw_intel_scan_controller -> acpi_bus_get_device -> acpi_get_device_data -> acpi_get_data_full -> acpi_ns_validate_handle will reject this handle. However, if the value from the stack doesn't point to a valid address, we get this: BUG: kernel NULL pointer dereference, address: 0000000000000050 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 6 PID: 472 Comm: systemd-udevd Tainted: G W 5.10.0-1-amd64 #1 Debian 5.10.4-1 Hardware name: HP HP Pavilion Laptop 15-cs3xxx/86E2, BIOS F.05 01/01/2020 RIP: 0010:acpi_ns_validate_handle+0x1a/0x23 Code: 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 44 00 00 48 8d 57 ff 48 89 f8 48 83 fa fd 76 08 48 8b 05 0c b8 67 01 c3 <80> 7f 08 0f 74 02 31 c0 c3 0f 1f 44 00 00 48 8b 3d f6 b7 67 01 e8 RSP: 0000:ffffc388807c7b20 EFLAGS: 00010213 RAX: 0000000000000048 RBX: ffffc388807c7b70 RCX: 0000000000000000 RDX: 0000000000000047 RSI: 0000000000000246 RDI: 0000000000000048 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffffc0f5f4d1 R11: ffffffff8f0cb268 R12: 0000000000001001 R13: ffffffff8e33b160 R14: 0000000000000048 R15: 0000000000000000 FS: 00007f24548288c0(0000) GS:ffff9f781fb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000050 CR3: 0000000106158004 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: acpi_get_data_full+0x4d/0x92 acpi_bus_get_device+0x1f/0x40 sdw_intel_acpi_scan+0x59/0x230 [soundwire_intel] ? strstr+0x22/0x60 ? dmi_matches+0x76/0xe0 snd_intel_dsp_driver_probe.cold+0xaf/0x163 [snd_intel_dspcfg] azx_probe+0x7a/0x970 [snd_hda_intel] local_pci_probe+0x42/0x80 ? _cond_resched+0x16/0x40 pci_device_probe+0xfd/0x1b0 really_probe+0x205/0x460 driver_probe_device+0xe1/0x150 device_driver_attach+0xa1/0xb0 __driver_attach+0x8a/0x150 ? device_driver_attach+0xb0/0xb0 ? device_driver_attach+0xb0/0xb0 bus_for_each_dev+0x78/0xc0 bus_add_driver+0x12b/0x1e0 driver_register+0x8b/0xe0 ? 0xffffffffc0f65000 do_one_initcall+0x44/0x1d0 ? do_init_module+0x23/0x250 ? kmem_cache_alloc_trace+0xf5/0x200 do_init_module+0x5c/0x250 __do_sys_finit_module+0xb1/0x110 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Marcin Ślusarz Reviewed-by: Pierre-Louis Bossart Reviewed-by: Rafael J. Wysocki CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210208120104.204761-1-marcin.slusarz@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit b6846c020d3e76973bc0885b4a730aec8832eb14 Author: Mikulas Patocka Date: Tue Feb 23 19:25:30 2021 -0700 blk-settings: align max_sectors on "logical_block_size" boundary commit 97f433c3601a24d3513d06f575a389a2ca4e11e4 upstream. We get I/O errors when we run md-raid1 on the top of dm-integrity on the top of ramdisk. device-mapper: integrity: Bio not aligned on 8 sectors: 0xff00, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0xff00, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0xffff, 0x1 device-mapper: integrity: Bio not aligned on 8 sectors: 0xffff, 0x1 device-mapper: integrity: Bio not aligned on 8 sectors: 0x8048, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0x8147, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0x8246, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0x8345, 0xbb The ramdisk device has logical_block_size 512 and max_sectors 255. The dm-integrity device uses logical_block_size 4096 and it doesn't affect the "max_sectors" value - thus, it inherits 255 from the ramdisk. So, we have a device with max_sectors not aligned on logical_block_size. The md-raid device sees that the underlying leg has max_sectors 255 and it will split the bios on 255-sector boundary, making the bios unaligned on logical_block_size. In order to fix the bug, we round down max_sectors to logical_block_size. Cc: stable@vger.kernel.org Reviewed-by: Ming Lei Signed-off-by: Mikulas Patocka Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 20894f310a2739f5f72271fdbc40632b319391ed Author: Bart Van Assche Date: Sun Feb 21 18:10:42 2021 -0800 scsi: sd: Fix Opal support commit aaf15f8c6de932861f1fce6aeec6a89ac0e354b6 upstream. The SCSI core has been modified recently such that it only processes PM requests if rpm_status != RPM_ACTIVE. Since some Opal requests are submitted while rpm_status != RPM_ACTIVE, set flag RQF_PM for Opal requests. See also https://bugzilla.kernel.org/show_bug.cgi?id=211227. [mkp: updated sha for PM patch] Link: https://lore.kernel.org/r/20210222021042.3534-1-bvanassche@acm.org Fixes: d80210f25ff0 ("sd: add support for TCG OPAL self encrypting disks") Fixes: e6044f714b25 ("scsi: core: Only process PM requests if rpm_status != RPM_ACTIVE") Cc: chriscjsus@yahoo.com Cc: Jens Axboe Cc: Alan Stern Cc: stable@vger.kernel.org Reported-by: chriscjsus@yahoo.com Tested-by: chriscjsus@yahoo.com Reviewed-by: Christoph Hellwig Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 098c9586e34659e5b5c26cade140da829cb7439b Author: Finn Thain Date: Fri Nov 20 15:39:56 2020 +1100 ide/falconide: Fix module unload [ Upstream commit 07f1dc8cc85bbfb2f9270f25060c4755f4509f45 ] Unloading the falconide module results in a crash: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Oops: 00000000 Modules linked in: falconide(-) PC: [<002930b2>] ide_host_remove+0x2e/0x1d2 SR: 2000 SP: 00b49e28 a2: 009b0f90 d0: 00000000 d1: 009b0f90 d2: 00000000 d3: 00b48000 d4: 003cef32 d5: 00299188 a0: 0086d000 a1: 0086d000 Process rmmod (pid: 322, task=009b0f90) Frame format=7 eff addr=00000000 ssw=0505 faddr=00000000 wb 1 stat/addr/data: 0000 00000000 00000000 wb 2 stat/addr/data: 0000 00000000 00000000 wb 3 stat/addr/data: 0000 00000000 00018da9 push data: 00000000 00000000 00000000 00000000 Stack from 00b49e90: 004c456a 0027f176 0027cb0a 0027cb9e 00000000 0086d00a 2187d3f0 0027f0e0 00b49ebc 2187d1f6 00000000 00b49ec8 002811e8 0086d000 00b49ef0 0028024c 0086d00a 002800d6 00279a1a 00000001 00000001 0086d00a 2187d3f0 00279a58 00b49f1c 002802e0 0086d00a 2187d3f0 004c456a 0086d00a ef96af74 00000000 2187d3f0 002805d2 800de064 00b49f44 0027f088 2187d3f0 00ac1cf4 2187d3f0 004c43be 2187d3f0 00000000 2187d3f0 800b66a8 00b49f5c 00280776 2187d3f0 Call Trace: [<0027f176>] __device_driver_unlock+0x0/0x48 [<0027cb0a>] device_links_busy+0x0/0x94 [<0027cb9e>] device_links_unbind_consumers+0x0/0x130 [<0027f0e0>] __device_driver_lock+0x0/0x5a [<2187d1f6>] falconide_remove+0x12/0x18 [falconide] [<002811e8>] platform_drv_remove+0x1c/0x28 [<0028024c>] device_release_driver_internal+0x176/0x17c [<002800d6>] device_release_driver_internal+0x0/0x17c [<00279a1a>] get_device+0x0/0x22 [<00279a58>] put_device+0x0/0x18 [<002802e0>] driver_detach+0x56/0x82 [<002805d2>] driver_remove_file+0x0/0x24 [<0027f088>] bus_remove_driver+0x4c/0xa4 [<00280776>] driver_unregister+0x28/0x5a [<00281a00>] platform_driver_unregister+0x12/0x18 [<2187d2a0>] ide_falcon_driver_exit+0x10/0x16 [falconide] [<000764f0>] sys_delete_module+0x110/0x1f2 [<000e83ea>] sys_rename+0x1a/0x1e [<00002e0c>] syscall+0x8/0xc [<00188004>] ext4_multi_mount_protect+0x35a/0x3ce Code: 0029 9188 4bf9 0027 aa1c 283c 003c ef32 <265c> 4a8b 6700 00b8 2043 2028 000c 0280 00ff ff00 6600 0176 40c0 7202 b2b9 004c Disabling lock debugging due to kernel taint This happens because the driver_data pointer is uninitialized. Add the missing platform_set_drvdata() call. For clarity, use the matching platform_get_drvdata() as well. Cc: Michael Schmitz Cc: Bartlomiej Zolnierkiewicz Fixes: 5ed0794cde593 ("m68k/atari: Convert Falcon IDE drivers to platform drivers") Reviewed-by: Geert Uytterhoeven Reviewed-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ac7506a95edf155bdb4f5ad70622f4aa9db1a260 Author: Ming Lei Date: Tue Feb 23 16:50:15 2021 +0800 block: fix logging on capacity change [ Upstream commit 452c0bf8754fbeffdf579465b82a3c2bbe373c95 ] Local variable of 'capacity' stores the previous disk capacity, and 'size' variable records the latest disk capacity, so swap them for fixing logging on capacity change. Cc: Christoph Hellwig Fixes: a782483cc1f8 ("block: remove the nr_sects field in struct hd_struct") Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c4f7a869ec1b9ecd8341e440b5793791345ed2fb Author: Christoph Hellwig Date: Tue Feb 23 16:18:22 2021 +0100 block: reopen the device in blkdev_reread_part [ Upstream commit 4601b4b130de2329fe06df80ed5d77265f2058e5 ] Historically the BLKRRPART ioctls called into the now defunct ->revalidate method, which caused the sd driver to check if any media is present. When the ->revalidate method was removed this revalidation was lost, leading to lots of I/O errors when using the eject command. Fix this by reopening the device to rescan the partitions, and thus calling the revalidation logic in the sd driver. Fixes: 471bd0af544b ("sd: use bdev_check_media_change") Reported--by: Tom Seewald Signed-off-by: Christoph Hellwig Tested-by: Tom Seewald Reviewed-by: Ming Lei Reviewed-by: Minwoo Im Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 599ffde6791f123f708f7b943880c912a3398655 Author: Johannes Thumshirn Date: Wed Feb 17 22:52:45 2021 +0900 scsi: sd: sd_zbc: Don't pass GFP_NOIO to kvcalloc [ Upstream commit 9acced3f58ad24407c1f9ebf53a8892c1e24cdb5 ] Dan reported we're passing in GFP_NOIO to kvmalloc() which will then fallback to doing kmalloc() instead of an optional vmalloc() if the size exceeds kmalloc()s limits. This will break with drives that have zone numbers exceeding PAGE_SIZE/sizeof(u32). Instead of passing in GFP_NOIO, enter an implicit GFP_NOIO allocation scope. Link: https://lore.kernel.org/r/YCuvSfKw4qEQBr/t@mwanda Link: https://lore.kernel.org/r/5a6345e2989fd06c049ac4e4627f6acb492c15b8.1613569821.git.johannes.thumshirn@wdc.com Fixes: 5795eb443060: ("scsi: sd_zbc: emulate ZONE_APPEND commands") Cc: Damien Le Moal Reported-by: Dan Carpenter Reviewed-by: Damien Le Moal Signed-off-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eade299459039a89e8153dc56492ebece8a2afbf Author: Randy Dunlap Date: Sat Feb 13 11:24:28 2021 -0800 scsi: bnx2fc: Fix Kconfig warning & CNIC build errors [ Upstream commit eefb816acb0162e94a85a857f3a55148f671d5a5 ] CNIC depends on MMU, but since 'select' does not follow any dependency chains, SCSI_BNX2X_FCOE also needs to depend on MMU, so that erroneous configs are not generated, which cause build errors in cnic. WARNING: unmet direct dependencies detected for CNIC Depends on [n]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && MMU [=n] Selected by [y]: - SCSI_BNX2X_FCOE [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && LIBFC [=y] && LIBFCOE [=y] riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L154': cnic.c:(.text+0x1094): undefined reference to `uio_event_notify' riscv64-linux-ld: cnic.c:(.text+0x10bc): undefined reference to `uio_event_notify' riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L1442': cnic.c:(.text+0x96a8): undefined reference to `__uio_register_device' riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L0 ': cnic.c:(.text.unlikely+0x68): undefined reference to `uio_unregister_device' Link: https://lore.kernel.org/r/20210213192428.22537-1-rdunlap@infradead.org Fixes: 853e2bd2103a ("[SCSI] bnx2fc: Broadcom FCoE offload driver") Cc: Saurav Kashyap Cc: Javed Hasan Cc: GR-QLogic-Storage-Upstream@marvell.com Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org Reported-by: kernel test robot Signed-off-by: Randy Dunlap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 420b7fa21f7e36b2dc4de21e8bb731c1397b0cb9 Author: Zhenzhong Duan Date: Tue Sep 22 17:15:05 2020 +0800 csky: Fix a size determination in gpr_get() [ Upstream commit 8bfb676492da208bd6dde0f22dff79840dbb5051 ] "*" is missed in size determination as we are passing register set rather than a pointer. Fixes: dcad7854fcce ("sky: switch to ->regset_get()") Signed-off-by: Zhenzhong Duan Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit 66258ab303588936ee1ee0794d9a271be24f73cb Author: Josef Bacik Date: Thu Feb 25 17:20:49 2021 -0800 proc: use kvzalloc for our kernel buffer [ Upstream commit 4508943794efdd94171549c0bd52810e2f4ad9fe ] Since sysctl: pass kernel pointers to ->proc_handler we have been pre-allocating a buffer to copy the data from the proc handlers into, and then copying that to userspace. The problem is this just blindly kzalloc()'s the buffer size passed in from the read, which in the case of our 'cat' binary was 64kib. Order-4 allocations are not awesome, and since we can potentially allocate up to our maximum order, so use kvzalloc for these buffers. [willy@infradead.org: changelog tweaks] Link: https://lkml.kernel.org/r/6345270a2c1160b89dd5e6715461f388176899d1.1612972413.git.josef@toxicpanda.com Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler") Signed-off-by: Josef Bacik Reviewed-by: Christoph Hellwig Acked-by: Vlastimil Babka Cc: Al Viro Cc: Alexey Dobriyan CC: Matthew Wilcox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c7f16d074b5380840208f968e5c83a2e503719b5 Author: Miaohe Lin Date: Thu Feb 25 17:18:09 2021 -0800 mm/rmap: fix potential pte_unmap on an not mapped pte [ Upstream commit 5d5d19eda6b0ee790af89c45e3f678345be6f50f ] For PMD-mapped page (usually THP), pvmw->pte is NULL. For PTE-mapped THP, pvmw->pte is mapped. But for HugeTLB pages, pvmw->pte is not mapped and set to the relevant page table entry. So in page_vma_mapped_walk_done(), we may do pte_unmap() for HugeTLB pte which is not mapped. Fix this by checking pvmw->page against PageHuge before trying to do pte_unmap(). Link: https://lkml.kernel.org/r/20210127093349.39081-1-linmiaohe@huawei.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Hongxiang Lou Signed-off-by: Miaohe Lin Tested-by: Sedat Dilek Cc: Kees Cook Cc: Nathan Chancellor Cc: Mike Kravetz Cc: Shakeel Butt Cc: Johannes Weiner Cc: Vlastimil Babka Cc: Michel Lespinasse Cc: Nick Desaulniers Cc: "Kirill A. Shutemov" Cc: Wei Yang Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Brian Geffon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b99e376b453083f84db0c95ca9f3d387a2119fbf Author: Dan Williams Date: Thu Feb 25 17:17:08 2021 -0800 mm: fix memory_failure() handling of dax-namespace metadata [ Upstream commit 34dc45be4563f344d59ba0428416d0d265aa4f4d ] Given 'struct dev_pagemap' spans both data pages and metadata pages be careful to consult the altmap if present to delineate metadata. In fact the pfn_first() helper already identifies the first valid data pfn, so export that helper for other code paths via pgmap_pfn_valid(). Other usage of get_dev_pagemap() are not a concern because those are operating on known data pfns having been looked up by get_user_pages(). I.e. metadata pfns are never user mapped. Link: https://lkml.kernel.org/r/161058501758.1840162.4239831989762604527.stgit@dwillia2-desk3.amr.corp.intel.com Fixes: 6100e34b2526 ("mm, memory_failure: Teach memory_failure() about dev_pagemap pages") Signed-off-by: Dan Williams Reported-by: David Hildenbrand Reviewed-by: David Hildenbrand Reviewed-by: Naoya Horiguchi Cc: Michal Hocko Cc: Oscar Salvador Cc: Qian Cai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit acd7d21bd003d91ab32ed206cdbd63596573bc8e Author: Rik van Riel Date: Thu Feb 25 17:16:25 2021 -0800 mm,thp,shmem: make khugepaged obey tmpfs mount flags [ Upstream commit cd89fb06509903f942a0ffe97ffa63034671ed0c ] Currently if thp enabled=[madvise], mounting a tmpfs filesystem with huge=always and mmapping files from that tmpfs does not result in khugepaged collapsing those mappings, despite the mount flag indicating that it should. Fix that by breaking up the blocks of tests in hugepage_vma_check a little bit, and testing things in the correct order. Link: https://lkml.kernel.org/r/20201124194925.623931-4-riel@surriel.com Fixes: c2231020ea7b ("mm: thp: register mm for khugepaged when merging vma for shmem") Signed-off-by: Rik van Riel Cc: Andrea Arcangeli Cc: Hugh Dickins Cc: Matthew Wilcox (Oracle) Cc: Mel Gorman Cc: Michal Hocko Cc: Vlastimil Babka Cc: Xu Yu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3e6993378d78540978894cf299dbd8b0c586c5d6 Author: Mårten Lindahl Date: Tue Feb 16 23:25:38 2021 +0100 i2c: exynos5: Preserve high speed master code [ Upstream commit f4ff0104d4c807a7f96aa3358c03d694895ee8ea ] When the driver starts to send a message with the MASTER_ID field set (high speed), the whole I2C_ADDR register is overwritten including MASTER_ID as the SLV_ADDR_MAS field is set. This patch preserves already written fields in I2C_ADDR when writing SLV_ADDR_MAS. Fixes: 8a73cd4cfa15 ("i2c: exynos5: add High Speed I2C controller driver") Signed-off-by: Mårten Lindahl Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 379c406f7c27455f105312798c295205304b8c55 Author: Maxime Ripard Date: Thu Feb 25 17:11:01 2021 +0100 i2c: brcmstb: Fix brcmstd_send_i2c_cmd condition [ Upstream commit a1858ce0cfe31368b23ba55794e409fb57ced4a4 ] The brcmstb_send_i2c_cmd currently has a condition that is (CMD_RD || CMD_WR) which always evaluates to true, while the obvious fix is to test whether the cmd variable passed as parameter holds one of these two values. Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver") Reported-by: Dave Stevenson Signed-off-by: Maxime Ripard Acked-by: Florian Fainelli Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 51e877252ae485d6f359432be221ba96df70b2df Author: Marc Zyngier Date: Wed Feb 24 09:37:37 2021 +0000 arm64: Add missing ISB after invalidating TLB in __primary_switch [ Upstream commit 9d41053e8dc115c92b8002c3db5f545d7602498b ] Although there has been a bit of back and forth on the subject, it appears that invalidating TLBs requires an ISB instruction when FEAT_ETS is not implemented by the CPU. From the bible: | In an implementation that does not implement FEAT_ETS, a TLB | maintenance instruction executed by a PE, PEx, can complete at any | time after it is issued, but is only guaranteed to be finished for a | PE, PEx, after the execution of DSB by the PEx followed by a Context | synchronization event Add the missing ISB in __primary_switch, just in case. Fixes: 3c5e9f238bc4 ("arm64: head.S: move KASLR processing out of __enable_mmu()") Suggested-by: Will Deacon Signed-off-by: Marc Zyngier Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210224093738.3629662-3-maz@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f5d4d3c6f6510b4b71df38219c6b36715072a9f5 Author: YueHaibing Date: Thu Feb 18 17:28:12 2021 +0800 cifs: Fix inconsistent IS_ERR and PTR_ERR [ Upstream commit af982da9a612295a91f367469f8945c916a20dfd ] Fix inconsistent IS_ERR and PTR_ERR in cifs_find_swn_reg(). The proper pointer to be passed as argument to PTR_ERR() is share_name. This bug was detected with the help of Coccinelle. Fixes: bf80e5d4259a ("cifs: Send witness register and unregister commands to userspace daemon") Signed-off-by: YueHaibing Reviewed-by: Samuel Cabrero Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0e40ac6a5294bf2241552615b36306cebb37878a Author: Sean Christopherson Date: Fri Feb 12 16:50:02 2021 -0800 KVM: x86/mmu: Expand collapsible SPTE zap for TDP MMU to ZONE_DEVICE and HugeTLB pages [ Upstream commit c060c72ffeb448fbb5864faa1f672ebfe14dd25f ] Zap SPTEs that are backed by ZONE_DEVICE pages when zappings SPTEs to rebuild them as huge pages in the TDP MMU. ZONE_DEVICE huge pages are managed differently than "regular" pages and are not compound pages. Likewise, PageTransCompoundMap() will not detect HugeTLB, so switch to PageCompound(). This matches the similar check in kvm_mmu_zap_collapsible_spte. Cc: Ben Gardon Fixes: 14881998566d ("kvm: x86/mmu: Support disabling dirty logging for the tdp MMU") Signed-off-by: Sean Christopherson Message-Id: <20210213005015.1651772-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ec84d8955d281e45f689a6a68600dc43c1d80642 Author: Sean Christopherson Date: Thu Feb 11 16:34:09 2021 -0800 KVM: SVM: Intercept INVPCID when it's disabled to inject #UD [ Upstream commit 0a8ed2eaac102c746d8d114f2787f06cb3e55dfb ] Intercept INVPCID if it's disabled in the guest, even when using NPT, as KVM needs to inject #UD in this case. Fixes: 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD") Cc: Babu Moger Signed-off-by: Sean Christopherson Message-Id: <20210212003411.1102677-2-seanjc@google.com> Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 0fecf7c478da41ce5010105689dc5bead6b0c891 Author: Trond Myklebust Date: Mon Feb 8 08:49:32 2021 -0500 NFSv4: Fixes for nfs4_bitmask_adjust() [ Upstream commit 45901a231723a5a513ff08477983f3a274a6a910 ] We don't want to ask for the ACL in a WRITE reply, since we don't have a preallocated buffer. Instead of checking NFS_INO_INVALID_ACCESS, which is really about managing the access cache, we should look at the value of NFS_INO_INVALID_OTHER. Also ensure we assign the mode, owner and owner_group flags to the correct bit mask. Finally, fix up the check for NFS_INO_INVALID_CTIME to retrieve the ctime, and add a check for NFS_INO_INVALID_CHANGE. Fixes: 76bd5c016ef4 ("NFSv4: make cache consistency bitmask dynamic") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit cbf8193d21f4f2622badae938c91a25ea1a67fca Author: Heiner Kallweit Date: Thu Feb 25 16:05:19 2021 +0100 r8169: fix jumbo packet handling on RTL8168e [ Upstream commit 6cf739131a15e4177e58a1b4f2bede9d5da78552 ] Josef reported [0] that using jumbo packets fails on RTL8168e. Aligning the values for register MaxTxPacketSize with the vendor driver fixes the problem. [0] https://bugzilla.kernel.org/show_bug.cgi?id=211827 Fixes: d58d46b5d851 ("r8169: jumbo fixes.") Reported-by: Josef Oškera Tested-by: Josef Oškera Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/b15ddef7-0d50-4320-18f4-6a3f86fbfd3e@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e4ade4860d06473040e66f8314b2a3478fad900 Author: Christian Melki Date: Wed Feb 24 21:55:36 2021 +0100 net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8081 [ Upstream commit 764d31cacfe48440745c4bbb55a62ac9471c9f19 ] Following a similar reinstate for the KSZ9031. Older kernels would use the genphy_soft_reset if the PHY did not implement a .soft_reset. Bluntly removing that default may expose a lot of situations where various PHYs/board implementations won't recover on various changes. Like with this implementation during a 4.9.x to 5.4.x LTS transition. I think it's a good thing to remove unwanted soft resets but wonder if it did open a can of worms? Atleast this fixes one iMX6 FEC/RMII/8081 combo. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Christian Melki Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210224205536.9349-1-christian.melki@t2data.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae3f6316202101395c4780670b28243977db04f3 Author: Wonhyuk Yang Date: Wed Feb 24 12:09:36 2021 -0800 mm/compaction: fix misbehaviors of fast_find_migrateblock() [ Upstream commit 15d28d0d11609c7a4f217b3d85e26456d9beb134 ] In the fast_find_migrateblock(), it iterates ocer the freelist to find the proper pageblock. But there are some misbehaviors. First, if the page we found is equal to cc->migrate_pfn, it is considered that we didn't find a suitable pageblock. Secondly, if the loop was terminated because order is less than PAGE_ALLOC_COSTLY_ORDER, it could be considered that we found a suitable one. Thirdly, if the skip bit is set on the page block and we goto continue, it doesn't check nr_scanned. Fourthly, if the page block's skip bit is set, it checks that page block is the last of list, which is unnecessary. Link: https://lkml.kernel.org/r/20210128130411.6125-1-vvghjk1234@gmail.com Fixes: 70b44595eafe9 ("mm, compaction: use free lists to quickly locate a migration source") Signed-off-by: Wonhyuk Yang Acked-by: Vlastimil Babka Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8ae648874a9c98acf349020a00bd47e897f058b2 Author: Chen Wandun Date: Wed Feb 24 12:07:58 2021 -0800 mm/hugetlb: suppress wrong warning info when alloc gigantic page [ Upstream commit 7ecc956551f8a66618f71838c790a9b0b4f9ca10 ] If hugetlb_cma is enabled, it will skip boot time allocation when allocating gigantic page, that doesn't means allocation failure, so suppress this warning info. Link: https://lkml.kernel.org/r/20210219123909.13130-1-chenwandun@huawei.com Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") Signed-off-by: Chen Wandun Reviewed-by: Mike Kravetz Cc: Roman Gushchin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 94e1a39e7b2caf1c0f9830e9baab230b3eb9856d Author: Miaohe Lin Date: Wed Feb 24 12:06:50 2021 -0800 mm/hugetlb: fix potential double free in hugetlb_register_node() error path [ Upstream commit cc2205a67dec5a700227a693fc113441e73e4641 ] In hugetlb_sysfs_add_hstate(), we would do kobject_put() on hstate_kobjs when failed to create sysfs group but forget to set hstate_kobjs to NULL. Then in hugetlb_register_node() error path, we may free it again via hugetlb_unregister_node(). Link: https://lkml.kernel.org/r/20210107123249.36964-1-linmiaohe@huawei.com Fixes: a3437870160c ("hugetlb: new sysfs interface") Signed-off-by: Miaohe Lin Reviewed-by: Mike Kravetz Reviewed-by: Muchun Song Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 249b0e399075cee8fcf899c3402e723d6e918508 Author: Miaohe Lin Date: Wed Feb 24 12:04:33 2021 -0800 mm/memory.c: fix potential pte_unmap_unlock pte error [ Upstream commit 90a3e375d324b2255b83e3dd29e99e2b05d82aaf ] Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed, we would break the loop with pte unchanged. Then the wrong pte - 1 would be passed to pte_unmap_unlock. Andi said: "While the fix is correct, I'm not sure if it actually is a real bug. Is there any architecture that would do something else than unlocking the underlying page? If it's just the underlying page then it should be always the same page, so no bug" Link: https://lkml.kernel.org/r/20210109080118.20885-1-linmiaohe@huawei.com Fixes: 42e4089c789 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings") Signed-off-by: Hongxiang Lou Signed-off-by: Miaohe Lin Cc: Thomas Gleixner Cc: Dave Hansen Cc: Andi Kleen Cc: Josh Poimboeuf Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 39285e1485c778c2f59034919f40cbd1d7ca33f1 Author: Muchun Song Date: Wed Feb 24 12:04:26 2021 -0800 mm: memcontrol: fix slub memory accounting [ Upstream commit 96403bfe50c344b587ea53894954a9d152af1c9d ] SLUB currently account kmalloc() and kmalloc_node() allocations larger than order-1 page per-node. But it forget to update the per-memcg vmstats. So it can lead to inaccurate statistics of "slab_unreclaimable" which is from memory.stat. Fix it by using mod_lruvec_page_state instead of mod_node_page_state. Link: https://lkml.kernel.org/r/20210223092423.42420-1-songmuchun@bytedance.com Fixes: 6a486c0ad4dc ("mm, sl[ou]b: improve memory accounting") Signed-off-by: Muchun Song Reviewed-by: Shakeel Butt Reviewed-by: Roman Gushchin Reviewed-by: Michal Koutný Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6de89e8255def1654220f9626ce47b73f7add088 Author: Muchun Song Date: Wed Feb 24 12:03:19 2021 -0800 mm: memcontrol: fix NR_ANON_THPS accounting in charge moving [ Upstream commit b0ba3bff3e7bb6b58bb248bdd2f3d8ad52fd10c3 ] Patch series "Convert all THP vmstat counters to pages", v6. This patch series is aimed to convert all THP vmstat counters to pages. The unit of some vmstat counters are pages, some are bytes, some are HPAGE_PMD_NR, and some are KiB. When we want to expose these vmstat counters to the userspace, we have to know the unit of the vmstat counters is which one. When the unit is bytes or kB, both clearly distinguishable by the B/KB suffix. But for the THP vmstat counters, we may make mistakes. For example, the below is some bug fix for the THP vmstat counters: - 7de2e9f195b9 ("mm: memcontrol: correct the NR_ANON_THPS counter of hierarchical memcg") - The first commit in this series ("fix NR_ANON_THPS accounting in charge moving") This patch series can make the code clear. And make all the unit of the THP vmstat counters in pages. Finally, the unit of the vmstat counters are pages, kB and bytes. The B/KB suffix can tell us that the unit is bytes or kB. The rest which is without suffix are pages. In this series, I changed the following vmstat counters unit from HPAGE_PMD_NR to pages. However, there is no change to the print format of output to user space. - NR_ANON_THPS - NR_FILE_THPS - NR_SHMEM_THPS - NR_SHMEM_PMDMAPPED - NR_FILE_PMDMAPPED Doing this also can make the statistics more accuracy for the THP vmstat counters. This series is consistent with 8f182270dfec ("mm/swap.c: flush lru pvecs on compound page arrival"). Because we use struct per_cpu_nodestat to cache the vmstat counters, which leads to inaccurate statistics especially THP vmstat counters. In the systems with hundreds of processors it can be GBs of memory. For example, for a 96 CPUs system, the threshold is the maximum number of 125. And the per cpu counters can cache 23.4375 GB in total. The THP page is already a form of batched addition (it will add 512 worth of memory in one go) so skipping the batching seems like sensible. Although every THP stats update overflows the per-cpu counter, resorting to atomic global updates. But it can make the statistics more accuracy for the THP vmstat counters. From this point of view, I think that do this converting is reasonable. Thanks Hugh for mentioning this. This was inspired by Johannes and Roman. Thanks to them. This patch (of 7): The unit of NR_ANON_THPS is HPAGE_PMD_NR already. So it should inc/dec by one rather than nr_pages. Link: https://lkml.kernel.org/r/20201228164110.2838-1-songmuchun@bytedance.com Link: https://lkml.kernel.org/r/20201228164110.2838-2-songmuchun@bytedance.com Fixes: 468c398233da ("mm: memcontrol: switch to native NR_ANON_THPS counter") Signed-off-by: Muchun Song Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Pankaj Gupta Reviewed-by: Roman Gushchin Reviewed-by: Shakeel Butt Cc: Alexey Dobriyan Cc: Feng Tang Cc: Greg Kroah-Hartman Cc: Hugh Dickins Cc: Joonsoo Kim Cc: NeilBrown Cc: Rafael. J. Wysocki Cc: Randy Dunlap Cc: Sami Tolvanen Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6ce3cee77d2aebba94108f3434198a5ea7a9a1c6 Author: Dan Carpenter Date: Wed Feb 24 12:00:41 2021 -0800 ocfs2: fix a use after free on error [ Upstream commit c57d117f2b2f2a19b570c36f2819ef8d8210af20 ] The error handling in this function frees "reg" but it is still on the "o2hb_all_regions" list so it will lead to a use after freew. Joseph Qi points out that we need to clear the bit in the "o2hb_region_bitmap" as well Link: https://lkml.kernel.org/r/YBk4M6HUG8jB/jc7@mwanda Fixes: 1cf257f51191 ("ocfs2: fix memory leak") Signed-off-by: Dan Carpenter Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c14a17f24a96d7ce6edffda9f1a2d5bacd174258 Author: Jason A. Donenfeld Date: Mon Feb 22 17:25:49 2021 +0100 wireguard: kconfig: use arm chacha even with no neon [ Upstream commit bce2473927af8de12ad131a743f55d69d358c0b9 ] The condition here was incorrect: a non-neon fallback implementation is available on arm32 when NEON is not supported. Reported-by: Ilya Lipnitskiy Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d1966e9d65eb13f15ea56c6b02aaac591232b5d0 Author: Jason A. Donenfeld Date: Mon Feb 22 17:25:47 2021 +0100 wireguard: device: do not generate ICMP for non-IP packets [ Upstream commit 99fff5264e7ab06f45b0ad60243475be0a8d0559 ] If skb->protocol doesn't match the actual skb->data header, it's probably not a good idea to pass it off to icmp{,v6}_ndo_send, which is expecting to reply to a valid IP packet. So this commit has that early mismatch case jump to a later error label. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4edb92665ffb053db0a449ed5b36e8aea865982f Author: Taehee Yoo Date: Sun Feb 21 15:45:52 2021 +0000 vxlan: move debug check after netdev unregister [ Upstream commit 92584ddf550ae72d492858c19d1f9025e07a9350 ] The debug check must be done after unregister_netdevice_many() call -- the hlist_del_rcu() for this is done inside .ndo_stop. This is the same with commit 0fda7600c2e1 ("geneve: move debug check after netdev unregister") Test commands: ip netns del A ip netns add A ip netns add B ip netns exec B ip link add vxlan0 type vxlan vni 100 local 10.0.0.1 \ remote 10.0.0.2 dstport 4789 srcport 4789 4789 ip netns exec B ip link set vxlan0 netns A ip netns exec A ip link set vxlan0 up ip netns del B Splat looks like: [ 73.176249][ T7] ------------[ cut here ]------------ [ 73.178662][ T7] WARNING: CPU: 4 PID: 7 at drivers/net/vxlan.c:4743 vxlan_exit_batch_net+0x52e/0x720 [vxlan] [ 73.182597][ T7] Modules linked in: vxlan openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 mlx5_core nfp mlxfw ixgbevf tls sch_fq_codel nf_tables nfnetlink ip_tables x_tables unix [ 73.190113][ T7] CPU: 4 PID: 7 Comm: kworker/u16:0 Not tainted 5.11.0-rc7+ #838 [ 73.193037][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 73.196986][ T7] Workqueue: netns cleanup_net [ 73.198946][ T7] RIP: 0010:vxlan_exit_batch_net+0x52e/0x720 [vxlan] [ 73.201509][ T7] Code: 00 01 00 00 0f 84 39 fd ff ff 48 89 ca 48 c1 ea 03 80 3c 1a 00 0f 85 a6 00 00 00 89 c2 48 83 c2 02 49 8b 14 d4 48 85 d2 74 ce <0f> 0b eb ca e8 b9 51 db dd 84 c0 0f 85 4a fe ff ff 48 c7 c2 80 bc [ 73.208813][ T7] RSP: 0018:ffff888100907c10 EFLAGS: 00010286 [ 73.211027][ T7] RAX: 000000000000003c RBX: dffffc0000000000 RCX: ffff88800ec411f0 [ 73.213702][ T7] RDX: ffff88800a278000 RSI: ffff88800fc78c70 RDI: ffff88800fc78070 [ 73.216169][ T7] RBP: ffff88800b5cbdc0 R08: fffffbfff424de61 R09: fffffbfff424de61 [ 73.218463][ T7] R10: ffffffffa126f307 R11: fffffbfff424de60 R12: ffff88800ec41000 [ 73.220794][ T7] R13: ffff888100907d08 R14: ffff888100907c50 R15: ffff88800fc78c40 [ 73.223337][ T7] FS: 0000000000000000(0000) GS:ffff888114800000(0000) knlGS:0000000000000000 [ 73.225814][ T7] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.227616][ T7] CR2: 0000562b5cb4f4d0 CR3: 0000000105fbe001 CR4: 00000000003706e0 [ 73.229700][ T7] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 73.231820][ T7] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 73.233844][ T7] Call Trace: [ 73.234698][ T7] ? vxlan_err_lookup+0x3c0/0x3c0 [vxlan] [ 73.235962][ T7] ? ops_exit_list.isra.11+0x93/0x140 [ 73.237134][ T7] cleanup_net+0x45e/0x8a0 [ ... ] Fixes: 57b61127ab7d ("vxlan: speedup vxlan tunnels dismantle") Signed-off-by: Taehee Yoo Link: https://lore.kernel.org/r/20210221154552.11749-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cb2eb84f675883200c1c6affd135f6e5df010e89 Author: Chen-Yu Tsai Date: Fri Jan 22 00:23:18 2021 +0800 PCI: rockchip: Make 'ep-gpios' DT property optional [ Upstream commit 58adbfb3ebec460e8b58875c682bafd866808e80 ] The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is an optional property. And indeed there are boards that don't require it. Make the driver follow the binding by using devm_gpiod_get_optional() instead of devm_gpiod_get(). [bhelgaas: tidy whitespace] Link: https://lore.kernel.org/r/20210121162321.4538-2-wens@kernel.org Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver") Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to parse DT") Signed-off-by: Chen-Yu Tsai Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 160cf78c5cb7bb74af0ce17c31015a31d5e61e8e Author: Chuhong Yuan Date: Sun Feb 21 22:35:59 2021 +0800 net/mlx4_core: Add missed mlx4_free_cmd_mailbox() [ Upstream commit 8eb65fda4a6dbd59cd5de24b106a10b6ee0d2176 ] mlx4_do_mirror_rule() forgets to call mlx4_free_cmd_mailbox() to free the memory region allocated by mlx4_alloc_cmd_mailbox() before an exit. Add the missed call to fix it. Fixes: 78efed275117 ("net/mlx4_core: Support mirroring VF DMFS rules on both ports") Signed-off-by: Chuhong Yuan Reviewed-by: Tariq Toukan Link: https://lore.kernel.org/r/20210221143559.390277-1-hslester96@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8c0dc8e89280e2014f61961d5a9880fec27611c Author: Song, Yoong Siang Date: Thu Feb 18 21:40:53 2021 +0800 net: stmmac: fix CBS idleslope and sendslope calculation [ Upstream commit 24877687b375f2c476ffb726ea915fc85df09e3d ] When link speed is not 100 Mbps, port transmit rate and speed divider are set to 8 and 1000000 respectively. These values are incorrect for CBS idleslope and sendslope HW values calculation if the link speed is not 1 Gbps. This patch adds switch statement to set the values of port transmit rate and speed divider for 10 Gbps, 5 Gbps, 2.5 Gbps, 1 Gbps, and 100 Mbps. Note that CBS is not supported at 10 Mbps. Fixes: bc41a6689b30 ("net: stmmac: tc: Remove the speed dependency") Fixes: 1f705bc61aee ("net: stmmac: Add support for CBS QDISC") Signed-off-by: Song, Yoong Siang Link: https://lore.kernel.org/r/1613655653-11755-1-git-send-email-yoong.siang.song@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4ca6bc059753fd5cac73573e2628ba514e711a15 Author: Camelia Groza Date: Thu Feb 18 20:21:06 2021 +0200 dpaa_eth: fix the access method for the dpaa_napi_portal [ Upstream commit 433dfc99aa3e0acbf655b961d98eb690162f758f ] The current use of container_of is flawed and unnecessary. Obtain the dpaa_napi_portal reference from the private percpu data instead. Fixes: a1e031ffb422 ("dpaa_eth: add XDP_REDIRECT support") Reported-by: Sascha Hauer Signed-off-by: Camelia Groza Acked-by: Madalin Bucur Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/r/20210218182106.22613-1-camelia.groza@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d395131e0bdac27a89786b920453ebd00ba1cb3b Author: Henry Tieman Date: Thu Dec 3 09:20:24 2020 -0800 ice: update the number of available RSS queues [ Upstream commit 0393e46ac48a6832b1011c233ebcef84f8dbe4f5 ] It was possible to have Rx queues that were not available for use by RSS. This would happen when increasing the number of Rx queues while there was a user defined RSS LUT. Always update the number of available RSS queues when changing the number of Rx queues. Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") Signed-off-by: Henry Tieman Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4f29665c76447432409d879cf5e8969211bbc2ba Author: Dave Ertman Date: Fri Nov 20 16:38:35 2020 -0800 ice: Fix state bits on LLDP mode switch [ Upstream commit 0d4907f65dc8fc5e897ad19956fca1acb3b33bc8 ] DCBX_CAP bits were not being adjusted when switching between SW and FW controlled LLDP. Adjust bits to correctly indicate which mode the LLDP logic is in. Fixes: b94b013eb626 ("ice: Implement DCBNL support") Signed-off-by: Dave Ertman Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ee5043cbea7ab6347284d6174d3a408052d401e3 Author: Brett Creeley Date: Thu Sep 17 13:13:38 2020 -0700 ice: Account for port VLAN in VF max packet size calculation [ Upstream commit a6aa7c8f998f4afddd73410aa043dad38162ce9e ] Currently if an AVF driver doesn't account for the possibility of a port VLAN when determining its max packet size then packets at MTU will be dropped. It is not the VF driver's responsibility to account for a port VLAN so fix this. To fix this, do the following: 1. Add a function that determines the max packet size a VF is allowed by using the port's max packet size and whether the VF is in a port VLAN. If a port VLAN is configured then a VF's max packet size will always be the port's max packet size minus VLAN_HLEN. Otherwise it will be the port's max packet size. 2. Use this function to verify the max packet size from the VF. 3. If there is a port VLAN configured then add 4 bytes (VLAN_HLEN) to the VF's max packet size configuration. Also, the VIRTCHNL_OP_GET_VF_RESOURCES message provides the capability to communicate a VF's max packet size. Use the new function for this purpose. Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support") Signed-off-by: Brett Creeley Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 906686086a612956164031dbc186c421930ef8f6 Author: Dave Ertman Date: Wed Sep 2 08:53:44 2020 -0700 ice: report correct max number of TCs [ Upstream commit 7dcf7aa01c7b9f18727cbe0f9cb4136f1c6cdcc2 ] In the driver currently, we are reporting max number of TCs to the DCBNL callback as a kernel define set to 8. This is preventing userspace applications performing DCBx to correctly down map the TCs from requested to actual values. Report the actual max TC value to userspace from the capability struct. Fixes: b94b013eb626 ("ice: Implement DCBNL support") Signed-off-by: Dave Ertman Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6ffd6b38d9d1151ea4d5cf52e2952be4dab0882f Author: Uwe Kleine-König Date: Fri Jan 15 08:32:39 2021 +0100 pwm: iqs620a: Fix overflow and optimize calculations [ Upstream commit 72d6b2459dbd539c1369149e501fdc3dc8ddef16 ] If state->duty_cycle is 0x100000000000000, the previous calculation of duty_scale overflows and yields a duty cycle ratio of 0% instead of 100%. Fix this by clamping the requested duty cycle to the maximal possible duty cycle first. This way it is possible to use a native integer division instead of a (depending on the architecture) more expensive 64bit division. With this change in place duty_scale cannot be bigger than 256 which allows to simplify the calculation of duty_val. Fixes: 6f0841a8197b ("pwm: Add support for Azoteq IQS620A PWM generator") Tested-by: Jeff LaBundy Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit c9a2ed3fdd037314a71e6a6ba5d99a3605f6f9c7 Author: Dan Carpenter Date: Fri Feb 19 12:56:32 2021 +0300 octeontx2-af: Fix an off by one in rvu_dbg_qsize_write() [ Upstream commit 3a2eb515d1367c0f667b76089a6e727279c688b8 ] This code does not allocate enough memory for the NUL terminator so it ends up putting it one character beyond the end of the buffer. Fixes: 8756828a8148 ("octeontx2-af: Add NPA aura and pool contexts to debugfs") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1e2c94d0e5c689d037fb5a6856e3e99d0a7a52c6 Author: Norbert Ciosek Date: Fri Feb 5 08:48:52 2021 +0000 i40e: Fix endianness conversions [ Upstream commit b32cddd2247cf730731f93f1967d0147a40682c7 ] Fixes the following sparse warnings: i40e_main.c:5953:32: warning: cast from restricted __le16 i40e_main.c:8008:29: warning: incorrect type in assignment (different base types) i40e_main.c:8008:29: expected unsigned int [assigned] [usertype] ipa i40e_main.c:8008:29: got restricted __le32 [usertype] i40e_main.c:8008:29: warning: incorrect type in assignment (different base types) i40e_main.c:8008:29: expected unsigned int [assigned] [usertype] ipa i40e_main.c:8008:29: got restricted __le32 [usertype] i40e_txrx.c:1950:59: warning: incorrect type in initializer (different base types) i40e_txrx.c:1950:59: expected unsigned short [usertype] vlan_tag i40e_txrx.c:1950:59: got restricted __le16 [usertype] l2tag1 i40e_txrx.c:1953:40: warning: cast to restricted __le16 i40e_xsk.c:448:38: warning: invalid assignment: |= i40e_xsk.c:448:38: left side has type restricted __le64 i40e_xsk.c:448:38: right side has type int Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower") Fixes: 2a508c64ad27 ("i40e: fix VLAN.TCI == 0 RX HW offload") Fixes: 3106c580fb7c ("i40e: Use batched xsk Tx interfaces to increase performance") Fixes: 8f88b3034db3 ("i40e: Add infrastructure for queue channel support") Signed-off-by: Norbert Ciosek Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 5572c79d08eb142c892bda9f617053247c47fbf1 Author: Mateusz Palczewski Date: Mon Dec 28 11:38:00 2020 +0100 i40e: Fix add TC filter for IPv6 [ Upstream commit 61c1e0eb8375def7c891bfe857bb795a57090526 ] Fix insufficient distinction between IPv4 and IPv6 addresses when creating a filter. IPv4 and IPv6 are kept in the same memory area. If IPv6 is added, then it's caught by IPv4 check, which leads to err -95. Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower") Signed-off-by: Grzegorz Szczurek Signed-off-by: Mateusz Palczewski Reviewed-by: Jaroslaw Gawin Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fa0559e673ca6fe91dc1c8e14b6bbe19151a7143 Author: Andreas Oetken Date: Fri Feb 19 14:41:03 2021 +0800 nios2: fixed broken sys_clone syscall [ Upstream commit 9abcfcb20320e8f693e89d86573b58e6289931cb ] The tls pointer must be pushed on the stack prior to calling nios2_clone as it is the 5th function argument. Prior handling of the tls pointer was done inside former called function copy_thread_tls using the r8 register from the current_pt_regs directly. This was a bad design and resulted in the current bug introduced in 04bd52fb. Fixes: 04bd52fb ("nios2: enable HAVE_COPY_THREAD_TLS, switch to kernel_clone_args") Signed-off-by: Andreas Oetken Signed-off-by: Ley Foon Tan Acked-by: Christian Brauner Signed-off-by: Sasha Levin commit 6487424203ef25e52d4c755755f093835c5c5e4d Author: Jann Horn Date: Fri Feb 19 14:59:35 2021 +0800 Take mmap lock in cacheflush syscall [ Upstream commit c26958cb5a0d9053d1358258827638773f3d36ed ] We need to take the mmap lock around find_vma() and subsequent use of the VMA. Otherwise, we can race with concurrent operations like munmap(), which can lead to use-after-free accesses to freed VMAs. Fixes: 1000197d8013 ("nios2: System calls handling") Signed-off-by: Jann Horn Signed-off-by: Ley Foon Tan Signed-off-by: Sasha Levin commit cfd1e824e450318a32d2764a549299ec8510f30e Author: Sylwester Dziedziuch Date: Fri Nov 27 11:23:01 2020 +0000 i40e: Fix VFs not created [ Upstream commit dc8812626440fa6a27f1f3f654f6dc435e042e42 ] When creating VFs they were sometimes not getting resources. It was caused by not executing i40e_reset_all_vfs due to flag __I40E_VF_DISABLE being set on PF. Because of this IAVF was never able to finish setup sequence never getting reset indication from PF. Changed test_and_set_bit __I40E_VF_DISABLE in i40e_sync_filters_subtask to test_bit and removed clear_bit. This function should not set this bit it should only check if it hasn't been already set. Fixes: a7542b876075 ("i40e: check __I40E_VF_DISABLE bit in i40e_sync_filters_subtask") Signed-off-by: Sylwester Dziedziuch Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e53af375e2481e690678081771248812f140f121 Author: Mateusz Palczewski Date: Fri Nov 27 10:39:03 2020 +0000 i40e: Fix addition of RX filters after enabling FW LLDP agent [ Upstream commit 28b1208e7a7fa3ddc9345b022bb93e53d9dcc28a ] Fix addition of VLAN filter for PF after enabling FW LLDP agent. Changing LLDP Agent causes FW to re-initialize per NVM settings. Remove default PF filter and move "Enable/Disable" to currently used reset flag. Without this patch PF would try to add MAC VLAN filter with default switch filter present. This causes AQ error and sets promiscuous mode on. Fixes: c65e78f87f81 ("i40e: Further implementation of LLDP") Signed-off-by: Przemyslaw Patynowski Signed-off-by: Mateusz Palczewski Reviewed-by: Sylwester Dziedziuch Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f3c73d6bdc220b4935a9a22fa4437ecd57bc439c Author: Mateusz Palczewski Date: Tue Nov 24 15:08:27 2020 +0000 i40e: Fix overwriting flow control settings during driver loading [ Upstream commit 4cdb9f80dcd46aab3c0020b4a6920c22735c5d6e ] During driver loading flow control settings were written to FW using a variable which was always zero, since it was being set only by ethtool. This behavior has been corrected and driver no longer overwrites the default FW/NVM settings. Fixes: 373149fc99a0 ("i40e: Decrease the scope of rtnl lock") Signed-off-by: Dawid Lukwinski Signed-off-by: Mateusz Palczewski Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 07c1fc86084c48dcea37deb6105118e8f55e1e60 Author: Mateusz Palczewski Date: Fri Nov 20 10:35:37 2020 +0000 i40e: Add zero-initialization of AQ command structures [ Upstream commit d2c788f739b6f68090e968a2ee31b543701e795f ] Zero-initialize AQ command data structures to comply with API specifications. Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower") Fixes: f4492db16df8 ("i40e: Add NPAR BW get and set functions") Signed-off-by: Andrzej Sawuła Signed-off-by: Mateusz Palczewski Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit cc336fc6177dfea50b8407f718409acae8d12a13 Author: Slawomir Laba Date: Thu Sep 10 07:57:04 2020 +0000 i40e: Fix flow for IPv6 next header (extension header) [ Upstream commit 92c6058024e87087cf1b99b0389d67c0a886360e ] When a packet contains an IPv6 header with next header which is an extension header and not a protocol one, the kernel function skb_transport_header called with such sk_buff will return a pointer to the extension header and not to the TCP one. The above explained call caused a problem with packet processing for skb with encapsulation for tunnel with I40E_TX_CTX_EXT_IP_IPV6. The extension header was not skipped at all. The ipv6_skip_exthdr function does check if next header of the IPV6 header is an extension header and doesn't modify the l4_proto pointer if it points to a protocol header value so its safe to omit the comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can return value -1. This means that the skipping process failed and there is something wrong with the packet so it will be dropped. Fixes: a3fd9d8876a5 ("i40e/i40evf: Handle IPv6 extension headers in checksum offload") Signed-off-by: Slawomir Laba Signed-off-by: Przemyslaw Patynowski Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 00193adcb7d7d2a20c4778ccfb1fe46e5f6628f4 Author: Krzysztof Wilczyński Date: Tue Feb 16 20:59:35 2021 +0000 PCI: cadence: Fix DMA range mapping early return error [ Upstream commit 1002573ee33efef0988a9a546c075a9fa37d2498 ] Function cdns_pcie_host_map_dma_ranges() iterates over a PCIe host bridge DMA ranges using the resource_list_for_each_entry() iterator, returning an error if cdns_pcie_host_bar_config() fails. 49e427e6bdd1 ("Merge branch 'pci/host-probe-refactor'") botched a merge so it *always* returned after the first DMA range, even if no error occurred. Fix the error checking so we return early only when an error occurs. [bhelgaas: commit log] Fixes: 49e427e6bdd1 ("Merge branch 'pci/host-probe-refactor'") Link: https://lore.kernel.org/r/20210216205935.3112661-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 22f6ec4c46149345e52c529e03bcfde9ce1e11f4 Author: Russell King Date: Tue Feb 2 17:07:46 2021 +0000 PCI: pci-bridge-emul: Fix array overruns, improve safety [ Upstream commit f8ee579d53aca887d93f5f411462f25c085a5106 ] We allow up to PCI_EXP_SLTSTA2 registers to be accessed, but the pcie_cap_regs_behavior[] array only covers up to PCI_EXP_RTSTA. Expand this array to avoid walking off the end of it. Do the same for pci_regs_behavior for consistency[], and add a BUILD_BUG_ON() to also check the bridge->conf structure size. Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Link: https://lore.kernel.org/r/E1l6z9W-0006Re-MQ@rmk-PC.armlinux.org.uk Signed-off-by: Russell King Signed-off-by: Bjorn Helgaas Reviewed-by: Pali Rohár Signed-off-by: Sasha Levin commit 6a76bc8617953355bd45b8161366bf96cbbf9db2 Author: Shiyang Ruan Date: Tue Jan 26 10:13:31 2021 +0800 device-dax: Fix default return code of range_parse() [ Upstream commit 7323fb22f05ff1d20498d267828870a5fbbaebd6 ] The return value of range_parse() indicates the size when it is positive. The error code should be negative. Signed-off-by: Shiyang Ruan Reviewed-by: Joao Martins Link: https://lore.kernel.org/r/20210126021331.1059933-1-ruansy.fnst@cn.fujitsu.com Reported-by: Zhang Qilong Fixes: 8490e2e25b5a ("device-dax: add a range mapping allocation attribute") Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit ad89f467781a2323d7a5d9d9832f492665fd5a7a Author: Magnum Shan Date: Thu Feb 4 16:18:19 2021 +0800 mailbox: sprd: correct definition of SPRD_OUTBOX_FIFO_FULL [ Upstream commit 4450f128c51160bfded6b483eba37d0628d7adb2 ] According to the specification, bit[2] represents SPRD_OUTBOX_FIFO_FULL, not bit[0], so correct it. Fixes: ca27fc26cd22 ("mailbox: sprd: Add Spreadtrum mailbox driver") Signed-off-by: Magnum Shan Signed-off-by: Chunyan Zhang Reviewed-by: Baolin Wang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 7fc8279ecd92f9ef5caccf8298dbe14dee11b03c Author: Geert Uytterhoeven Date: Fri Jan 22 12:02:34 2021 +0100 ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it [ Upstream commit 302fdadeafe4be539f247abf25f61822e4a5a577 ] EXT4_KUNIT_TESTS selects EXT4_FS, thus enabling an optional feature the user may not want to enable. Fix this by making the test depend on EXT4_FS instead. Fixes: 1cbeab1b242d16fd ("ext4: add kunit test for decoding extended timestamps") Reviewed-by: Randy Dunlap Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210122110234.2825685-1-geert@linux-m68k.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit a232e4dc70d27a604d218ee47cccbc8e9f89435b Author: Bard Liao Date: Fri Jan 22 15:06:30 2021 +0800 regmap: sdw: use _no_pm functions in regmap_read/write [ Upstream commit d288a5712ef961e16d588bbdb2d846e00b5ef154 ] sdw_update_slave_status will be invoked when a codec is attached, and the codec driver will initialize the codec with regmap functions while the codec device is pm_runtime suspended. regmap routines currently rely on regular SoundWire IO functions, which will call pm_runtime_get_sync()/put_autosuspend. This causes a deadlock where the resume routine waits for an initialization complete signal that while the initialization complete can only be reached when the resume completes. The only solution if we allow regmap functions to be used in resume operations as well as during codec initialization is to use _no_pm routines. The duty of making sure the bus is operational needs to be handled above the regmap level. Fixes: 7c22ce6e21840 ('regmap: Add SoundWire bus support') Signed-off-by: Bard Liao Acked-by: Mark Brown Link: https://lore.kernel.org/r/20210122070634.12825-6-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 37610acdaf2388f9c2679919e944d0520e39b427 Author: Loic Poulain Date: Wed Feb 10 13:55:38 2021 +0530 mhi: Fix double dma free [ Upstream commit db4e8de1935b0202960e9ebb88ab93e8bd1e66b1 ] mhi_deinit_chan_ctxt functionthat takes care of unitializing channel resources, including unmapping coherent MHI areas, can be called from different path in case of controller unregistering/removal: - From a client driver remove callback, via mhi_unprepare_channel - From mhi_driver_remove that unitialize all channels mhi_driver_remove() |-> driver->remove() | |-> mhi_unprepare_channel() | |-> mhi_deinit_chan_ctxt() |... |-> mhi_deinit_chan_ctxt() This leads to double dma freeing... Fix that by preventing deinit for already uninitialized channel. Link: https://lore.kernel.org/r/1612894264-15956-1-git-send-email-loic.poulain@linaro.org Fixes: a7f422f2f89e ("bus: mhi: Fix channel close issue on driver remove") Reported-by: Kalle Valo Tested-by: Kalle Valo Reviewed-by: Manivannan Sadhasivam Signed-off-by: Loic Poulain Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210210082538.2494-2-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ae49ffaa4038a9ca5bb0ddde7ab77592f3f769e6 Author: Tzung-Bi Shih Date: Wed Jan 27 16:20:46 2021 +0800 remoteproc/mediatek: acknowledge watchdog IRQ after handled [ Upstream commit 8c545f52dce44368fff524e13116e696e005c074 ] Acknowledges watchdog IRQ after handled or kernel keeps receiving the interrupt. Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP") Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20210127082046.3735157-1-tzungbi@google.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cea2344cda6d1d8f9c10772646085fb6b0dfcfb4 Author: Jonathan Marek Date: Mon Feb 8 15:04:01 2021 -0500 misc: fastrpc: fix incorrect usage of dma_map_sgtable [ Upstream commit b212658aebda82f92967bcbd4c7380d607c3d803 ] dma_map_sgtable() returns 0 on success, which is the opposite of what this code was doing. Fixes: 7cd7edb89437 ("misc: fastrpc: fix common struct sg_table related issues") Acked-by: Marek Szyprowski Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20210208200401.31100-1-jonathan@marek.ca Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b859094fdd202f378c66ac8eef450e09ed9ac5c2 Author: Stephen Boyd Date: Sat Feb 6 20:18:58 2021 -0800 drm/msm/dp: Add a missing semi-colon [ Upstream commit 182b4a2d251305201b6f9cae29067f7112f05835 ] A missing semicolon here causes my external display to stop working. Indeed, missing the semicolon on the return statement leads to dp_panel_update_tu_timings() not existing because the compiler thinks it's part of the return statement of a void function, so it must not be important. $ ./scripts/bloat-o-meter before.o after.o add/remove: 1/1 grow/shrink: 0/1 up/down: 7400/-7540 (-140) Function old new delta dp_panel_update_tu_timings - 7400 +7400 _dp_ctrl_calc_tu.constprop 18024 17900 -124 dp_panel_update_tu_timings.constprop 7416 - -7416 Total: Before=54440, After=54300, chg -0.26% Add a semicolon so this function works like it used to. Cc: Sean Paul Cc: Kuogee Hsieh Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: Lee Jones Fixes: cc9014bf63a4 ("drm/msm/dp/dp_ctrl: Move 'tu' from the stack to the heap") Signed-off-by: Stephen Boyd Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 624bbb9b0b09bedb27925f867737c9b0711c0664 Author: Pierre-Louis Bossart Date: Fri Jan 22 15:06:33 2021 +0800 soundwire: bus: fix confusion on device used by pm_runtime [ Upstream commit 973794e85610d9a716a897baa9007ff56e192826 ] Intel stress-tests routinely report IO timeouts and invalid power management transitions. Upon further analysis, we seem to be using the wrong devices in pm_runtime calls. Before reading and writing registers, we first need to make sure the Slave is fully resumed. The existing code attempts to do such that, however because of a confusion dating from 2017 and copy/paste, we end-up resuming the parent only instead of resuming the codec device. This can lead to accesses to the Slave registers while the bus is still being configured and the Slave not enumerated, and as a result IO errors occur. This is a classic problem, similar confusions happened for HDaudio between bus and codec device, leading to power management issues. Fix by using the relevant device for all uses of pm_runtime functions. Fixes: 60ee9be255712 ('soundwire: bus: add PM/no-PM versions of read/write functions') Fixes: aa79293517b39 ('soundwire: bus: fix io error when processing alert event') Fixes: 9d715fa005ebc ('soundwire: Add IO transfer') Reported-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210122070634.12825-9-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a0f161068a8f16eadd20a030309562d65a734394 Author: Bard Liao Date: Fri Jan 22 15:06:29 2021 +0800 soundwire: export sdw_write/read_no_pm functions [ Upstream commit 167790abb90fa073d8341ee0e408ccad3d2109cd ] sdw_write_no_pm and sdw_read_no_pm are useful when we want to do IO without touching PM. Fixes: 0231453bc08f ('soundwire: bus: add clock stop helpers') Fixes: 60ee9be25571 ('soundwire: bus: add PM/no-PM versions of read/write functions') Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210122070634.12825-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d31506d799f680050410a4a5aa6a07996a9d4b57 Author: Pierre-Louis Bossart Date: Fri Jan 22 15:06:27 2021 +0800 soundwire: bus: use sdw_write_no_pm when setting the bus scale registers [ Upstream commit 299e9780b9196bcb15b26dfdccd3244eb072d560 ] When a Slave device is resumed, it may resume the bus and restart the enumeration. During that process, we absolutely don't want to call regular read/write routines which will wait for the resume to complete, otherwise a deadlock occurs. This patch fixes the same problem as the previous one, but is split to make the life of linux-stable maintainers less painful. Fixes: 29d158f90690 ('soundwire: bus: initialize bus clock base and scale registers') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210122070634.12825-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c576745c83efae390aac3832f8b4b6963ac3541b Author: Pierre-Louis Bossart Date: Fri Jan 22 15:06:26 2021 +0800 soundwire: bus: use sdw_update_no_pm when initializing a device [ Upstream commit b04c975e654cfdea6d691cd403b5a81cce7e593d ] When a Slave device is resumed, it may resume the bus and restart the enumeration. During that process, we absolutely don't want to call regular read/write routines which will wait for the resume to complete, otherwise a deadlock occurs. Fixes: 60ee9be25571 ('soundwire: bus: add PM/no-PM versions of read/write functions') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210122070634.12825-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ce32c2c976f47ddbf19e5b437fa10f6ba27d6fa8 Author: Rob Clark Date: Thu Feb 4 14:53:11 2021 -0800 drm/msm: Fix legacy relocs path [ Upstream commit c8d99bb938d3303989c4988caf090084073e85a2 ] In moving code around, we ended up using the same pointer to copy_from_user() the relocs tables as we used for the cmd table entry, which is clearly not right. This went unnoticed because modern mesa on non-ancent kernels does not actually use relocs. But this broke ancient mesa on modern kernels. Reported-by: Emil Velikov Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos") Signed-off-by: Rob Clark Reviewed-by: Akhil P Oommen Signed-off-by: Sasha Levin commit 1dae20e246e77a608e1089dd427942877dc16366 Author: Ahmad Fatoum Date: Fri Jan 29 17:14:30 2021 +0000 nvmem: core: skip child nodes not matching binding [ Upstream commit 0445efacec75b85c2a3c176957ee050ba9be53f0 ] The nvmem cell binding applies to all eeprom child nodes matching "^.*@[0-9a-f]+$" without taking a compatible into account. Linux drivers, like at24, are even more extensive and assume _all_ at24 eeprom child nodes to be nvmem cells since e888d445ac33 ("nvmem: resolve cells from DT at registration time"). Since df5f3b6f5357 ("dt-bindings: nvmem: stm32: new property for data access"), the additionalProperties: True means it's Ok to have other properties as long as they don't match "^.*@[0-9a-f]+$". The barebox bootloader extends the MTD partitions binding to EEPROM and can fix up following device tree node: &eeprom { partitions { compatible = "fixed-partitions"; }; }; This is allowed binding-wise, but drivers using nvmem_register() like at24 will fail to parse because the function expects all child nodes to have a reg property present. This results in the whole EEPROM driver probe failing despite the device tree being correct. Fix this by skipping nodes lacking a reg property instead of returning an error. This effectively makes the drivers adhere to the binding because all nodes with a unit address must have a reg property and vice versa. Fixes: e888d445ac33 ("nvmem: resolve cells from DT at registration time"). Signed-off-by: Ahmad Fatoum Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210129171430.11328-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a99348a96d5048afe5d0222924cf29f713fa5d44 Author: Dan Carpenter Date: Fri Jan 29 17:14:26 2021 +0000 nvmem: core: Fix a resource leak on error in nvmem_add_cells_from_of() [ Upstream commit 72e008ce307fa2f35f6783997378b32e83122839 ] This doesn't call of_node_put() on the error path so it leads to a memory leak. Fixes: 0749aa25af82 ("nvmem: core: fix regression in of_nvmem_cell_get()") Signed-off-by: Dan Carpenter Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210129171430.11328-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 409b1654b79fc6952bad1888e62e136d9d203455 Author: Suzuki K Poulose Date: Mon Feb 1 11:13:24 2021 -0700 coresight: etm4x: Skip accessing TRCPDCR in save/restore [ Upstream commit df81b43802f43c0954a55e5d513e8750a1ab4d31 ] When the ETM is affected by Qualcomm errata, modifying the TRCPDCR could cause the system hang. Even though this is taken care of during enable/disable ETM, the ETM state save/restore could still access the TRCPDCR. Make sure we skip the access during the save/restore. Found by code inspection. Link: https://lore.kernel.org/r/20210110224850.1880240-3-suzuki.poulose@arm.com Fixes: 02510a5aa78d ("coresight: etm4x: Add support to skip trace unit power up") Cc: Mathieu Poirier Cc: Mike Leach Cc: Sai Prakash Ranjan Cc: Tingwei Zhang Tested-by: Sai Prakash Ranjan Reviewed-by: Sai Prakash Ranjan Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20210201181351.1475223-5-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d025238b0f601cd8b14662461d808dfe00cdd3fb Author: Geert Uytterhoeven Date: Fri Jan 29 14:17:53 2021 +0100 phy: USB_LGM_PHY should depend on X86 [ Upstream commit 6b46e60a6943d629d69924be3169d8f214624ab2 ] The Intel Lightning Mountain (LGM) USB3 USB is only present on Intel Lightning Mountain SoCs. Hence add a dependency on X86, to prevent asking the user about this driver when configuring a kernel without Intel Lightning Mountain platform support. Fixes: 1cce8f73a561c944 ("phy: Add USB3 PHY support for Intel LGM SoC") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210129131753.2656306-1-geert+renesas@glider.be Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7c82739c0747f4ad7e3b65ed636c7450c08a2259 Author: Theodore Ts'o Date: Thu Feb 4 00:05:20 2021 -0500 ext4: fix potential htree index checksum corruption [ Upstream commit b5776e7524afbd4569978ff790864755c438bba7 ] In the case where we need to do an interior node split, and immediately afterwards, we are unable to allocate a new directory leaf block due to ENOSPC, the directory index checksum's will not be filled in correctly (and indeed, will not be correctly journalled). This looks like a bug that was introduced when we added largedir support. The original code doesn't make any sense (and should have been caught in code review), but it was hidden because most of the time, the index node checksum will be set by do_split(). But if do_split bails out due to ENOSPC, then ext4_handle_dirty_dx_node() won't get called, and so the directory index checksum field will not get set, leading to: EXT4-fs error (device sdb): dx_probe:858: inode #6635543: block 4022: comm nfsd: Directory index failed checksum Google-Bug-Id: 176345532 Fixes: e08ac99fa2a2 ("ext4: add largedir feature") Cc: Artem Blagodarenko Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit d0b0f9101c51df18bb23ae83763a45cff678ac00 Author: Max Gurtovoy Date: Mon Feb 1 16:28:25 2021 +0000 vfio-pci/zdev: fix possible segmentation fault issue [ Upstream commit 7e31d6dc2c78b2a0ba0039ca97ca98a581e8db82 ] In case allocation fails, we must behave correctly and exit with error. Fixes: e6b817d4b821 ("vfio-pci/zdev: Add zPCI capabilities to VFIO_DEVICE_GET_INFO") Signed-off-by: Max Gurtovoy Reviewed-by: Cornelia Huck Reviewed-by: Matthew Rosato Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit f23841da0e8d51536ebf9a2bd68c7387102f6fc6 Author: Keqian Zhu Date: Fri Jan 22 17:26:35 2021 +0800 vfio/iommu_type1: Fix some sanity checks in detach group [ Upstream commit 4a19f37a3dd3f29997735e61b25ddad24b8abe73 ] vfio_sanity_check_pfn_list() is used to check whether pfn_list and notifier are empty when remove the external domain, so it makes a wrong assumption that only external domain will use the pinning interface. Now we apply the pfn_list check when a vfio_dma is removed and apply the notifier check when all domains are removed. Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices") Signed-off-by: Keqian Zhu Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit d513be7a0aade3f12264a5d959025ee9f68edf63 Author: Keqian Zhu Date: Fri Jan 22 17:26:34 2021 +0800 vfio/iommu_type1: Populate full dirty when detach non-pinned group [ Upstream commit d0a78f91761fcd837da1e7a4b0f8368873adc646 ] If a group with non-pinned-page dirty scope is detached with dirty logging enabled, we should fully populate the dirty bitmaps at the time it's removed since we don't know the extent of its previous DMA, nor will the group be present to trigger the full bitmap when the user retrieves the dirty bitmap. Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages tracking") Suggested-by: Alex Williamson Signed-off-by: Keqian Zhu Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit f1fbb4df98b980f3fb19228d423343b2eeb5b60b Author: Judy Hsiao Date: Fri Jan 29 18:16:03 2021 +0800 drm/msm/dp: trigger unplug event in msm_dp_display_disable [ Upstream commit c703d5789590935c573bbd080a2166b72d51a017 ] 1. Trigger the unplug event in msm_dp_display_disable() to shutdown audio properly. 2. Reset the completion before signal the disconnect event. Fixes: 158b9aa74479 ("drm/msm/dp: wait for audio notification before disabling clocks") Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd Signed-off-by: Judy Hsiao Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit da5b88b3f66b295f2626dffce21b2c34e4af7456 Author: Stephen Boyd Date: Thu Jan 28 09:09:29 2021 -0800 drm/msm/kms: Make a lock_class_key for each crtc mutex [ Upstream commit 6ec9351809612fa1c0256fb3e39b49b6100e2983 ] Lockdep complains about an AA deadlock when rebooting the device. base-commit: 19c329f6808995b142b3966301f217c831e7cf31 ============================================ WARNING: possible recursive locking detected 5.4.91 #1 Not tainted -------------------------------------------- reboot/5213 is trying to acquire lock: ffffff80d13391b0 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4 but task is already holding lock: ffffff80d1339110 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&kms->commit_lock[i]); lock(&kms->commit_lock[i]); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by reboot/5213: __arm64_sys_reboot+0x148/0x2a0 device_shutdown+0x10c/0x2c4 drm_atomic_helper_shutdown+0x48/0xfc modeset_lock+0x120/0x24c lock_crtcs+0x60/0xa4 stack backtrace: CPU: 4 PID: 5213 Comm: reboot Not tainted 5.4.91 #1 Hardware name: Google Pompom (rev1) with LTE (DT) Call trace: dump_backtrace+0x0/0x1dc show_stack+0x24/0x30 dump_stack+0xfc/0x1a8 __lock_acquire+0xcd0/0x22b8 lock_acquire+0x1ec/0x240 __mutex_lock_common+0xe0/0xc84 mutex_lock_nested+0x48/0x58 lock_crtcs+0x60/0xa4 msm_atomic_commit_tail+0x348/0x570 commit_tail+0xdc/0x178 drm_atomic_helper_commit+0x160/0x168 drm_atomic_commit+0x68/0x80 This is because lockdep thinks all the locks taken in lock_crtcs() are the same lock, when they actually aren't. That's because we call mutex_init() in msm_kms_init() and that assigns one static key for every lock initialized in this loop. Let's allocate a dynamic number of lock_class_keys and assign them to each lock so that lockdep can figure out an AA deadlock isn't possible here. Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver with async layer updates") Cc: Krishna Manikandan Signed-off-by: Stephen Boyd Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a486a905ff0b75c7af33dde82191ab2699d913ea Author: Eric Anholt Date: Thu Jan 28 13:03:31 2021 -0800 drm/msm: Fix races managing the OOB state for timestamp vs timestamps. [ Upstream commit 5f98b33b04c02c0d9088c7486c59d058696782f9 ] Now that we're not racing with GPU setup, also fix races of timestamps against other timestamps. In freedreno CI, we were seeing this path trigger timeouts on setting the GMU bit, producing: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this triggered especially on the first set of tests right after boot (it's probably easier to lose the race than one might think, given that we start many tests in parallel, and waiting for NFS to page in code probably means that lots of tests hit the same point of screen init at the same time). As of this patch, the message seems to have completely gone away. Signed-off-by: Eric Anholt Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 196a071a352f3112261d9236b9929104aa427aef Author: Eric Anholt Date: Thu Jan 28 13:03:30 2021 -0800 drm/msm: Fix race of GPU init vs timestamp power management. [ Upstream commit 7a7cbf2a819740674455ad36155c662367261296 ] We were using the same force-poweron bit in the two codepaths, so they could race to have one of them lose GPU power early. freedreno CI was seeing intermittent errors like: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this issue could have contributed to it. Signed-off-by: Eric Anholt Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 1dfee6007698fad535e2e3913fff3747cd52a7fc Author: Iskren Chernev Date: Wed Jan 27 17:24:40 2021 +0200 drm/msm/mdp5: Fix wait-for-commit for cmd panels [ Upstream commit 68e4f01fddb4ead80e8c7084db489307f22c9cbb ] Before the offending commit in msm_atomic_commit_tail wait_flush was called once per frame, after the commit was submitted. After it wait_flush is also called at the beginning to ensure previous potentially async commits are done. For cmd panels the source of wait_flush is a ping-pong irq notifying a completion. The completion needs to be notified with complete_all so multiple waiting parties (new async committers) can proceed. Signed-off-by: Iskren Chernev Suggested-by: Rob Clark Fixes: 2d99ced787e3d ("drm/msm: async commit support") Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6d2622f42baade725e5275388284969c28e14ee8 Author: Konrad Dybcio Date: Mon Jan 18 17:15:58 2021 +0100 drm/msm/dsi: Correct io_start for MSM8994 (20nm PHY) [ Upstream commit 33a7808ce1aea6e2edc1af25db25928137940c02 ] The previous registers were *almost* correct, but instead of PHYs, they were pointing at DSI PLLs, resulting in the PHY id autodetection failing miserably. Fixes: dcefc117cc19 ("drm/msm/dsi: Add support for msm8x94") Signed-off-by: Konrad Dybcio Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 5b99af7c1ab1ef470ddb72038ea189fecfc1e310 Author: Sai Prakash Ranjan Date: Mon Jan 11 17:34:08 2021 +0530 drm/msm: Add proper checks for GPU LLCC support [ Upstream commit 276619c0923f8fa6a82e60edb88a82468645362d ] Domain attribute setting for LLCC is guarded by !IS_ERR check which works fine only when CONFIG_QCOM_LLCC=y but when it is disabled, the LLCC apis return NULL and that is not handled by IS_ERR check. Due to this, domain attribute for LLCC will be set even on GPUs which do not support it and cause issues, so correct this by using IS_ERR_OR_NULL checks appropriately. Meanwhile also cleanup comment block and remove unwanted blank line. Fixes: 00fd44a1a470 ("drm/msm: Only enable A6xx LLCC code on A6xx") Fixes: 474dadb8b0d5 ("drm/msm/a6xx: Add support for using system cache(LLC)") Signed-off-by: Sai Prakash Ranjan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit f38ac6ccd960c3b0a41249905d522d410d7bfcbe Author: Iskren Chernev Date: Sat Jan 2 22:24:37 2021 +0200 drm/msm: Fix MSM_INFO_GET_IOVA with carveout [ Upstream commit 6cefa31e810404dafdfcdb94874146cea11626c2 ] The msm_gem_get_iova should be guarded with gpu != NULL and not aspace != NULL, because aspace is NULL when using vram carveout. Fixes: 933415e24bd0d ("drm/msm: Add support for private address space instances") Signed-off-by: Iskren Chernev Tested-by: Alexey Minnekhanov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 27c690b3be80fbef69fe371e40e956fc1f275661 Author: Alexander Usyskin Date: Fri Jan 29 14:07:48 2021 +0200 mei: hbm: call mei_set_devstate() on hbm stop response [ Upstream commit 3a77df62deb2e62de0dc26c1cb763cc152329287 ] Use mei_set_devstate() wrapper upon hbm stop command response, to trigger sysfs event. Fixes: 43b8a7ed4739 ("mei: expose device state in sysfs") Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20210129120752.850325-3-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e387a55a938d33441b97b87232e03de1d2681ea Author: Heiner Kallweit Date: Sun Jan 24 16:39:32 2021 +0100 PCI: Align checking of syscall user config accessors [ Upstream commit ef9e4005cbaf022c6251263aa27836acccaef65d ] After 34e3207205ef ("PCI: handle positive error codes"), pci_user_read_config_*() and pci_user_write_config_*() return 0 or negative errno values, not PCIBIOS_* values like PCIBIOS_SUCCESSFUL or PCIBIOS_BAD_REGISTER_NUMBER. Remove comparisons with PCIBIOS_SUCCESSFUL and check only for non-zero. It happens that PCIBIOS_SUCCESSFUL is zero, so this is not a functional change, but it aligns this code with the user accessors. [bhelgaas: commit log] Fixes: 34e3207205ef ("PCI: handle positive error codes") Link: https://lore.kernel.org/r/f1220314-e518-1e18-bf94-8e6f8c703758@gmail.com Signed-off-by: Heiner Kallweit Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 992a476fea9e311a80d15fc7efbaf182550a4397 Author: Jorgen Hansen Date: Wed Jan 20 08:32:40 2021 -0800 VMCI: Use set_page_dirty_lock() when unregistering guest memory [ Upstream commit 5a16c535409f8dcb7568e20737309e3027ae3e49 ] When the VMCI host support releases guest memory in the case where the VM was killed, the pinned guest pages aren't locked. Use set_page_dirty_lock() instead of set_page_dirty(). Testing done: Killed VM while having an active VMCI based vSocket connection and observed warning from ext4. With this fix, no warning was observed. Ran various vSocket tests without issues. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Reviewed-by: Vishnu Dasa Signed-off-by: Jorgen Hansen Link: https://lore.kernel.org/r/1611160360-30299-1-git-send-email-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2f440de6e28c0949d558da5a56ea32c85f755b66 Author: Pan Bian Date: Wed Jan 20 06:37:45 2021 -0800 PCI: xilinx-cpm: Fix reference count leak on error path [ Upstream commit ae191d2e513ae5274224777ae67018a584074a28 ] Also drop the reference count of the node on error path. Link: https://lore.kernel.org/r/20210120143745.699-1-bianpan2016@163.com Fixes: 508f610648b9 ("PCI: xilinx-cpm: Add Versal CPM Root Port driver") Signed-off-by: Pan Bian Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit c104a020ca60d9ba441cd9cf2b1d4d4534a4fa8c Author: Simon South Date: Tue Jan 19 11:12:08 2021 -0500 pwm: rockchip: Eliminate potential race condition when probing [ Upstream commit d21ba5d6217bd5a6a696678385906ed1994b380b ] Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") introduced a potential race condition in rockchip_pwm_probe(): A consumer could enable an inactive PWM, or disable a running one, between rockchip_pwm_probe() registering the device via pwmchip_add() and checking whether it is enabled (to determine whether it was started by a bootloader). This could result in a device's PWM clock being either enabled once more than necessary, potentially causing it to continue running when no longer needed, or disabled once more than necessary, producing a warning from the kernel. Eliminate these possibilities by modifying rockchip_pwm_probe() so it checks whether a device is enabled before registering it rather than after. Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Reported-by: Trent Piepho Signed-off-by: Simon South Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 2a8b8e516cd21207e4164b74f08db7ae6849f378 Author: Simon South Date: Tue Jan 19 11:12:06 2021 -0500 pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare() [ Upstream commit d5d8d675865ccddfe4da26c85f22c55cec663bf2 ] If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having first disabled the clock and before jumping to an error handler that also unprepares it. This is likely to produce warnings from the kernel about the clock being unprepared when it is still enabled, and then being unprepared when it has already been unprepared. Prevent these warnings by removing this unnecessary call to clk_unprepare(). Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Signed-off-by: Simon South Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 7a7cafaa0e96663a3e1176ca0cf78549d32d0653 Author: Simon South Date: Tue Jan 19 11:12:05 2021 -0500 pwm: rockchip: Enable APB clock during register access while probing [ Upstream commit d9b657a5cdbd960de35dee7e06473caf44a9016f ] Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") modified rockchip_pwm_probe() to access a PWM device's registers directly to check whether or not the device is enabled, but did not also change the function so it first enables the device's APB clock to be certain the device can respond. This risks hanging the kernel on systems with PWM devices that use more than a single clock. Avoid this by enabling the device's APB clock before accessing its registers (and disabling the clock when register access is complete). Fixes: 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") Reported-by: Thierry Reding Suggested-by: Trent Piepho Signed-off-by: Simon South Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit aaaed4160e039e010eea5bd2bbd3599f20cbbec9 Author: Pierre-Louis Bossart Date: Fri Jan 15 13:37:37 2021 +0800 soundwire: cadence: fix ACK/NAK handling [ Upstream commit db9d9f944f95e7f3aa60ac00cbd502415152c421 ] The existing code reports a NAK only when ACK=0 This is not aligned with the SoundWire 1.x specifications. Table 32 in the SoundWire 1.2 specification shows that a Device shall not set NAK=1 if ACK=1. But Table 33 shows the Combined Response may very well be NAK=1/ACK=1, e.g. if another Device than the one addressed reports a parity error. NAK=1 signals a 'Command_Aborted', regardless of the ACK bit value. Move the tests for NAK so that the NAK=1/ACK=1 combination is properly detected according to the specification. Fixes: 956baa1992f9a ('soundwire: cdns: Add sdw_master_ops and IO transfer support') Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210115053738.22630-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f14caff25668156b19238867905b4bc393341903 Author: Marek Vasut Date: Fri Oct 16 14:04:31 2020 +0200 PCI: rcar: Always allocate MSI addresses in 32bit space [ Upstream commit c4e0fec2f7ee013dbf86445394ff47f719408f99 ] This fixes MSI operation on legacy PCI cards, which cannot issue 64bit MSIs. The R-Car controller only has one MSI trigger address instead of two, one for 64bit and one for 32bit MSI, set the address to 32bit PCIe space so that legacy PCI cards can also trigger MSIs. Link: https://lore.kernel.org/r/20201016120431.7062-1-marek.vasut@gmail.com Fixes: 290c1fb35860 ("PCI: rcar: Add MSI support for PCIe") Tested-by: Yoshihiro Shimoda Tested-by: Geert Uytterhoeven Signed-off-by: Marek Vasut Signed-off-by: Lorenzo Pieralisi Reviewed-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Cc: Bjorn Helgaas Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Wolfram Sang Cc: Yoshihiro Shimoda Cc: linux-renesas-soc@vger.kernel.org Signed-off-by: Sasha Levin commit 8ee111dbe3c37054a46239d7d9da9c91d84e7697 Author: Aswath Govindraju Date: Wed Jan 13 10:42:52 2021 +0530 misc: eeprom_93xx46: Add module alias to avoid breaking support for non device tree users [ Upstream commit 4540b9fbd8ebb21bb3735796d300a1589ee5fbf2 ] Module alias "spi:93xx46" is used by non device tree users like drivers/misc/eeprom/digsy_mtc_eeprom.c and removing it will break support for them. Fix this by adding back the module alias "spi:93xx46". Fixes: 13613a2246bf ("misc: eeprom_93xx46: Fix module alias to enable module autoprobe") Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210113051253.15061-1-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3d07e400bf9bdbabd04f6580cc51a2621ec1387b Author: Dan Carpenter Date: Thu Dec 17 14:04:59 2020 +0300 phy: cadence-torrent: Fix error code in cdns_torrent_phy_probe() [ Upstream commit 266df28f9ac16b0dff553d78bc3fb1c084b96b9d ] This error path should return -EINVAL, but currently it returns success. Fixes: d09945eacad0 ("phy: cadence-torrent: Check total lane count for all subnodes is within limit") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X9s7Wxq+b6ls0q7o@mwanda Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6e96bf8f8ac05d38491dacb0e5fe4d933a62dcab Author: Chris Ruehl Date: Thu Dec 10 16:04:54 2020 +0800 phy: rockchip-emmc: emmc_phy_init() always return 0 [ Upstream commit 39961bd6b70e5a5d7c4b5483ad8e1db6b5765c60 ] rockchip_emmc_phy_init() return variable is not set with the error value if clk_get() failed. 'emmcclk' is optional, thus use clk_get_optional() and if the return value != NULL make error processing and set the return code accordingly. Fixes: 52c0624a10cce phy: rockchip-emmc: Set phyctrl_frqsel based on card clock Signed-off-by: Chris Ruehl Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20201210080454.17379-1-chris.ruehl@gtsys.com.hk Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 49f741d6696886ddf6f26bea9497cfed134d7e5a Author: Aswath Govindraju Date: Thu Jan 7 22:09:53 2021 +0530 misc: eeprom_93xx46: Fix module alias to enable module autoprobe [ Upstream commit 13613a2246bf531f5fc04e8e62e8f21a3d39bf1c ] Fix module autoprobe by correcting module alias to match the string from /sys/class/.../spi1.0/modalias content. Fixes: 06b4501e88ad ("misc/eeprom: add driver for microwire 93xx46 EEPROMs") Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210107163957.28664-2-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8f77d9fe5cefc1ab3a19a60cd179fac334199911 Author: Geert Uytterhoeven Date: Tue Feb 23 09:30:09 2021 -0800 Input: st1232 - fix NORMAL vs. IDLE state handling [ Upstream commit 1bff77f41a805b16b5355497c217656711601282 ] NORMAL (0x0) and IDLE (0x4) are really two different states. Hence you cannot check for both using a bitmask, as that checks for IDLE only, breaking operation for devices that are in NORMAL state. Fix the wait function to report either state as ready. Fixes: 6524d8eac258452e ("Input: st1232 - add IDLE state as ready condition") Signed-off-by: Geert Uytterhoeven Reviewed-by: Michael Tretter Link: https://lore.kernel.org/r/20210223090201.1430542-1-geert+renesas@glider.be Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit d34debb0b4e62e927dabc24404423b35d1d78691 Author: Randy Dunlap Date: Sat Feb 20 19:47:48 2021 +0100 ARM: 9065/1: OABI compat: fix build when EPOLL is not enabled [ Upstream commit fd749fe4bcb00ad80d9eece709f804bb4ac6bf1e ] When CONFIG_EPOLL is not set/enabled, sys_oabi-compat.c has build errors. Fix these by surrounding them with ifdef CONFIG_EPOLL/endif and providing stubs for the "EPOLL is not set" case. ../arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_epoll_ctl': ../arch/arm/kernel/sys_oabi-compat.c:257:6: error: implicit declaration of function 'ep_op_has_event' [-Werror=implicit-function-declaration] 257 | if (ep_op_has_event(op) && | ^~~~~~~~~~~~~~~ ../arch/arm/kernel/sys_oabi-compat.c:264:9: error: implicit declaration of function 'do_epoll_ctl'; did you mean 'sys_epoll_ctl'? [-Werror=implicit-function-declaration] 264 | return do_epoll_ctl(epfd, op, fd, &kernel, false); | ^~~~~~~~~~~~ Fixes: c281634c8652 ("ARM: compat: remove KERNEL_DS usage in sys_oabi_epoll_ctl()") Signed-off-by: Randy Dunlap Reported-by: kernel test robot # from an lkp .config file Cc: linux-arm-kernel@lists.infradead.org Cc: Nicolas Pitre Cc: Alexander Viro Cc: patches@armlinux.org.uk Acked-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d9cb8243ca0dc6d9e2874152fb479b47c5295993 Author: Michael Tretter Date: Fri Feb 19 10:37:00 2021 -0800 Input: st1232 - add IDLE state as ready condition [ Upstream commit 6524d8eac258452e547f8a49c8a965ac6dd8a161 ] The st1232 can switch from NORMAL to IDLE state after the configured idle time (by default 8 s). If the st1232 is not reset during probe, it might already be ready but in IDLE state. Since it does not enter NORMAL state in this case, probe fails. Fix the wait function to report the IDLE state as ready, too. Fixes: f605be6a57b4 ("Input: st1232 - wait until device is ready before reading resolution") Signed-off-by: Michael Tretter Link: https://lore.kernel.org/r/20210219110556.1858969-1-m.tretter@pengutronix.de Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 8591ed3b6131f158640eb0273424d0dc9af5e701 Author: Dmitry Torokhov Date: Fri Feb 19 10:36:48 2021 -0800 Input: zinitix - fix return type of zinitix_init_touch() [ Upstream commit 836f308cb5c72d48e2dff8d3e64c3adb94f4710d ] zinitix_init_touch() returns error code or 0 for success and therefore return type must be int, not bool. Fixes: 26822652c85e ("Input: add zinitix touchscreen driver") Reported-by: kernel test robot Reported-by: Jiapeng Chong Link: https://lore.kernel.org/r/YC8z2bXc3Oy8pABa@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit a671777a9848efb7f30f2b8bb044b68a25a96e51 Author: Randy Dunlap Date: Mon Nov 16 16:48:00 2020 -0800 sparc: fix led.c driver when PROC_FS is not enabled [ Upstream commit b3554aa2470b5db1222c31e08ec9c29ab33eabc7 ] Fix Sparc build when CONFIG_PROC_FS is not enabled. Fixes this build error: arch/sparc/kernel/led.c:107:30: error: 'led_proc_ops' defined but not used [-Werror=unused-const-variable=] 107 | static const struct proc_ops led_proc_ops = { | ^~~~~~~~~~~~ cc1: all warnings being treated as errors Fixes: 97a32539b956 ("proc: convert everything to "struct proc_ops"") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Alexey Dobriyan Cc: Andrew Morton Cc: Lars Kotthoff Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 601962f58d59115d0c06d4209718890739f5b29f Author: Randy Dunlap Date: Wed Nov 25 16:40:11 2020 -0800 sparc64: only select COMPAT_BINFMT_ELF if BINFMT_ELF is set [ Upstream commit 80bddf5c93a99e11fc9faf7e4b575d01cecd45d3 ] Currently COMPAT on SPARC64 selects COMPAT_BINFMT_ELF unconditionally, even when BINFMT_ELF is not enabled. This causes a kconfig warning. Instead, just select COMPAT_BINFMT_ELF if BINFMT_ELF is enabled. This builds cleanly with no kconfig warnings. WARNING: unmet direct dependencies detected for COMPAT_BINFMT_ELF Depends on [n]: COMPAT [=y] && BINFMT_ELF [=n] Selected by [y]: - COMPAT [=y] && SPARC64 [=y] Fixes: 26b4c912185a ("sparc,sparc64: unify Kconfig files") Signed-off-by: Randy Dunlap Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Cc: Sam Ravnborg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 204c4cb7312ef2aaaa46f7341c5646270034d957 Author: Dan Carpenter Date: Tue Feb 16 20:29:05 2021 -0800 Input: elo - fix an error code in elo_connect() [ Upstream commit 0958351e93fa0ac142f6dd8bd844441594f30a57 ] If elo_setup_10() fails then this should return an error code instead of success. Fixes: fae3006e4b42 ("Input: elo - add support for non-pressure-sensitive touchscreens") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YBKFd5CvDu+jVmfW@mwanda Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit ebd9d13c3930d316c96e889ae911d4818dae9e50 Author: Namhyung Kim Date: Sun Feb 14 18:16:38 2021 +0900 perf test: Fix unaligned access in sample parsing test [ Upstream commit c5c97cadd7ed13381cb6b4bef5c841a66938d350 ] The ubsan reported the following error. It was because sample's raw data missed u32 padding at the end. So it broke the alignment of the array after it. The raw data contains an u32 size prefix so the data size should have an u32 padding after 8-byte aligned data. 27: Sample parsing :util/synthetic-events.c:1539:4: runtime error: store to misaligned address 0x62100006b9bc for type '__u64' (aka 'unsigned long long'), which requires 8 byte alignment 0x62100006b9bc: note: pointer points here 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ #0 0x561532a9fc96 in perf_event__synthesize_sample util/synthetic-events.c:1539:13 #1 0x5615327f4a4f in do_test tests/sample-parsing.c:284:8 #2 0x5615327f3f50 in test__sample_parsing tests/sample-parsing.c:381:9 #3 0x56153279d3a1 in run_test tests/builtin-test.c:424:9 #4 0x56153279c836 in test_and_print tests/builtin-test.c:454:9 #5 0x56153279b7eb in __cmd_test tests/builtin-test.c:675:4 #6 0x56153279abf0 in cmd_test tests/builtin-test.c:821:9 #7 0x56153264e796 in run_builtin perf.c:312:11 #8 0x56153264cf03 in handle_internal_command perf.c:364:8 #9 0x56153264e47d in run_argv perf.c:408:2 #10 0x56153264c9a9 in main perf.c:538:3 #11 0x7f137ab6fbbc in __libc_start_main (/lib64/libc.so.6+0x38bbc) #12 0x561532596828 in _start ... SUMMARY: UndefinedBehaviorSanitizer: misaligned-pointer-use util/synthetic-events.c:1539:4 in Fixes: 045f8cd8542d ("perf tests: Add a sample parsing test") Signed-off-by: Namhyung Kim Acked-by: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: Stephane Eranian Link: https://lore.kernel.org/r/20210214091638.519643-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 248b0472898c78e56ba771d04feadc6284704b8e Author: Adrian Hunter Date: Fri Feb 5 19:53:49 2021 +0200 perf intel-pt: Fix IPC with CYC threshold [ Upstream commit 6af4b60033e0ce0332fcdf256c965ad41942821a ] The code assumed every CYC-eligible packet has a CYC packet, which is not the case when CYC thresholds are used. Fix by checking if a CYC packet is actually present in that case. Fixes: 5b1dc0fd1da06 ("perf intel-pt: Add support for samples to contain IPC ratio") Signed-off-by: Adrian Hunter Reviewed-by: Andi Kleen Cc: Jiri Olsa Link: https://lore.kernel.org/r/20210205175350.23817-4-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f906a02170cd1aac9f8d732fd0947dac760e9ec4 Author: Adrian Hunter Date: Fri Feb 5 19:53:48 2021 +0200 perf intel-pt: Fix premature IPC [ Upstream commit 20aa39708a5999b7921b27482a756766272286ac ] The code assumed a change in cycle count means accurate IPC. That is not correct, for example when sampling both branches and instructions, or at a FUP packet (which is not CYC-eligible) address. Fix by using an explicit flag to indicate when IPC can be sampled. Fixes: 5b1dc0fd1da06 ("perf intel-pt: Add support for samples to contain IPC ratio") Signed-off-by: Adrian Hunter Reviewed-by: Andi Kleen Cc: Jiri Olsa Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20210205175350.23817-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bbf7207a6663b7b72be0978f82f15b9f2c2ce36b Author: Adrian Hunter Date: Fri Feb 5 19:53:47 2021 +0200 perf intel-pt: Fix missing CYC processing in PSB [ Upstream commit 03fb0f859b45d1eb05c984ab4bd3bef67e45ede2 ] Add missing CYC packet processing when walking through PSB+. This improves the accuracy of timestamps that follow PSB+, until the next MTC. Fixes: 3d49807870f08 ("perf tools: Add new Intel PT packet definitions") Signed-off-by: Adrian Hunter Reviewed-by: Andi Kleen Cc: Jiri Olsa Link: https://lore.kernel.org/r/20210205175350.23817-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 78aa786e3cdf0e28e8fb610d7d8122912a50f816 Author: Dave Rigby Date: Thu Feb 18 16:56:54 2021 +0000 perf unwind: Set userdata for all __report_module() paths [ Upstream commit 4e1481445407b86a483616c4542ffdc810efb680 ] When locating the DWARF module for a given address, __find_debuginfo() requires a 'struct dso' passed via the userdata argument. However, this field is only set in __report_module() if the module is found in via dwfl_addrmodule(), not if it is found later via dwfl_report_elf(). Set userdata irrespective of how the DWARF module was found, as long as we found a module. Fixes: bf53fc6b5f41 ("perf unwind: Fix separate debug info files when using elfutils' libdw's unwinder") Signed-off-by: Dave Rigby Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211801 Acked-by: Jan Kratochvil Acked-by: Jiri Olsa Link: https://lore.kernel.org/linux-perf-users/20210218165654.36604-1-d.rigby@me.com/ Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 613919261b6f5c49e23db8298a5d43060274474e Author: Yang Jihong Date: Fri Feb 5 14:50:01 2021 +0800 perf record: Fix continue profiling after draining the buffer [ Upstream commit e16c2ce7c5ed5de881066c1fd10ba5c09af69559 ] Commit da231338ec9c0987 ("perf record: Use an eventfd to wakeup when done") uses eventfd() to solve a rare race where the setting and checking of 'done' which add done_fd to pollfd. When draining buffer, revents of done_fd is 0 and evlist__filter_pollfd function returns a non-zero value. As a result, perf record does not stop profiling. The following simple scenarios can trigger this condition: # sleep 10 & # perf record -p $! After the sleep process exits, perf record should stop profiling and exit. However, perf record keeps running. If pollfd revents contains only POLLERR or POLLHUP, perf record indicates that buffer is draining and need to stop profiling. Use fdarray_flag__nonfilterable() to set done eventfd to nonfilterable objects, so that evlist__filter_pollfd() does not filter and check done eventfd. Fixes: da231338ec9c0987 ("perf record: Use an eventfd to wakeup when done") Signed-off-by: Yang Jihong Tested-by: Arnaldo Carvalho de Melo Tested-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: zhangjinhao2@huawei.com Link: http://lore.kernel.org/lkml/20210205065001.23252-1-yangjihong1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e98bd0390883b4685e8a58f7645506382d50fea3 Author: Dan Carpenter Date: Tue Feb 16 20:30:45 2021 -0800 Input: sur40 - fix an error code in sur40_probe() [ Upstream commit b0b7d2815839024e5181bd2572f5d8d4f65363b3 ] If v4l2_ctrl_handler_setup() fails then probe() should return an error code instead of returning success. Fixes: cee1e3e2ef39 ("media: add video control handlers using V4L2 control framework") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YBKFkbATXa5fA3xj@mwanda Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 3b9d36b71aa59139a1967da52745d41068278773 Author: Jack Wang Date: Tue Feb 16 15:38:07 2021 +0100 RDMA/rtrs-srv: Do not pass a valid pointer to PTR_ERR() [ Upstream commit ed408529679737a9a7ad816c8de5d59ba104bb11 ] smatch gives the warning: drivers/infiniband/ulp/rtrs/rtrs-srv.c:1805 rtrs_rdma_connect() warn: passing zero to 'PTR_ERR' Which is trying to say smatch has shown that srv is not an error pointer and thus cannot be passed to PTR_ERR. The solution is to move the list_add() down after full initilization of rtrs_srv. To avoid holding the srv_mutex too long, only hold it during the list operation as suggested by Leon. Fixes: 03e9b33a0fd6 ("RDMA/rtrs: Only allow addition of path to an already established session") Link: https://lore.kernel.org/r/20210216143807.65923-1-jinpu.wang@cloud.ionos.com Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a526f2abcece8512505c478f94917ec950b45f4b Author: Gioh Kim Date: Fri Feb 12 14:45:25 2021 +0100 RDMA/rtrs-srv-sysfs: fix missing put_device [ Upstream commit e2853c49477d104c01d3c7944e1fb5074eb11d9f ] put_device() decreases the ref-count and then the device will be cleaned-up, while at is also add missing put_device in rtrs_srv_create_once_sysfs_root_folders This patch solves a kmemleak error as below: unreferenced object 0xffff88809a7a0710 (size 8): comm "kworker/4:1H", pid 113, jiffies 4295833049 (age 6212.380s) hex dump (first 8 bytes): 62 6c 61 00 6b 6b 6b a5 bla.kkk. backtrace: [<0000000054413611>] kstrdup+0x2e/0x60 [<0000000078e3120a>] kobject_set_name_vargs+0x2f/0xb0 [<00000000f1a17a6b>] dev_set_name+0xab/0xe0 [<00000000d5502e32>] rtrs_srv_create_sess_files+0x2fb/0x314 [rtrs_server] [<00000000ed11a1ef>] rtrs_srv_info_req_done+0x631/0x800 [rtrs_server] [<000000008fc5aa8f>] __ib_process_cq+0x94/0x100 [ib_core] [<00000000a9599cb4>] ib_cq_poll_work+0x32/0xc0 [ib_core] [<00000000cfc376be>] process_one_work+0x4bc/0x980 [<0000000016e5c96a>] worker_thread+0x78/0x5c0 [<00000000c20b8be0>] kthread+0x191/0x1e0 [<000000006c9c0003>] ret_from_fork+0x3a/0x50 Fixes: baa5b28b7a47 ("RDMA/rtrs-srv: Replace device_register with device_initialize and device_add") Link: https://lore.kernel.org/r/20210212134525.103456-5-jinpu.wang@cloud.ionos.com Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f81a31cf727aa4de73a999637fed394a686f07ea Author: Gioh Kim Date: Fri Feb 12 14:45:24 2021 +0100 RDMA/rtrs-srv: fix memory leak by missing kobject free [ Upstream commit f7452a7e96c120d73100387d5f87de9fce7133cb ] kmemleak reported an error as below: unreferenced object 0xffff8880674b7640 (size 64): comm "kworker/4:1H", pid 113, jiffies 4296403507 (age 507.840s) hex dump (first 32 bytes): 69 70 3a 31 39 32 2e 31 36 38 2e 31 32 32 2e 31 ip:192.168.122.1 31 30 40 69 70 3a 31 39 32 2e 31 36 38 2e 31 32 10@ip:192.168.12 backtrace: [<0000000054413611>] kstrdup+0x2e/0x60 [<0000000078e3120a>] kobject_set_name_vargs+0x2f/0xb0 [<00000000ca2be3ee>] kobject_init_and_add+0xb0/0x120 [<0000000062ba5e78>] rtrs_srv_create_sess_files+0x14c/0x314 [rtrs_server] [<00000000b45b7217>] rtrs_srv_info_req_done+0x5b1/0x800 [rtrs_server] [<000000008fc5aa8f>] __ib_process_cq+0x94/0x100 [ib_core] [<00000000a9599cb4>] ib_cq_poll_work+0x32/0xc0 [ib_core] [<00000000cfc376be>] process_one_work+0x4bc/0x980 [<0000000016e5c96a>] worker_thread+0x78/0x5c0 [<00000000c20b8be0>] kthread+0x191/0x1e0 [<000000006c9c0003>] ret_from_fork+0x3a/0x50 It is caused by the not-freed kobject of rtrs_srv_sess. The kobject embedded in rtrs_srv_sess has ref-counter 2 after calling process_info_req(). Therefore it must call kobject_put twice. Currently it calls kobject_put only once at rtrs_srv_destroy_sess_files because kobject_del removes the state_in_sysfs flag and then kobject_put in free_sess() is not called. This patch moves kobject_del() into free_sess() so that the kobject of rtrs_srv_sess can be freed. And also this patch adds the missing call of sysfs_remove_group() to clean-up the sysfs directory. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20210212134525.103456-4-jinpu.wang@cloud.ionos.com Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a3740a078a9a82a2f069078e3bd395ccfbb6e0b3 Author: Md Haris Iqbal Date: Fri Feb 12 14:45:23 2021 +0100 RDMA/rtrs: Only allow addition of path to an already established session [ Upstream commit 03e9b33a0fd677f554b03352646c13459bf60458 ] While adding a path from the client side to an already established session, it was possible to provide the destination IP to a different server. This is dangerous. This commit adds an extra member to the rtrs_msg_conn_req structure, named first_conn; which is supposed to notify if the connection request is the first for that session or not. On the server side, if a session does not exist but the first_conn received inside the rtrs_msg_conn_req structure is 1, the connection request is failed. This signifies that the connection request is for an already existing session, and since the server did not find one, it is an wrong connection request. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20210212134525.103456-3-jinpu.wang@cloud.ionos.com Signed-off-by: Md Haris Iqbal Reviewed-by: Lutz Pogrell Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a8cf8ba6915043b2df7ff06f6b0e85261a41fd5b Author: Jack Wang Date: Fri Feb 12 14:45:22 2021 +0100 RDMA/rtrs-srv: Fix stack-out-of-bounds [ Upstream commit e6daa8f61d8def10f0619fe51b4c794f69598e4f ] BUG: KASAN: stack-out-of-bounds in _mlx4_ib_post_send+0x1bd2/0x2770 [mlx4_ib] Read of size 4 at addr ffff8880d5a7f980 by task kworker/0:1H/565 CPU: 0 PID: 565 Comm: kworker/0:1H Tainted: G O 5.4.84-storage #5.4.84-1+feature+linux+5.4.y+dbg+20201216.1319+b6b887b~deb10 Hardware name: Supermicro H8QG6/H8QG6, BIOS 3.00 09/04/2012 Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] Call Trace: dump_stack+0x96/0xe0 print_address_description.constprop.4+0x1f/0x300 ? irq_work_claim+0x2e/0x50 __kasan_report.cold.8+0x78/0x92 ? _mlx4_ib_post_send+0x1bd2/0x2770 [mlx4_ib] kasan_report+0x10/0x20 _mlx4_ib_post_send+0x1bd2/0x2770 [mlx4_ib] ? check_chain_key+0x1d7/0x2e0 ? _mlx4_ib_post_recv+0x630/0x630 [mlx4_ib] ? lockdep_hardirqs_on+0x1a8/0x290 ? stack_depot_save+0x218/0x56e ? do_profile_hits.isra.6.cold.13+0x1d/0x1d ? check_chain_key+0x1d7/0x2e0 ? save_stack+0x4d/0x80 ? save_stack+0x19/0x80 ? __kasan_slab_free+0x125/0x170 ? kfree+0xe7/0x3b0 rdma_write_sg+0x5b0/0x950 [rtrs_server] The problem is when we send imm_wr, the type should be ib_rdma_wr, so hw driver like mlx4 can do rdma_wr(wr), so fix it by use the ib_rdma_wr as type for imm_wr. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20210212134525.103456-2-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Reviewed-by: Gioh Kim Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a3262b3884dd67b4c5632ce7cdf9cff9d1a575d4 Author: Avihai Horon Date: Thu Feb 11 11:05:17 2021 +0200 RDMA/ucma: Fix use-after-free bug in ucma_create_uevent [ Upstream commit fe454dc31e84f8c14cb8942fcb61666c9f40745b ] ucma_process_join() allocates struct ucma_multicast mc and frees it if an error occurs during its run. Specifically, if an error occurs in copy_to_user(), a use-after-free might happen in the following scenario: 1. mc struct is allocated. 2. rdma_join_multicast() is called and succeeds. During its run, cma_iboe_join_multicast() enqueues a work that will later use the aforementioned mc struct. 3. copy_to_user() is called and fails. 4. mc struct is deallocated. 5. The work that was enqueued by cma_iboe_join_multicast() is run and calls ucma_create_uevent() which tries to access mc struct (which is freed by now). Fix this bug by cancelling the work enqueued by cma_iboe_join_multicast(). Since cma_work_handler() frees struct cma_work, we don't use it in cma_iboe_join_multicast() so we can safely cancel the work later. The following syzkaller report revealed it: BUG: KASAN: use-after-free in ucma_create_uevent+0x2dd/0x;3f0 drivers/infiniband/core/ucma.c:272 Read of size 8 at addr ffff88810b3ad110 by task kworker/u8:1/108 CPU: 1 PID: 108 Comm: kworker/u8:1 Not tainted 5.10.0-rc6+ #257 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: rdma_cm cma_work_handler Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xbe/0xf9 lib/dump_stack.c:118 print_address_description.constprop.0+0x3e/0×60 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0×37 mm/kasan/report.c:562 ucma_create_uevent+0x2dd/0×3f0 drivers/infiniband/core/ucma.c:272 ucma_event_handler+0xb7/0×3c0 drivers/infiniband/core/ucma.c:349 cma_cm_event_handler+0x5d/0×1c0 drivers/infiniband/core/cma.c:1977 cma_work_handler+0xfa/0×190 drivers/infiniband/core/cma.c:2718 process_one_work+0x54c/0×930 kernel/workqueue.c:2272 worker_thread+0x82/0×830 kernel/workqueue.c:2418 kthread+0x1ca/0×220 kernel/kthread.c:292 ret_from_fork+0x1f/0×30 arch/x86/entry/entry_64.S:296 Allocated by task 359: kasan_save_stack+0x1b/0×40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:461 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:434 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:664 [inline] ucma_process_join+0x16e/0×3f0 drivers/infiniband/core/ucma.c:1453 ucma_join_multicast+0xda/0×140 drivers/infiniband/core/ucma.c:1538 ucma_write+0x1f7/0×280 drivers/infiniband/core/ucma.c:1724 vfs_write fs/read_write.c:603 [inline] vfs_write+0x191/0×4c0 fs/read_write.c:585 ksys_write+0x1a1/0×1e0 fs/read_write.c:658 do_syscall_64+0x2d/0×40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 359: kasan_save_stack+0x1b/0×40 mm/kasan/common.c:48 kasan_set_track+0x1c/0×30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0×30 mm/kasan/generic.c:355 __kasan_slab_free+0x112/0×160 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1544 [inline] slab_free_freelist_hook mm/slub.c:1577 [inline] slab_free mm/slub.c:3142 [inline] kfree+0xb3/0×3e0 mm/slub.c:4124 ucma_process_join+0x22d/0×3f0 drivers/infiniband/core/ucma.c:1497 ucma_join_multicast+0xda/0×140 drivers/infiniband/core/ucma.c:1538 ucma_write+0x1f7/0×280 drivers/infiniband/core/ucma.c:1724 vfs_write fs/read_write.c:603 [inline] vfs_write+0x191/0×4c0 fs/read_write.c:585 ksys_write+0x1a1/0×1e0 fs/read_write.c:658 do_syscall_64+0x2d/0×40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff88810b3ad100 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 16 bytes inside of 192-byte region [ffff88810b3ad100, ffff88810b3ad1c0) Fixes: b5de0c60cc30 ("RDMA/cma: Fix use after free race in roce multicast join") Link: https://lore.kernel.org/r/20210211090517.1278415-1-leon@kernel.org Reported-by: Amit Matityahu Signed-off-by: Avihai Horon Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2826615a709af0b187108151196051f8708969f6 Author: Lang Cheng Date: Sun Feb 7 16:55:40 2021 +0800 RDMA/hns: Fixes missing error code of CMDQ [ Upstream commit 8f86e2eadac968200a6ab1d7074fc0f5cbc1e075 ] When posting a multi-descriptors command, the error code of previous failed descriptors may be rewrote to 0 by a later successful descriptor. Fixes: a04ff739f2a9 ("RDMA/hns: Add command queue support for hip08 RoCE driver") Link: https://lore.kernel.org/r/1612688143-28226-3-git-send-email-liweihang@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 19efec0286c57b26c163fbace0bc6c3936b8645c Author: Jeff Layton Date: Thu Dec 10 13:35:46 2020 -0500 ceph: fix flush_snap logic after putting caps [ Upstream commit 64f36da5625f7f9853b86750eaa89d499d16a2e9 ] A primary reason for skipping ceph_check_caps after putting the references was to avoid the locking in ceph_check_caps during a reconnect. __ceph_put_cap_refs can still call ceph_flush_snaps in that case though, and that takes many of the same inconvenient locks. Fix the logic in __ceph_put_cap_refs to skip flushing snaps when the skip_checking_caps flag is set. Fixes: e64f44a88465 ("ceph: skip checking caps when session reconnecting and releasing reqs") Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 4247a6a4aabfb833a483badd5cef1ce3aae8cbc6 Author: Chuck Lever Date: Tue Feb 9 10:48:57 2021 -0500 svcrdma: Hold private mutex while invoking rdma_accept() [ Upstream commit 0ac24c320c4d89a9de6ec802591398b8675c7b3c ] RDMA core mutex locking was restructured by commit d114c6feedfe ("RDMA/cma: Add missing locking to rdma_accept()") [Aug 2020]. When lock debugging is enabled, the RPC/RDMA server trips over the new lockdep assertion in rdma_accept() because it doesn't call rdma_accept() from its CM event handler. As a temporary fix, have svc_rdma_accept() take the handler_mutex explicitly. In the meantime, let's consider how to restructure the RPC/RDMA transport to invoke rdma_accept() from the proper context. Calls to svc_rdma_accept() are serialized with calls to svc_rdma_free() by the generic RPC server layer. Suggested-by: Jason Gunthorpe Link: https://lore.kernel.org/linux-rdma/20210209154014.GO4247@nvidia.com/ Fixes: d114c6feedfe ("RDMA/cma: Add missing locking to rdma_accept()") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 4d41f65efeec0a6da6088341203c81e49ebfcd90 Author: J. Bruce Fields Date: Wed Feb 3 11:42:13 2021 -0500 nfsd: register pernet ops last, unregister first [ Upstream commit bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 ] These pernet operations may depend on stuff set up or torn down in the module init/exit functions. And they may be called at any time in between. So it makes more sense for them to be the last to be registered in the init function, and the first to be unregistered in the exit function. In particular, without this, the drc slab is being destroyed before all the per-net drcs are shut down, resulting in an "Objects remaining in nfsd_drc on __kmem_cache_shutdown()" warning in exit_nfsd. Reported-by: Zhi Li Fixes: 3ba75830ce17 "nfsd4: drc containerization" Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit c0ea71f0d925eaff86939af5dfbb0c4e8ea859b7 Author: Nicholas Fraser Date: Wed Feb 10 14:18:02 2021 -0500 perf symbols: Fix return value when loading PE DSO [ Upstream commit 77771a97011fa9146ccfaf2983a3a2885dc57b6f ] The first time dso__load() was called on a PE file it always returned -1 error. This caused the first call to map__find_symbol() to always fail on a PE file so the first sample from each PE file always had symbol . Subsequent samples succeed however because the DSO is already loaded. This fixes dso__load() to return 0 when successfully loading a DSO with libbfd. Fixes: eac9a4342e5447ca ("perf symbols: Try reading the symbol table with libbfd") Signed-off-by: Nicholas Fraser Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Frank Ch. Eigler Cc: Huw Davies Cc: Ian Rogers Cc: Jiri Olsa Cc: Kim Phillips Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Remi Bernon Cc: Song Liu Cc: Tommi Rantala Cc: Ulrich Czekalla Link: http://lore.kernel.org/lkml/1671b43b-09c3-1911-dbf8-7f030242fbf7@codeweavers.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 13b6d107fdc9eecb6bf119c5e4ed96a0290555b8 Author: John Ogness Date: Thu Feb 11 18:37:52 2021 +0106 printk: avoid prb_first_valid_seq() where possible [ Upstream commit 13791c80b0cdf54d92fc54221cdf490683b109de ] If message sizes average larger than expected (more than 32 characters), the data_ring will wrap before the desc_ring. Once the data_ring wraps, it will start invalidating descriptors. These invalid descriptors hang around until they are eventually recycled when the desc_ring wraps. Readers do not care about invalid descriptors, but they still need to iterate past them. If the average message size is much larger than 32 characters, then there will be many invalid descriptors preceding the valid descriptors. The function prb_first_valid_seq() always begins at the oldest descriptor and searches for the first valid descriptor. This can be rather expensive for the above scenario. And, in fact, because of its heavy usage in /dev/kmsg, there have been reports of long delays and even RCU stalls. For code that does not need to search from the oldest record, replace prb_first_valid_seq() usage with prb_read_valid_*() functions, which provide a start sequence number to search from. Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer") Reported-by: kernel test robot Reported-by: J. Avila Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210211173152.1629-1-john.ogness@linutronix.de Signed-off-by: Sasha Levin commit 14fa5c211bd85162c841c3472101d05fec81ce4d Author: Nicolas Saenz Julienne Date: Thu Feb 11 19:08:20 2021 +0100 spi: Skip zero-length transfers in spi_transfer_one_message() [ Upstream commit b306320322c9cfaa465bc2c7367acf6072b1ac0e ] With the introduction of 26751de25d25 ("spi: bcm2835: Micro-optimise FIFO loops") it has become apparent that some users might initiate zero-length SPI transfers. A fact the micro-optimization omitted, and which turned out to cause crashes[1]. Instead of changing the micro-optimization itself, use a bigger hammer and skip zero-length transfers altogether for drivers using the default transfer_one_message() implementation. Reported-by: Phil Elwell Fixes: 26751de25d25 ("spi: bcm2835: Micro-optimise FIFO loops") Signed-off-by: Nicolas Saenz Julienne [1] https://github.com/raspberrypi/linux/issues/4100 Link: https://lore.kernel.org/r/20210211180820.25757-1-nsaenzjulienne@suse.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c4d83a1e356d04f7f4347438de8dab9b6dfa51b1 Author: Kees Cook Date: Thu Feb 11 12:37:14 2021 -0800 spi: dw: Avoid stack content exposure [ Upstream commit 386f771aad15dd535f2368b4adc9958c0160edd4 ] Since "data" is u32, &data is a "u32 *" type, which means pointer math will move in u32-sized steps. This was meant to be a byte offset, so cast &data to "char *" to aim the copy into the correct location. Seen with -Warray-bounds (and found by Coverity): In file included from ./include/linux/string.h:269, from ./arch/powerpc/include/asm/paca.h:15, from ./arch/powerpc/include/asm/current.h:13, from ./include/linux/mutex.h:14, from ./include/linux/notifier.h:14, from ./include/linux/clk.h:14, from drivers/spi/spi-dw-bt1.c:12: In function 'memcpy', inlined from 'dw_spi_bt1_dirmap_copy_from_map' at drivers/spi/spi-dw-bt1.c:87:3: ./include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset 4 is out of the bounds [0, 4] of object 'data' with type 'u32' {aka 'unsigned int'} [-Warray-bounds] 20 | #define __underlying_memcpy __builtin_memcpy | ^ ./include/linux/fortify-string.h:191:9: note: in expansion of macro '__underlying_memcpy' 191 | return __underlying_memcpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~ drivers/spi/spi-dw-bt1.c: In function 'dw_spi_bt1_dirmap_copy_from_map': drivers/spi/spi-dw-bt1.c:77:6: note: 'data' declared here 77 | u32 data; | ^~~~ Addresses-Coverity: CID 1497771 Out-of-bounds access Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Acked-by: Serge Semin Link: https://lore.kernel.org/r/20210211203714.1929862-1-keescook@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 33a7cb2d7814c4e9e80276449a38fbcf97b31bcb Author: Matti Vaittinen Date: Fri Feb 12 10:00:23 2021 +0200 regulator: bd718x7, bd71828, Fix dvs voltage levels [ Upstream commit c294554111a835598b557db789d9ad2379b512a2 ] The ROHM BD718x7 and BD71828 drivers support setting HW state specific voltages from device-tree. This is used also by various in-tree DTS files. These drivers do incorrectly try to compose bit-map using enum values. By a chance this works for first two valid levels having values 1 and 2 - but setting values for the rest of the levels do indicate capability of setting values for first levels as well. Luckily the regulators which support setting values for SUSPEND/LPSR do usually also support setting values for RUN and IDLE too - thus this has not been such a fatal issue. Fix this by defining the old enum values as bits and fixing the parsing code. This allows keeping existing IC specific drivers intact and only slightly changing the rohm-regulator.c Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7 specific parts") Signed-off-by: Matti Vaittinen Acked-by: Lee Jones Link: https://lore.kernel.org/r/20210212080023.GA880728@localhost.localdomain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b917e5a8625b369faf2754237caecb22bf254b83 Author: Dmitry Safonov <0x7f454c46@gmail.com> Date: Tue Feb 9 14:51:48 2021 +0000 perf symbols: Use (long) for iterator for bfd symbols [ Upstream commit 96de68fff5ded8833bf5832658cb43c54f86ff6c ] GCC (GCC) 8.4.0 20200304 fails to build perf with: : util/symbol.c: In function 'dso__load_bfd_symbols': : util/symbol.c:1626:16: error: comparison of integer expressions of different signednes : for (i = 0; i < symbols_count; ++i) { : ^ : util/symbol.c:1632:16: error: comparison of integer expressions of different signednes : while (i + 1 < symbols_count && : ^ : util/symbol.c:1637:13: error: comparison of integer expressions of different signednes : if (i + 1 < symbols_count && : ^ : cc1: all warnings being treated as errors It's unlikely that the symtable will be that big, but the fix is an oneliner and as perf has CORE_CFLAGS += -Wextra, which makes build to fail together with CORE_CFLAGS += -Werror Fixes: eac9a4342e54 ("perf symbols: Try reading the symbol table with libbfd") Signed-off-by: Dmitry Safonov Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Jacek Caban Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: Remi Bernon Link: http://lore.kernel.org/lkml/20210209145148.178702-1-dima@arista.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4e2cd6ac8cbfda84c4936ad6eb8dc29694cc6146 Author: Tom Zanussi Date: Mon Feb 1 13:48:15 2021 -0600 selftests/ftrace: Update synthetic event syntax errors [ Upstream commit b5734e997e1117afb479ffda500e36fa91aea3e8 ] Some of the synthetic event errors and positions have changed in the code - update those and add several more tests. Also add a runtime check to ensure that the kernel supports dynamic strings in synthetic events, which these tests require. Link: https://lkml.kernel.org/r/51402656433455baead34f068c6e9466b64df9c0.1612208610.git.zanussi@kernel.org Fixes: 81ff92a93d95 (selftests/ftrace: Add test case for synthetic event syntax errors) Reported-by: Masami Hiramatsu Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit f3780c9e5363f182bb9145d015d39b223a0f3974 Author: Ryan Chen Date: Tue Jan 19 14:17:15 2021 +0800 clk: aspeed: Fix APLL calculate formula from ast2600-A2 [ Upstream commit 6286ce1e3ece54799f12775f8ce2a1cba9cbcfc5 ] Starting from A2, the A-PLL calculation has changed. Use the existing formula for A0/A1 and the new formula for A2 onwards. Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC") Signed-off-by: Ryan Chen Link: https://lore.kernel.org/r/20210119061715.6043-1-ryan_chen@aspeedtech.com Reviewed-by: Joel Stanley Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e9cc34839e1791e8a872a4bec5d882c4f9ee380a Author: Jonathan Marek Date: Wed Feb 10 22:49:35 2021 -0500 regulator: qcom-rpmh: fix pm8009 ldo7 [ Upstream commit 20ccc362c3d20da734af896e075b74222589f2c0 ] Use the correct name to avoid ldo7 commands being sent to ldo6's address. Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Signed-off-by: Jonathan Marek Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20210211034935.5622-1-jonathan@marek.ca Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 37c3c0e07fc6a859a15c95b4e24b04eaa9638613 Author: Alexey Kardashevskiy Date: Tue Feb 2 20:15:41 2021 +1100 powerpc/kuap: Restore AMR after replaying soft interrupts [ Upstream commit 60a707d0c99aff4eadb7fd334c5fd21df386723e ] Since de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection"), user access helpers call user_{read|write}_access_{begin|end} when user space access is allowed. Commit 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU") made the mentioned helpers program a AMR special register to allow such access for a short period of time, most of the time AMR is expected to block user memory access by the kernel. Since the code accesses the user space memory, unsafe_get_user() calls might_fault() which calls arch_local_irq_restore() if either CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP is enabled. arch_local_irq_restore() then attempts to replay pending soft interrupts as KUAP regions have hardware interrupts enabled. If a pending interrupt happens to do user access (performance interrupts do that), it enables access for a short period of time so after returning from the replay, the user access state remains blocked and if a user page fault happens - "Bug: Read fault blocked by AMR!" appears and SIGSEGV is sent. An example trace: Bug: Read fault blocked by AMR! WARNING: CPU: 0 PID: 1603 at /home/aik/p/kernel/arch/powerpc/include/asm/book3s/64/kup-radix.h:145 CPU: 0 PID: 1603 Comm: amr Not tainted 5.10.0-rc6_v5.10-rc6_a+fstn1 #24 NIP: c00000000009ece8 LR: c00000000009ece4 CTR: 0000000000000000 REGS: c00000000dc63560 TRAP: 0700 Not tainted (5.10.0-rc6_v5.10-rc6_a+fstn1) MSR: 8000000000021033 CR: 28002888 XER: 20040000 CFAR: c0000000001fa928 IRQMASK: 1 GPR00: c00000000009ece4 c00000000dc637f0 c000000002397600 000000000000001f GPR04: c0000000020eb318 0000000000000000 c00000000dc63494 0000000000000027 GPR08: c00000007fe4de68 c00000000dfe9180 0000000000000000 0000000000000001 GPR12: 0000000000002000 c0000000030a0000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 bfffffffffffffff GPR20: 0000000000000000 c0000000134a4020 c0000000019c2218 0000000000000fe0 GPR24: 0000000000000000 0000000000000000 c00000000d106200 0000000040000000 GPR28: 0000000000000000 0000000000000300 c00000000dc63910 c000000001946730 NIP __do_page_fault+0xb38/0xde0 LR __do_page_fault+0xb34/0xde0 Call Trace: __do_page_fault+0xb34/0xde0 (unreliable) handle_page_fault+0x10/0x2c --- interrupt: 300 at strncpy_from_user+0x290/0x440 LR = strncpy_from_user+0x284/0x440 strncpy_from_user+0x2f0/0x440 (unreliable) getname_flags+0x88/0x2c0 do_sys_openat2+0x2d4/0x5f0 do_sys_open+0xcc/0x140 system_call_exception+0x160/0x240 system_call_common+0xf0/0x27c To fix it save/restore the AMR when replaying interrupts, and also add a check if AMR was not blocked prior to replaying interrupts. Originally found by syzkaller. Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU") Signed-off-by: Alexey Kardashevskiy Reviewed-by: Nicholas Piggin [mpe: Use normal commit citation format and add full oops log to change log, move kuap_check_amr() into the restore routine to avoid warnings about unreconciled IRQ state] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210202091541.36499-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit ecd72a9a8b7d3aeb124df32bd43ca7dfdaaf9843 Author: Alexey Kardashevskiy Date: Mon Feb 8 16:57:40 2021 +1100 powerpc/uaccess: Avoid might_fault() when user access is enabled [ Upstream commit 7d506ca97b665b95e698a53697dad99fae813c1a ] The amount of code executed with enabled user space access (unlocked KUAP) should be minimal. However with CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP enabled, might_fault() calls into various parts of the kernel, and may even end up replaying interrupts which in turn may access user space and forget to restore the KUAP state. The problem places are: 1. strncpy_from_user (and similar) which unlock KUAP and call unsafe_get_user -> __get_user_allowed -> __get_user_nocheck() with do_allow=false to skip KUAP as the caller took care of it. 2. __unsafe_put_user_goto() which is called with unlocked KUAP. eg: WARNING: CPU: 30 PID: 1 at arch/powerpc/include/asm/book3s/64/kup.h:324 arch_local_irq_restore+0x160/0x190 NIP arch_local_irq_restore+0x160/0x190 LR lock_is_held_type+0x140/0x200 Call Trace: 0xc00000007f392ff8 (unreliable) ___might_sleep+0x180/0x320 __might_fault+0x50/0xe0 filldir64+0x2d0/0x5d0 call_filldir+0xc8/0x180 ext4_readdir+0x948/0xb40 iterate_dir+0x1ec/0x240 sys_getdents64+0x80/0x290 system_call_exception+0x160/0x280 system_call_common+0xf0/0x27c Change __get_user_nocheck() to look at `do_allow` to decide whether to skip might_fault(). Since strncpy_from_user/etc call might_fault() anyway before unlocking KUAP, there should be no visible change. Drop might_fault() in __unsafe_put_user_goto() as it is only called from unsafe_put_user(), which already has KUAP unlocked. Since keeping might_fault() is still desirable for debugging, add calls to it in user_[read|write]_access_begin(). That also allows us to drop the is_kernel_addr() test, because there should be no code using user_[read|write]_access_begin() in order to access a kernel address. Fixes: de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection") Signed-off-by: Alexey Kardashevskiy [mpe: Combine with related patch from myself, merge change logs] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210204121612.32721-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit a031ba877eb58a44af0210c0958831bfda053444 Author: Andy Shevchenko Date: Mon Feb 8 18:38:15 2021 +0200 spi: pxa2xx: Fix the controller numbering for Wildcat Point [ Upstream commit 54c5d3bfb0cfb7b31259765524567871dee11615 ] Wildcat Point has two SPI controllers and added one is actually second one. Fix the numbering by adding the description of the first one. Fixes: caba248db286 ("spi: spi-pxa2xx-pci: Add ID and driver type for WildcatPoint PCH") Cc: Leif Liddy Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210208163816.22147-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4080ba03f38cfb057601e3052d44e2f6eb939533 Author: Michael Tretter Date: Thu Jan 21 08:16:46 2021 +0100 clk: divider: fix initialization with parent_hw [ Upstream commit 0225daea08141b1dff681502d5af70b71e8b11ec ] If a driver registers a divider clock with a parent_hw instead of the parent_name, the parent_hw is ignored and the clock does not have a parent. Fix this by initializing the parents the same way they are initialized for clock gates. Fixes: ff258817137a ("clk: divider: Add support for specifying parents via DT/pointers") Signed-off-by: Michael Tretter Reviewed-by: Stephen Boyd Acked-by: Michal Simek Link: https://lore.kernel.org/r/20210121071659.1226489-3-m.tretter@pengutronix.de Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 67c71a22bd340dabfb331d6c1b4f2b6327f27bf0 Author: Lijun Ou Date: Fri Feb 5 17:39:26 2021 +0800 RDMA/hns: Disable RQ inline by default [ Upstream commit 7373de9adb19aebed2781d3fdde576533d626d7a ] This feature should only be enabled by querying capability from firmware. Fixes: ba6bb7e97421 ("RDMA/hns: Add interfaces to get pf capabilities from firmware") Link: https://lore.kernel.org/r/1612517974-31867-5-git-send-email-liweihang@huawei.com Signed-off-by: Lijun Ou Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit fce1063a755fbb4a96790b5327a140144b4270fe Author: Xi Wang Date: Fri Feb 5 17:39:25 2021 +0800 RDMA/hns: Add mapped page count checking for MTR [ Upstream commit 9ea9a53ea93be1cc66729ceb920f0d07285d6bfd ] Add the mapped page count checking flow to avoid invalid page size when creating MTR. Fixes: 38389eaa4db1 ("RDMA/hns: Add mtr support for mixed multihop addressing") Link: https://lore.kernel.org/r/1612517974-31867-4-git-send-email-liweihang@huawei.com Signed-off-by: Xi Wang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit fdfb08adc8628fa72afd327623c065b36e5a9793 Author: Weihang Li Date: Fri Feb 5 17:39:24 2021 +0800 RDMA/hns: Fix type of sq_signal_bits [ Upstream commit ea4092f3b56b236d08890ea589506ebd76248c53 ] This bit should be in type of enum ib_sig_type, or there will be a sparse warning. Fixes: bfe860351e31 ("RDMA/hns: Fix cast from or to restricted __le32 for driver") Link: https://lore.kernel.org/r/1612517974-31867-3-git-send-email-liweihang@huawei.com Reported-by: kernel test robot Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit aa26140e79370fbbf93c799499c1107b0b26bcbb Author: Weihang Li Date: Fri Feb 5 17:39:23 2021 +0800 RDMA/hns: Avoid filling sgid index when modifying QP to RTR [ Upstream commit 773f841ab1aeb0134e3872eb3545592732db8218 ] ULP usually set IB(V)_QP_AV when trying to modify QP to RTR if they want to record sgid index into QPC. For UD QPs, it is useless because it will be included in WQE. For RC QPs, it will be filled in hns_roce_set_path(). So sgid index shouldn't be filled by default. Then hns_get_gid_index() is moved to hns_roce_hw_v1.c because it is only called in it. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1612517974-31867-2-git-send-email-liweihang@huawei.com Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a31c8f42ce99cfb4f5f3c740142a4251cce1368a Author: Kamal Heib Date: Mon Feb 1 13:29:22 2021 +0200 RDMA/siw: Fix calculation of tx_valid_cpus size [ Upstream commit 429fa9698957d1a910535ce5e33aedf5adfdabc1 ] The size of tx_valid_cpus was calculated under the assumption that the numa nodes identifiers are continuous, which is not the case in all archs as this could lead to the following panic when trying to access an invalid tx_valid_cpus index, avoid the following panic by using nr_node_ids instead of num_online_nodes() to allocate the tx_valid_cpus size. Kernel attempted to read user page (8) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000008 Faulting instruction address: 0xc0080000081b4a90 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: siw(+) rfkill rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm sunrpc ib_umad rdma_cm ib_cm iw_cm i40iw ib_uverbs ib_core i40e ses enclosure scsi_transport_sas ipmi_powernv ibmpowernv at24 ofpart ipmi_devintf regmap_i2c ipmi_msghandler powernv_flash uio_pdrv_genirq uio mtd opal_prd zram ip_tables xfs libcrc32c sd_mod t10_pi ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm vmx_crypto aacraid drm_panel_orientation_quirks dm_mod CPU: 40 PID: 3279 Comm: modprobe Tainted: G W X --------- --- 5.11.0-0.rc4.129.eln108.ppc64le #2 NIP: c0080000081b4a90 LR: c0080000081b4a2c CTR: c0000000007ce1c0 REGS: c000000027fa77b0 TRAP: 0300 Tainted: G W X --------- --- (5.11.0-0.rc4.129.eln108.ppc64le) MSR: 9000000002009033 CR: 44224882 XER: 00000000 CFAR: c0000000007ce200 DAR: 0000000000000008 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000081b4a2c c000000027fa7a50 c0080000081c3900 0000000000000040 GPR04: c000000002023080 c000000012e1c300 000020072ad70000 0000000000000001 GPR08: c000000001726068 0000000000000008 0000000000000008 c0080000081b5758 GPR12: c0000000007ce1c0 c0000007fffc3000 00000001590b1e40 0000000000000000 GPR16: 0000000000000000 0000000000000001 000000011ad68fc8 00007fffcc09c5c8 GPR20: 0000000000000008 0000000000000000 00000001590b2850 00000001590b1d30 GPR24: 0000000000043d68 000000011ad67a80 000000011ad67a80 0000000000100000 GPR28: c000000012e1c300 c0000000020271c8 0000000000000001 c0080000081bf608 NIP [c0080000081b4a90] siw_init_cpulist+0x194/0x214 [siw] LR [c0080000081b4a2c] siw_init_cpulist+0x130/0x214 [siw] Call Trace: [c000000027fa7a50] [c0080000081b4a2c] siw_init_cpulist+0x130/0x214 [siw] (unreliable) [c000000027fa7a90] [c0080000081b4e68] siw_init_module+0x40/0x2a0 [siw] [c000000027fa7b30] [c0000000000124f4] do_one_initcall+0x84/0x2e0 [c000000027fa7c00] [c000000000267ffc] do_init_module+0x7c/0x350 [c000000027fa7c90] [c00000000026a180] __do_sys_init_module+0x210/0x250 [c000000027fa7db0] [c0000000000387e4] system_call_exception+0x134/0x230 [c000000027fa7e10] [c00000000000d660] system_call_common+0xf0/0x27c Instruction dump: 40810044 3d420000 e8bf0000 e88a82d0 3d420000 e90a82c8 792a1f24 7cc4302a 7d2642aa 79291f24 7d25482a 7d295214 <7d4048a8> 7d4a3b78 7d4049ad 40c2fff4 Fixes: bdcf26bf9b3a ("rdma/siw: network and RDMA core interface") Link: https://lore.kernel.org/r/20210201112922.141085-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Reviewed-by: Bernard Metzler Tested-by: Yi Zhang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7ba39fceb055da3cb06588c51a18beee98933d34 Author: Wenpeng Liang Date: Sat Jan 30 16:58:03 2021 +0800 RDMA/hns: Remove the reserved WQE of SRQ [ Upstream commit 6ee00fbf733d7e17ca935e5636adfce605b10659 ] Each SRQs contain an reserved WQE, it is inappropriate and should be removed. Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1611997090-48820-6-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 794b1eb6750559dcbe8b4cd4e4cac5710ca0ae23 Author: Wenpeng Liang Date: Sat Jan 30 16:58:02 2021 +0800 RDMA/hns: Fixed wrong judgments in the goto branch [ Upstream commit bb74fe7e81c8b2b65c6a351a247fdb9a969cbaec ] When an error occurs, the qp_table must be cleared, regardless of whether the SRQ feature is enabled. Fixes: 5c1f167af112 ("RDMA/hns: Init SRQ table for hip08") Link: https://lore.kernel.org/r/1611997090-48820-5-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit aed46ff85eb1cf4d2ceacaa2f0b878574e12a30e Author: Wenpeng Liang Date: Sat Jan 30 16:58:01 2021 +0800 RDMA/hns: Force srq_limit to 0 when creating SRQ [ Upstream commit b5df9b7a2f965b7903850d8f89846ffe0080b84b ] According to the IB Specification, srq_limit shouldn't be configured during SRQ creation. If a user set srq_limit at this time, the driver should forced it to zero, or the result of creating SRQ will conflict with the result of querying SRQ. Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1611997090-48820-4-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5a5056a400e7081465933e11b2b7c617928fe456 Author: Wenpeng Liang Date: Sat Jan 30 16:58:00 2021 +0800 RDMA/hns: Bugfix for checking whether the srq is full when post wr [ Upstream commit 1620f09b96ec14c1ff1ff64ee0aeabc027c653d5 ] If a user posts WR by wr_list, the head pointer of idx_queue won't be updated until all wqes are filled, so the judgment of whether head equals to tail will get a wrong result. Fix above issue and move the head and tail pointer from the srq structure into the idx_queue structure. After idx_queue is filled with wqe idx, the head pointer of it will increase. Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Link: https://lore.kernel.org/r/1611997090-48820-3-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 63d8526e288b81c9f62cb1680c8d5f8f85d2c36e Author: Lang Cheng Date: Sat Jan 30 16:57:59 2021 +0800 RDMA/hns: Allocate one more recv SGE for HIP08 [ Upstream commit 9dd052474a2645b2a6171d19ad17b05b180d446d ] The RQ/SRQ of HIP08 needs one special sge to stop receive reliably. So the driver needs to allocate at least one SGE when creating RQ/SRQ and ensure that at least one SGE is filled with the special value during post_recv. Besides, the kernel driver should only do this for kernel ULP. For userspace ULP, the userspace driver will allocate the reserved SGE in buffer, and the kernel driver just needs to pin the corresponding size of memory based on the userspace driver's requirements. Link: https://lore.kernel.org/r/1611997090-48820-2-git-send-email-liweihang@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d33ca3872e94e2263d62a24316fbb1fd1a688183 Author: John Stultz Date: Fri Jan 29 03:05:10 2021 +0000 kselftests: dmabuf-heaps: Fix Makefile's inclusion of the kernel's usr/include dir [ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ] Copied in from somewhere else, the makefile was including the kerne's usr/include dir, which caused the asm/ioctl.h file to be used. Unfortunately, that file has different values for _IOC_SIZEBITS and _IOC_WRITE than include/uapi/asm-generic/ioctl.h which then causes the _IOCW macros to give the wrong ioctl numbers, specifically for DMA_BUF_IOCTL_SYNC. This patch simply removes the extra include from the Makefile Cc: Shuah Khan Cc: Brian Starkey Cc: Sumit Semwal Cc: Laura Abbott Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-kselftest@vger.kernel.org Fixes: a8779927fd86c ("kselftests: Add dma-heap test") Signed-off-by: John Stultz Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit bde59afb0f5e10940466169a97c118662e8291bb Author: Daniel Latypov Date: Wed Dec 2 11:08:21 2020 -0800 kunit: tool: fix unit test cleanup handling [ Upstream commit cfd607e43da4a20753744f134e201310262b827a ] * Stop leaking file objects. * Use self.addCleanup() to ensure we call cleanup functions even if setUp() fails. * use mock.patch.stopall instead of more error-prone manual approach Signed-off-by: Daniel Latypov Reviewed-by: David Gow Tested-by: Brendan Higgins Acked-by: Brendan Higgins Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 4863b496e0229caddfc32958a39977b99a07d8e2 Author: AngeloGioacchino Del Regno Date: Thu Jan 14 23:10:54 2021 +0100 clk: qcom: gcc-msm8998: Fix Alpha PLL type for all GPLLs [ Upstream commit 292f75ecff07e8a07fe2e3e19b4b567d0b698842 ] All of the GPLLs in the MSM8998 Global Clock Controller are Fabia PLLs and not generic alphas: this was producing bad effects over the entire clock tree of MSM8998, where any GPLL child clock was declaring a false clock rate, due to their parent also showing the same. The issue resides in the calculation of the clock rate for the specific Alpha PLL type, where Fabia has a different register layout; switching the MSM8998 GPLLs to the correct Alpha Fabia PLL type fixes the rate (calculation) reading. While at it, also make these PLLs fixed since their rate is supposed to *never* be changed while the system runs, as this would surely crash the entire SoC. Now all the children of all the PLLs are also complying with their specified clock table and system stability is improved. Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20210114221059.483390-7-angelogioacchino.delregno@somainline.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 262df9685e6a4f365279583ed934086bfc6fca78 Author: Taniya Das Date: Wed Jan 20 13:17:51 2021 +0530 clk: qcom: gcc-sc7180: Mark the MM XO clocks to be always ON [ Upstream commit d79dfa19ca4235c28be62952bda6091babdcf8f3 ] There are intermittent GDSC power-up failures observed for titan top gdsc, which requires the XO clock. Thus mark all the MM XO clocks always enabled from probe. Fixes: 8d4025943e13 ("clk: qcom: camcc-sc7180: Use runtime PM ops instead of clk ones") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1611128871-5898-1-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit ca171daaf4fa503e86922b445a2eaf07644dc993 Author: Srinivas Kandagatla Date: Tue Jan 19 11:38:51 2021 +0000 clk: qcom: gfm-mux: fix clk mask [ Upstream commit 78ddb79cab178534b2c1d9ab95823f2af882ee8e ] For some reason global GFM_MASK ended up with bit 1 instead of bit 0. Remove the global GFM_MASK and reuse mux_mask field. Fixes: a2d8f507803e ("clk: qcom: Add support to LPASS AUDIO_CC Glitch Free Mux clocks") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210119113851.18946-1-srinivas.kandagatla@linaro.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 0e6abd5f98786e2c4e5f34986688b9f360110a78 Author: Sandipan Das Date: Thu Feb 4 13:37:44 2021 +0530 powerpc/sstep: Fix darn emulation [ Upstream commit 22b89ba178dd0a66a26699ead014a3e73ff8e044 ] Commit 8813ff49607e ("powerpc/sstep: Check instruction validity against ISA version before emulation") introduced a proper way to skip unknown instructions. This makes sure that the same is used for the darn instruction when the range selection bits have a reserved value. Fixes: a23987ef267a ("powerpc: sstep: Add support for darn instruction") Signed-off-by: Sandipan Das Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210204080744.135785-2-sandipan@linux.ibm.com Signed-off-by: Sasha Levin commit 58cd0d2faf0956ef99e78bea7a7ae2a1b3fbb18e Author: Sandipan Das Date: Thu Feb 4 13:37:43 2021 +0530 powerpc/sstep: Fix load-store and update emulation [ Upstream commit bbda4b6c7d7c7f79da71f95c92a5d76be22c3efd ] The Power ISA says that the fixed-point load and update instructions must neither use R0 for the base address (RA) nor have the destination (RT) and the base address (RA) as the same register. Similarly, for fixed-point stores and floating-point loads and stores, the instruction is invalid when R0 is used as the base address (RA). This is applicable to the following instructions. * Load Byte and Zero with Update (lbzu) * Load Byte and Zero with Update Indexed (lbzux) * Load Halfword and Zero with Update (lhzu) * Load Halfword and Zero with Update Indexed (lhzux) * Load Halfword Algebraic with Update (lhau) * Load Halfword Algebraic with Update Indexed (lhaux) * Load Word and Zero with Update (lwzu) * Load Word and Zero with Update Indexed (lwzux) * Load Word Algebraic with Update Indexed (lwaux) * Load Doubleword with Update (ldu) * Load Doubleword with Update Indexed (ldux) * Load Floating Single with Update (lfsu) * Load Floating Single with Update Indexed (lfsux) * Load Floating Double with Update (lfdu) * Load Floating Double with Update Indexed (lfdux) * Store Byte with Update (stbu) * Store Byte with Update Indexed (stbux) * Store Halfword with Update (sthu) * Store Halfword with Update Indexed (sthux) * Store Word with Update (stwu) * Store Word with Update Indexed (stwux) * Store Doubleword with Update (stdu) * Store Doubleword with Update Indexed (stdux) * Store Floating Single with Update (stfsu) * Store Floating Single with Update Indexed (stfsux) * Store Floating Double with Update (stfdu) * Store Floating Double with Update Indexed (stfdux) E.g. the following behaviour is observed for an invalid load and update instruction having RA = RT. While a userspace program having an instruction word like 0xe9ce0001, i.e. ldu r14, 0(r14), runs without getting receiving a SIGILL on a Power system (observed on P8 and P9), the outcome of executing that instruction word varies and its behaviour can be considered to be undefined. Attaching an uprobe at that instruction's address results in emulation which currently performs the load as well as writes the effective address back to the base register. This might not match the outcome from hardware. To remove any inconsistencies, this adds additional checks for the aforementioned instructions to make sure that the emulation infrastructure treats them as unknown. The kernel can then fallback to executing such instructions on hardware. Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()") Signed-off-by: Sandipan Das Reviewed-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210204080744.135785-1-sandipan@linux.ibm.com Signed-off-by: Sasha Levin commit 0c3a1bec8275fe29fb8c6cf32cab836d42d3bb63 Author: Christophe Leroy Date: Fri Feb 5 08:56:13 2021 +0000 powerpc/8xx: Fix software emulation interrupt [ Upstream commit 903178d0ce6bb30ef80a3604ab9ee2b57869fbc9 ] For unimplemented instructions or unimplemented SPRs, the 8xx triggers a "Software Emulation Exception" (0x1000). That interrupt doesn't set reason bits in SRR1 as the "Program Check Exception" does. Go through emulation_assist_interrupt() to set REASON_ILLEGAL. Fixes: fbbcc3bb139e ("powerpc/8xx: Remove SoftwareEmulation()") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/ad782af87a222efc79cfb06079b0fd23d4224eaf.1612515180.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 6fb4165dd9e23ef73fc803bd126249f3c121ae6d Author: Nathan Lynch Date: Wed Jan 6 20:59:00 2021 -0600 powerpc/pseries/dlpar: handle ibm, configure-connector delay status [ Upstream commit 768d70e19ba525debd571b36e6d0ab19956c63d7 ] dlpar_configure_connector() has two problems in its handling of ibm,configure-connector's return status: 1. When the status is -2 (busy, call again), we call ibm,configure-connector again immediately without checking whether to schedule, which can result in monopolizing the CPU. 2. Extended delay status (9900..9905) goes completely unhandled, causing the configuration to unnecessarily terminate. Fix both of these issues by using rtas_busy_delay(). Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure") Signed-off-by: Nathan Lynch Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210107025900.410369-1-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 0caff2c7df324305157f94eacbc35a79e99673b3 Author: Dan Carpenter Date: Fri Jan 29 17:37:24 2021 +0300 mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq() [ Upstream commit 26783d74cc6a440ee3ef9836a008a697981013d0 ] The "req" struct is always added to the "wm831x->auxadc_pending" list, but it's only removed from the list on the success path. If a failure occurs then the "req" struct is freed but it's still on the list, leading to a use after free. Fixes: 78bb3688ea18 ("mfd: Support multiple active WM831x AUXADC conversions") Signed-off-by: Dan Carpenter Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2530c2fcd5706ae15ea277853a5c6df1d37b3372 Author: Arnd Bergmann Date: Thu Dec 3 23:52:48 2020 +0100 mfd: altera-sysmgr: Fix physical address storing more [ Upstream commit b0b5b16b78cea1b2b990a69ab8e07a42ccf7a2ed ] A recent fix improved the way the resource gets passed to the low-level accessors, but left one warning that appears in configurations with a resource_size_t that is wider than a pointer: In file included from drivers/mfd/altera-sysmgr.c:19: drivers/mfd/altera-sysmgr.c: In function 'sysmgr_probe': drivers/mfd/altera-sysmgr.c:148:40: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 148 | regmap = devm_regmap_init(dev, NULL, (void *)res->start, | ^ include/linux/regmap.h:646:6: note: in definition of macro '__regmap_lockdep_wrapper' 646 | fn(__VA_ARGS__, &_key, \ | ^~~~~~~~~~~ drivers/mfd/altera-sysmgr.c:148:12: note: in expansion of macro 'devm_regmap_init' 148 | regmap = devm_regmap_init(dev, NULL, (void *)res->start, | ^~~~~~~~~~~~~~~~ I had tried a different approach that would store the address in the private data as a phys_addr_t, but the easiest solution now seems to be to add a double cast to shut up the warning. As the address is passed to an inline assembly, it is guaranteed to not be wider than a register anyway. Fixes: d9ca7801b6e5 ("mfd: altera-sysmgr: Fix physical address storing hacks") Signed-off-by: Arnd Bergmann Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3bf69497bba16303b0f1406b7d291383b4559908 Author: Alain Volmat Date: Fri Feb 5 19:59:25 2021 +0100 spi: stm32: properly handle 0 byte transfer [ Upstream commit 2269f5a8b1a7b38651d62676b98182828f29d11a ] On 0 byte transfer request, return straight from the xfer function after finalizing the transfer. Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller") Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1612551572-495-2-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15f5f83198e6d37229815177dc1f2316a5fa7c20 Author: Bob Pearson Date: Thu Jan 28 12:23:02 2021 -0600 RDMA/rxe: Correct skb on loopback path [ Upstream commit 5120bf0a5fc15dec210a0fe0f39e4a256bb6e349 ] rxe_net.c sends packets at the IP layer with skb->data pointing at the IP header but receives packets from a UDP tunnel with skb->data pointing at the UDP header. On the loopback path this was not correctly accounted for. This patch corrects for this by using sbk_pull() to strip the IP header from the skb on received packets. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210128182301.16859-1-rpearson@hpe.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 079cebab8e72999b60b276e75537ca84556d58d9 Author: Bob Pearson Date: Thu Jan 28 11:47:53 2021 -0600 RDMA/rxe: Fix coding error in rxe_rcv_mcast_pkt [ Upstream commit 8fc1b7027fc162738d5a85c82410e501a371a404 ] rxe_rcv_mcast_pkt() in rxe_recv.c can leak SKBs in error path code. The loop over the QPs attached to a multicast group creates new cloned SKBs for all but the last QP in the list and passes the SKB and its clones to rxe_rcv_pkt() for further processing. Any QPs that do not pass some checks are skipped. If the last QP in the list fails the tests the SKB is leaked. This patch checks if the SKB for the last QP was used and if not frees it. Also removes a redundant loop invariant assignment. Fixes: 8700e3e7c485 ("Soft RoCE driver") Fixes: 71abf20b28ff ("RDMA/rxe: Handle skb_clone() failure in rxe_recv.c") Link: https://lore.kernel.org/r/20210128174752.16128-1-rpearson@hpe.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a6d7a13507b9a8899315fcabf924531ffaaa12a8 Author: Bob Pearson Date: Wed Jan 27 15:45:01 2021 -0600 RDMA/rxe: Fix coding error in rxe_recv.c [ Upstream commit 7d9ae80e31df57dd3253e1ec514f0000aa588a81 ] check_type_state() in rxe_recv.c is written as if the type bits in the packet opcode were a bit mask which is not correct. This patch corrects this code to compare all 3 type bits to the required type. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210127214500.3707-1-rpearson@hpe.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8feb101bf9278dc12cef98b2f844c67d37e9c767 Author: John Garry Date: Thu Jan 28 20:00:33 2021 +0800 perf vendor events arm64: Fix Ampere eMag event typo [ Upstream commit 2bf797be81fa808f05f1a7a65916619132256a27 ] The "briefdescription" for event 0x35 has a typo - fix it. Fixes: d35c595bf005 ("perf vendor events arm64: Revise core JSON events for eMAG") Signed-off-by: John Garry Acked-by: Will Deacon Cc: James Clark Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: Mathieu Poirier Cc: Nakamura, Shunsuke/中村 俊介 Cc: linux-arm-kernel@lists.infradead.org Cc: linuxarm@openeuler.org Link: https://lore.kernel.org/r/1611835236-34696-2-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f1daa84254be17e46a504d280db09683903156d8 Author: Arnaldo Carvalho de Melo Date: Thu Jan 28 09:52:47 2021 -0300 perf tools: Fix DSO filtering when not finding a map for a sampled address [ Upstream commit c69bf11ad3d30b6bf01cfa538ddff1a59467c734 ] When we lookup an address and don't find a map we should filter that sample if the user specified a list of --dso entries to filter on, fix it. Before: $ perf script sleep 274800 2843.556162: 1 cycles:u: ffffffffbb26bff4 [unknown] ([unknown]) sleep 274800 2843.556168: 1 cycles:u: ffffffffbb2b047d [unknown] ([unknown]) sleep 274800 2843.556171: 1 cycles:u: ffffffffbb2706b2 [unknown] ([unknown]) sleep 274800 2843.556174: 6 cycles:u: ffffffffbb2b0267 [unknown] ([unknown]) sleep 274800 2843.556176: 59 cycles:u: ffffffffbb2b03b1 [unknown] ([unknown]) sleep 274800 2843.556180: 691 cycles:u: ffffffffbb26bff4 [unknown] ([unknown]) sleep 274800 2843.556189: 9160 cycles:u: 7fa9550eeaa3 __GI___tunables_init+0xf3 (/usr/lib64/ld-2.32.so) sleep 274800 2843.556312: 86937 cycles:u: 7fa9550e157b _dl_lookup_symbol_x+0x4b (/usr/lib64/ld-2.32.so) $ So we have some samples we somehow didn't find in a map for, if we now do: $ perf report --stdio --dso /usr/lib64/ld-2.32.so # dso: /usr/lib64/ld-2.32.so # # Total Lost Samples: 0 # # Samples: 8 of event 'cycles:u' # Event count (approx.): 96856 # # Overhead Command Symbol # ........ ....... ........................ # 89.76% sleep [.] _dl_lookup_symbol_x 9.46% sleep [.] __GI___tunables_init 0.71% sleep [k] 0xffffffffbb26bff4 0.06% sleep [k] 0xffffffffbb2b03b1 0.01% sleep [k] 0xffffffffbb2b0267 0.00% sleep [k] 0xffffffffbb2706b2 0.00% sleep [k] 0xffffffffbb2b047d $ After this patch we get the right output with just entries for the DSOs specified in --dso: $ perf report --stdio --dso /usr/lib64/ld-2.32.so # dso: /usr/lib64/ld-2.32.so # # Total Lost Samples: 0 # # Samples: 8 of event 'cycles:u' # Event count (approx.): 96856 # # Overhead Command Symbol # ........ ....... ........................ # 89.76% sleep [.] _dl_lookup_symbol_x 9.46% sleep [.] __GI___tunables_init $ # Fixes: 96415e4d3f5fdf9c ("perf symbols: Avoid unnecessary symbol loading when dso list is specified") Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210128131209.GD775562@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4fae716d1ce246c1dbde234a40796c3007aad11d Author: David E. Box Date: Tue Jan 26 12:55:08 2021 -0800 platform/x86: intel_pmt_crashlog: Add dependency on MFD_INTEL_PMT [ Upstream commit fdd3feb37e36bec2ad75d76f8ac4d0273c5c0a91 ] All devices that expose Intel Platform Monitoring Technology (PMT) crashlog are currently owned by the intel_pmt MFD driver. Therefore make the crashlog driver depend on the MFD driver for build. Fixes: 5ef9998c96b0 ("platform/x86: Intel PMT Crashlog capability driver") Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20210126205508.30907-3-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 657b22c97439d985a4740760ec8d9f2c5a7088eb Author: David E. Box Date: Tue Jan 26 12:55:07 2021 -0800 platform/x86: intel_pmt_telemetry: Add dependency on MFD_INTEL_PMT [ Upstream commit f3f6da5014dea3cc005b36948abe3664b5d1f7d3 ] All devices that expose Intel Platform Monitoring Technology (PMT) telemetry are currently owned by the intel_pmt MFD driver. Therefore make the telemetry driver depend on the MFD driver for build. Fixes: 68fe8e6e2c4b ("platform/x86: Intel PMT Telemetry capability driver") Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20210126205508.30907-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0b23df0f63dae6ee518f38f1e785f557a0132d80 Author: David E. Box Date: Tue Jan 26 12:55:06 2021 -0800 platform/x86: intel_pmt: Make INTEL_PMT_CLASS non-user-selectable [ Upstream commit 35d8a973fe4d38afee944db636c3d2b1df3741a7 ] Fix error in Kconfig that exposed INTEL_PMT_CLASS as a user selectable option. It is already selected by INTEL_PMT_TELEMETRY and INTEL_PMT_CRASHLOG which are user selectable. Fixes: e2729113ce66 ("platform/x86: Intel PMT class driver") Signed-off-by: David E. Box Link: https://lore.kernel.org/r/20210126205508.30907-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 859b1002e3883c39d575bd5ace86a11ebb458d6b Author: David Gow Date: Tue Jan 26 19:51:47 2021 -0800 rtc: zynqmp: depend on HAS_IOMEM [ Upstream commit ddd0521549a975e6148732d6ca6b89ffa862c0e5 ] The Xilinx zynqmp RTC driver makes use of IOMEM functions like devm_platform_ioremap_resource(), which are only available if CONFIG_HAS_IOMEM is defined. This causes the driver not to be enable under make ARCH=um allyesconfig, even though it won't build. By adding a dependency on HAS_IOMEM, the driver will not be enabled on architectures which don't support it. Fixes: 09ef18bcd5ac ("rtc: use devm_platform_ioremap_resource() to simplify code") Signed-off-by: David Gow Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210127035146.1523286-1-davidgow@google.com Signed-off-by: Sasha Levin commit ccbdf0c8704edd813a9aa257f676b81b9c1754c4 Author: Steven Rostedt (VMware) Date: Wed Nov 18 09:34:05 2020 -0500 tracepoint: Do not fail unregistering a probe due to memory failure [ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ] The list of tracepoint callbacks is managed by an array that is protected by RCU. To update this array, a new array is allocated, the updates are copied over to the new array, and then the list of functions for the tracepoint is switched over to the new array. After a completion of an RCU grace period, the old array is freed. This process happens for both adding a callback as well as removing one. But on removing a callback, if the new array fails to be allocated, the callback is not removed, and may be used after it is freed by the clients of the tracepoint. There's really no reason to fail if the allocation for a new array fails when removing a function. Instead, the function can simply be replaced by a stub function that could be cleaned up on the next modification of the array. That is, instead of calling the function registered to the tracepoint, it would call a stub function in its place. Link: https://lore.kernel.org/r/20201115055256.65625-1-mmullins@mmlx.us Link: https://lore.kernel.org/r/20201116175107.02db396d@gandalf.local.home Link: https://lore.kernel.org/r/20201117211836.54acaef2@oasis.local.home Link: https://lkml.kernel.org/r/20201118093405.7a6d2290@gandalf.local.home [ Note, this version does use undefined compiler behavior (assuming that a stub function with no parameters or return, can be called by a location that thinks it has parameters but still no return value. Static calls do the same thing, so this trick is not without precedent. There's another solution that uses RCU tricks and is more complex, but can be an alternative if this solution becomes an issue. Link: https://lore.kernel.org/lkml/20210127170721.58bce7cc@gandalf.local.home/ ] Cc: Peter Zijlstra Cc: Josh Poimboeuf Cc: Mathieu Desnoyers Cc: Ingo Molnar Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Dmitry Vyukov Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Andrii Nakryiko Cc: John Fastabend Cc: KP Singh Cc: netdev Cc: bpf Cc: Kees Cook Cc: Florian Weimer Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints") Reported-by: syzbot+83aa762ef23b6f0d1991@syzkaller.appspotmail.com Reported-by: syzbot+d29e58bb557324e55e5e@syzkaller.appspotmail.com Reported-by: Matt Mullins Signed-off-by: Steven Rostedt (VMware) Tested-by: Matt Mullins Signed-off-by: Sasha Levin commit 7b43f95c1fa9f91146f592271bb194b8b396fb0b Author: Parav Pandit Date: Wed Jan 27 17:00:08 2021 +0200 IB/cm: Avoid a loop when device has 255 ports [ Upstream commit 131be26750379592f0dd6244b2a90bbb504a10bb ] When RDMA device has 255 ports, loop iterator i overflows. Due to which cm_add_one() port iterator loops infinitely. Use core provided port iterator to avoid the infinite loop. Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation") Link: https://lore.kernel.org/r/20210127150010.1876121-9-leon@kernel.org Signed-off-by: Mark Bloch Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 32538379d35d6afcc6b3d3a974ad28404357e003 Author: Parav Pandit Date: Wed Jan 27 17:00:07 2021 +0200 IB/mlx5: Return appropriate error code instead of ENOMEM [ Upstream commit d286ac1d05210695c312b9018b3aa7c2048e9aca ] When mlx5_ib_stage_init_init() fails, return the error code related to failure instead of -ENOMEM. Fixes: 16c1975f1032 ("IB/mlx5: Create profile infrastructure to add and remove stages") Link: https://lore.kernel.org/r/20210127150010.1876121-8-leon@kernel.org Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d78c3672288d3b59dcac0b5cbf0ae8a7b7229b65 Author: Douglas Anderson Date: Mon Feb 1 17:06:23 2021 -0800 iommu: Properly pass gfp_t in _iommu_map() to avoid atomic sleeping [ Upstream commit b8437a3ef8c485903d05d1f261328aaf0c0a6cc2 ] Sleeping while atomic = bad. Let's fix an obvious typo to try to avoid it. The warning that was seen (on a downstream kernel with the problematic patch backported): BUG: sleeping function called from invalid context at mm/page_alloc.c:4726 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: ksoftirqd/0 CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.4.93-12508-gc10c93e28e39 #1 Call trace: dump_backtrace+0x0/0x154 show_stack+0x20/0x2c dump_stack+0xa0/0xfc ___might_sleep+0x11c/0x12c __might_sleep+0x50/0x84 __alloc_pages_nodemask+0xf8/0x2bc __arm_lpae_alloc_pages+0x48/0x1b4 __arm_lpae_map+0x124/0x274 __arm_lpae_map+0x1cc/0x274 arm_lpae_map+0x140/0x170 arm_smmu_map+0x78/0xbc __iommu_map+0xd4/0x210 _iommu_map+0x4c/0x84 iommu_map_atomic+0x44/0x58 __iommu_dma_map+0x8c/0xc4 iommu_dma_map_page+0xac/0xf0 Fixes: d8c1df02ac7f ("iommu: Move iotlb_sync_map out from __iommu_map") Signed-off-by: Douglas Anderson Reviewed-by: Yong Wu Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210201170611.1.I64a7b62579287d668d7c89e105dcedf45d641063@changeid Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 5135ad572da70306df0dc981676869572540eff0 Author: Yong Wu Date: Thu Jan 7 20:29:03 2021 +0800 iommu: Move iotlb_sync_map out from __iommu_map [ Upstream commit d8c1df02ac7f2c802a9b2afc0f5c888c4217f1d5 ] In the end of __iommu_map, It alway call iotlb_sync_map. This patch moves iotlb_sync_map out from __iommu_map since it is unnecessary to call this for each sg segment especially iotlb_sync_map is flush tlb all currently. Add a little helper _iommu_map for this. Signed-off-by: Yong Wu Reviewed-by: Robin Murphy Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210107122909.16317-2-yong.wu@mediatek.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8189846341680964a303c39e41cfc0043d8137f1 Author: Uwe Kleine-König Date: Tue Jan 26 17:58:31 2021 +0100 amba: Fix resource leak for drivers without .remove [ Upstream commit de5d7adb89367bbc87b4e5ce7afe7ae9bd86dc12 ] Consider an amba driver with a .probe but without a .remove callback (e.g. pl061_gpio_driver). The function amba_probe() is called to bind a device and so dev_pm_domain_attach() and others are called. As there is no remove callback amba_remove() isn't called at unbind time however and so calling dev_pm_domain_detach() is missed and the pm domain keeps active. To fix this always use the core driver callbacks and handle missing amba callbacks there. For probe refuse registration as a driver without probe doesn't make sense. Fixes: 7cfe249475fd ("ARM: AMBA: Add pclk support to AMBA bus infrastructure") Reviewed-by: Ulf Hansson Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210126165835.687514-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 4a586840a3a329f7ac90576379b655c12b7f2d9d Author: David Gow Date: Tue Jan 26 20:06:37 2021 -0800 i3c/master/mipi-i3c-hci: Specify HAS_IOMEM dependency [ Upstream commit 9d909f1b1e91b4aa7d016ed14b7b76dbf2675414 ] The MIPI i3c HCI driver makes use of IOMEM functions like devm_platform_ioremap_resource(), which are only available if CONFIG_HAS_IOMEM is defined. This causes the driver to be enabled under make ARCH=um allyesconfig, even though it won't build. By adding a dependency on HAS_IOMEM, the driver will not be enabled on architectures which don't support it. Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver") Signed-off-by: David Gow Acked-by: Nicolas Pitre Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210127040636.1535722-1-davidgow@google.com Signed-off-by: Sasha Levin commit 39270c122d6ff1b366c7a735bdeb01380abe7db2 Author: Roja Rani Yarubandi Date: Mon Dec 21 18:08:00 2020 +0530 i2c: qcom-geni: Store DMA mapping data in geni_i2c_dev struct [ Upstream commit 357ee8841d0b7bd822f25fc768afbc0c2ab7e47b ] Store DMA mapping data in geni_i2c_dev struct to enhance DMA mapping data scope. For example during shutdown callback to unmap DMA mapping, this stored DMA mapping data can be used to call geni_se_tx_dma_unprep and geni_se_rx_dma_unprep functions. Add two helper functions geni_i2c_rx_msg_cleanup and geni_i2c_tx_msg_cleanup to unwrap the things after rx/tx FIFO/DMA transfers, so that the same can be used in geni_i2c_stop_xfer() function during shutdown callback. Signed-off-by: Roja Rani Yarubandi Reviewed-by: Akash Asthana Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit b85c8f68c783716d7695c486ab997263be5f1583 Author: Vladimir Murzin Date: Thu Jan 7 10:47:24 2021 +0100 ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores [ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ] It was observed that decompressor running on hardware implementing ARM v8.2 Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest, would stuck just after: Uncompressing Linux... done, booting the kernel. The reason is that it clears nTLSMD bit when disabling caches: nTLSMD, bit [3] When ARMv8.2-LSMAOC is implemented: No Trap Load Multiple and Store Multiple to Device-nGRE/Device-nGnRE/Device-nGnRnE memory. 0b0 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and generate a stage 1 Alignment fault. 0b1 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped. This bit is permitted to be cached in a TLB. This field resets to 1. Otherwise: Reserved, RES1 So as effect we start getting traps we are not quite ready for. Looking into history it seems that mask used for SCTLR clear came from the similar code for ARMv4, where bit[3] is the enable/disable bit for the write buffer. That not applicable to ARMv7 and onwards, so retire that bit from the masks. Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format") Signed-off-by: Vladimir Murzin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit efa165f2071ec7f8629b9ade62e008c03bd2f1ed Author: Takeshi Saito Date: Wed Dec 16 19:29:31 2020 +0900 mmc: renesas_sdhi_internal_dmac: Fix DMA buffer alignment from 8 to 128-bytes [ Upstream commit d7aefb2887601cf1fc3f86f55d43b2c9aece5e8f ] According to the latest datasheet, the internal DMAC buffer alignment R-Car Gen3 SDHI HW should be 128-bytes. So, fix it. Signed-off-by: Takeshi Saito [shimoda: revise commit description, rebase] Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Link: https://lore.kernel.org/r/1608114572-1892-2-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 676aa6bad7c2122248476745670a951c3e4646a3 Author: Christophe JAILLET Date: Thu Dec 17 22:09:22 2020 +0100 mmc: usdhi6rol0: Fix a resource leak in the error handling path of the probe [ Upstream commit 6052b3c370fb82dec28bcfff6d7ec0da84ac087a ] A call to 'ausdhi6_dma_release()' to undo a previous call to 'usdhi6_dma_request()' is missing in the error handling path of the probe function. It is already present in the remove function. Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201217210922.165340-1-christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2d5cb23241e8e104b380775b94385eefb13610ce Author: Christophe JAILLET Date: Thu Dec 17 21:42:36 2020 +0100 mmc: sdhci-sprd: Fix some resource leaks in the remove function [ Upstream commit c9c256a8b0dc09c305c409d6264cc016af2ba38d ] 'sdhci_remove_host()' and 'sdhci_pltfm_free()' should be used in place of 'mmc_remove_host()' and 'mmc_free_host()'. This avoids some resource leaks, is more in line with the error handling path of the probe function, and is more consistent with other drivers. Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Signed-off-by: Christophe JAILLET Acked-by: Orson Zhai Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20201217204236.163446-1-christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9f5398d5f24e615debf72c8aaec8283058e64683 Author: Christophe JAILLET Date: Wed Dec 9 20:42:02 2020 +0100 mmc: owl-mmc: Fix a resource leak in an error handling path and in the remove function [ Upstream commit 5d15cbf63515c6183d2ed7c9dd0586b4db23ffb1 ] 'dma_request_chan()' calls should be balanced by a corresponding 'dma_release_channel()' call. Add the missing call both in the error handling path of the probe function and in the remove function. Fixes: ff65ffe46d28 ("mmc: Add Actions Semi Owl SoCs SD/MMC driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201209194202.54099-1-christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 26b4cc83467470496b2c1a2bacdeca12d1efd7b9 Author: Michal Suchanek Date: Wed Jan 20 14:28:38 2021 +0100 powerpc: Fix build error in paravirt.h [ Upstream commit 9899a56f1eca964cd0de21008a9fa1523a571231 ] ./arch/powerpc/include/asm/paravirt.h:83:44: error: implicit declaration of function 'smp_processor_id'; did you mean 'raw_smp_processor_id'? smp_processor_id is defined in linux/smp.h but it is not included. The build error happens only when the patch is applied to 5.3 kernel but it only works by chance in mainline. Fixes: ca3f969dcb11 ("powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted()") Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210120132838.15589-1-msuchanek@suse.de Signed-off-by: Sasha Levin commit 221a42984543b72254fec9bfda6a53fd0dbe1047 Author: Pingfan Liu Date: Thu Oct 22 14:51:19 2020 +0800 powerpc/time: Enable sched clock for irqtime [ Upstream commit b709e32ef570b8b91dfbcb63cffac4324c87799f ] When CONFIG_IRQ_TIME_ACCOUNTING and CONFIG_VIRT_CPU_ACCOUNTING_GEN, powerpc does not enable "sched_clock_irqtime" and can not utilize irq time accounting. Like x86, powerpc does not use the sched_clock_register() interface. So it needs an dedicated call to enable_sched_clock_irqtime() to enable irq time accounting. Fixes: 518470fe962e ("powerpc: Add HAVE_IRQ_TIME_ACCOUNTING") Signed-off-by: Pingfan Liu [mpe: Add fixes tag] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1603349479-26185-1-git-send-email-kernelfans@gmail.com Signed-off-by: Sasha Levin commit 773f9a944a1c0e78b098e35ce54ec190f3ab3721 Author: Ananth N Mavinakayanahalli Date: Mon Jan 25 18:36:43 2021 +0530 powerpc/sstep: Fix incorrect return from analyze_instr() [ Upstream commit 718aae916fa6619c57c348beaedd675835cf1aa1 ] We currently just percolate the return value from analyze_instr() to the caller of emulate_step(), especially if it is a -1. For one particular case (opcode = 4) for instructions that aren't currently emulated, we are returning 'should not be single-stepped' while we should have returned 0 which says 'did not emulate, may have to single-step'. Fixes: 930d6288a26787 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions") Signed-off-by: Ananth N Mavinakayanahalli Suggested-by: Michael Ellerman Tested-by: Naveen N. Rao Reviewed-by: Sandipan Das Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161157999039.64773.14950289716779364766.stgit@thinktux.local Signed-off-by: Sasha Levin commit 02f415bcf6074401ff1453e7aabb3005eba3b95a Author: Ananth N Mavinakayanahalli Date: Mon Jan 25 18:36:22 2021 +0530 powerpc/sstep: Check instruction validity against ISA version before emulation [ Upstream commit 8813ff49607eab3caaf40fe8929b0ce7dc68e85f ] We currently unconditionally try to emulate newer instructions on older Power versions that could cause issues. Gate it. Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code") Signed-off-by: Ananth N Mavinakayanahalli Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/161157995977.64773.13794501093457185080.stgit@thinktux.local Signed-off-by: Sasha Levin commit 96d3de51972f31c2bb8c157ec41c24d491fdf469 Author: Christophe Leroy Date: Wed Jan 20 07:49:13 2021 +0000 powerpc/47x: Disable 256k page size [ Upstream commit 910a0cb6d259736a0c86e795d4c2f42af8d0d775 ] PPC47x_TLBE_SIZE isn't defined for 256k pages, leading to a build break if 256k pages is selected. So change the kconfig so that 256k pages can't be selected for 47x. Fixes: e7f75ad01d59 ("powerpc/47x: Base ppc476 support") Reported-by: kernel test robot Signed-off-by: Christophe Leroy [mpe: Expand change log to mention build break] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/2fed79b1154c872194f98bac4422c23918325e61.1611128938.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 5866ad6f861abe9867b0832e640a7c1a1f9e6870 Author: Christophe Leroy Date: Tue Jan 19 06:36:52 2021 +0000 powerpc/kvm: Force selection of CONFIG_PPC_FPU [ Upstream commit 27f699579b64dbf27caf31e5c0eac567ec0aa8b8 ] book3s/32 kvm is designed with the assumption that an FPU is always present. Force selection of FPU support in the kernel when build KVM. Fixes: 7d68c8916950 ("powerpc/32s: Allow deselecting CONFIG_PPC_FPU on mpc832x") Reported-by: kernel test robot Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/74461a99fa1466f361532ca794ca0753be3d9f86.1611038044.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 812b5c3bf6ef42c952937a8d08144ca6fd812ca3 Author: Cédric Le Goater Date: Mon Jan 4 15:32:01 2021 +0100 KVM: PPC: Make the VMX instruction emulation routines static [ Upstream commit 9236f57a9e51c72ce426ccd2e53e123de7196a0f ] These are only used locally. It fixes these W=1 compile errors : ../arch/powerpc/kvm/powerpc.c:1521:5: error: no previous prototype for ‘kvmppc_get_vmx_dword’ [-Werror=missing-prototypes] 1521 | int kvmppc_get_vmx_dword(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~~ ../arch/powerpc/kvm/powerpc.c:1539:5: error: no previous prototype for ‘kvmppc_get_vmx_word’ [-Werror=missing-prototypes] 1539 | int kvmppc_get_vmx_word(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~ ../arch/powerpc/kvm/powerpc.c:1557:5: error: no previous prototype for ‘kvmppc_get_vmx_hword’ [-Werror=missing-prototypes] 1557 | int kvmppc_get_vmx_hword(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~~ ../arch/powerpc/kvm/powerpc.c:1575:5: error: no previous prototype for ‘kvmppc_get_vmx_byte’ [-Werror=missing-prototypes] 1575 | int kvmppc_get_vmx_byte(struct kvm_vcpu *vcpu, int index, u64 *val) | ^~~~~~~~~~~~~~~~~~~ Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction mmio emulation with analyse_instr() input") Signed-off-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210104143206.695198-19-clg@kaod.org Signed-off-by: Sasha Levin commit daf9eac951542d5017d41f5a708301d132f95f1b Author: Shay Drory Date: Mon Jan 25 14:13:39 2021 +0200 IB/umad: Return EPOLLERR in case of when device disassociated [ Upstream commit def4cd43f522253645b72c97181399c241b54536 ] Currently, polling a umad device will always works, even if the device was disassociated. A disassociated device should immediately return EPOLLERR from poll(). Otherwise userspace is endlessly hung on poll() with no idea that the device has been removed from the system. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/20210125121339.837518-3-leon@kernel.org Signed-off-by: Shay Drory Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c911568e245bb396d05de86a458aed824f557bf7 Author: Shay Drory Date: Mon Jan 25 14:13:38 2021 +0200 IB/umad: Return EIO in case of when device disassociated [ Upstream commit 4fc5461823c9cad547a9bdfbf17d13f0da0d6bb5 ] MAD message received by the user has EINVAL error in all flows including when the device is disassociated. That makes it impossible for the applications to treat such flow differently. Change it to return EIO, so the applications will be able to perform disassociation recovery. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/20210125121339.837518-2-leon@kernel.org Signed-off-by: Shay Drory Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1d8eaee00aeabe7dea9e8df563cd61f5d27c135b Author: Mark Bloch Date: Mon Jan 25 14:07:09 2021 +0200 RDMA/mlx5: Allow creating all QPs even when non RDMA profile is used [ Upstream commit 2614488d1f3cd5989375042286b11424208e20c8 ] The cited commit disallowed creating any QP which isn't raw ethernet, reg umr or the special UD qp for testing WC, this proved too strict. While modify can't be done (no GIDS/GID table for example) just creating a QP is okay. This patch partially reverts the bellow mentioned commit and places the restriction at the modify QP stage and not at the creation. DEVX commands should be used to manipulate such QPs. Fixes: 42caf9cb5937 ("RDMA/mlx5: Allow only raw Ethernet QPs when RoCE isn't enabled") Link: https://lore.kernel.org/r/20210125120709.836718-1-leon@kernel.org Signed-off-by: Mark Bloch Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 47049c61349e4afe7517bc35751e07ec1d6541e7 Author: Maor Gottlieb Date: Mon Jan 25 14:05:27 2021 +0200 tools/testing/scatterlist: Fix overflow of max segment size [ Upstream commit 96667052149da3855c4361925324b690c687152f ] Because SCATTERLIST_MAX_SEGMENT was removed and replaced with UINT_MAX, the test overflows the max_sgement variable. Remove this case. Fixes: 7a60c2dd0f57 ("drm: Remove SCATTERLIST_MAX_SEGMENT") Link: https://lore.kernel.org/r/20210125120527.836363-1-leon@kernel.org Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c4b97710b10ebf00d5872665cf83fc2121fbe78f Author: Yong Wu Date: Thu Jan 7 20:29:06 2021 +0800 iommu: Switch gather->end to the inclusive end [ Upstream commit 862c3715de8f3e5350489240c951d697f04bd8c9 ] Currently gather->end is "unsigned long" which may be overflow in arch32 in the corner case: 0xfff00000 + 0x100000(iova + size). Although it doesn't affect the size(end - start), it affects the checking "gather->end < end" This patch changes this "end" to the real end address (end = start + size - 1). Correspondingly, update the length to "end - start + 1". Fixes: a7d20dc19d9e ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes") Signed-off-by: Yong Wu Reviewed-by: Robin Murphy Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210107122909.16317-5-yong.wu@mediatek.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 798ccdeb1752edf4fdfdf4496e1ca4ee7f36cdd6 Author: Dan Carpenter Date: Mon Jan 25 11:44:34 2021 +0300 scsi: lpfc: Fix ancient double free [ Upstream commit 0be310979e5e1272d4c5b557642df4da4ce7eba4 ] The "pmb" pointer is freed at the start of the function and then freed again in the error handling code. Link: https://lore.kernel.org/r/YA6E8rO51hE56SVw@mwanda Fixes: 92d7f7b0cde3 ("[SCSI] lpfc: NPIV: add NPIV support on top of SLI-3") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 78c28007b9e45e956c18fd227dd48ec73bb06747 Author: Josh Poimboeuf Date: Thu Jan 21 15:29:19 2021 -0600 objtool: Fix ".cold" section suffix check for newer versions of GCC [ Upstream commit 34ca59e109bdf69704c33b8eeffaa4c9f71076e5 ] With my version of GCC 9.3.1 the ".cold" subfunctions no longer have a numbered suffix, so the trailing period is no longer there. Presumably this doesn't yet trigger a user-visible bug since most of the subfunction detection logic is duplicated. I only found it when testing vmlinux.o validation. Fixes: 54262aa28301 ("objtool: Fix sibling call detection") Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/ca0b5a57f08a2fbb48538dd915cc253b5edabb40.1611263461.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit b430c44814dad98308394e9f20c9d5a42d8dc56c Author: Josh Poimboeuf Date: Thu Jan 21 15:29:18 2021 -0600 objtool: Fix retpoline detection in asm code [ Upstream commit 1f9a1b74942485a0a29e7c4a9a9f2fe8aea17766 ] The JMP_NOSPEC macro branches to __x86_retpoline_*() rather than the __x86_indirect_thunk_*() wrappers used by C code. Detect jumps to __x86_retpoline_*() as retpoline dynamic jumps. Presumably this doesn't trigger a user-visible bug. I only found it when testing vmlinux.o validation. Fixes: 39b735332cb8 ("objtool: Detect jumps to retpoline thunks") Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/31f5833e2e4f01e3d755889ac77e3661e906c09f.1611263461.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit 473c0c0a8d7dc8dcad96a6a820482c14736eae02 Author: Josh Poimboeuf Date: Thu Jan 21 15:29:17 2021 -0600 objtool: Fix error handling for STD/CLD warnings [ Upstream commit 6f567c9300a5ebd7b18c26dda1c8d6ffbdd0debd ] Actually return an error (and display a backtrace, if requested) for directional bit warnings. Fixes: 2f0f9e9ad7b3 ("objtool: Add Direction Flag validation") Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/dc70f2adbc72f09526f7cab5b6feb8bf7f6c5ad4.1611263461.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit 828e8e61c55c1bb643d4a94165bbadaaf4410bfb Author: Geert Uytterhoeven Date: Fri Jan 22 17:01:02 2021 +0100 auxdisplay: Fix duplicate CHARLCD config symbol [ Upstream commit b45616445a6e346daf8a173a0c51413aec067ebb ] A second CHARLCD config symbol was added instead of moving the existing one. Fix this by removing the old one. Fixes: 718e05ed92ecac0d ("auxdisplay: Introduce hd44780_common.[ch]") Signed-off-by: Geert Uytterhoeven Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 6d6dfeabacfbd69f2b45e57d0bc6d0f5d31b4c38 Author: Geert Uytterhoeven Date: Fri Jan 22 16:39:40 2021 +0100 auxdisplay: ht16k33: Fix refresh rate handling [ Upstream commit e89b0a426721a8ca5971bc8d70aa5ea35c020f90 ] Drop the call to msecs_to_jiffies(), as "HZ / fbdev->refresh_rate" is already the number of jiffies to wait. Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller") Signed-off-by: Geert Uytterhoeven Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 5ca0ab462636d4dd82c2d345b376b352d3a07c29 Author: Andy Shevchenko Date: Fri Oct 23 19:33:02 2020 +0300 watchdog: intel-mid_wdt: Postpone IRQ handler registration till SCU is ready [ Upstream commit f285c9532b5bd3de7e37a6203318437cab79bd9a ] When SCU is not ready and CONFIG_DEBUG_SHIRQ=y we got deferred probe followed by fired test IRQ which immediately makes kernel panic. Fix this by delaying IRQ handler registration till SCU is ready. Fixes: 80ae679b8f86 ("watchdog: intel-mid_wdt: Convert to use new SCU IPC API") Signed-off-by: Andy Shevchenko Reviewed-by: Guenter Roeck Acked-by: Linus Walleij Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit de477430e07179036dbe88b08b54ee33752fe052 Author: Pan Bian Date: Mon Jan 18 04:04:55 2021 -0800 isofs: release buffer head before return [ Upstream commit 0a6dc67a6aa45f19bd4ff89b4f468fc50c4b8daa ] Release the buffer_head before returning error code in do_isofs_readdir() and isofs_find_entry(). Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading corrupted filesystem") Link: https://lore.kernel.org/r/20210118120455.118955-1-bianpan2016@163.com Signed-off-by: Pan Bian Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 0068aad36244daf873437e1fafb5a6ab19aeb716 Author: Hans de Goede Date: Fri Jan 22 19:32:50 2021 +0100 regulator: core: Avoid debugfs: Directory ... already present! error [ Upstream commit dbe954d8f1635f949a1d9a5d6e6fb749ae022b47 ] Sometimes regulator_get() gets called twice for the same supply on the same device. This may happen e.g. when a framework / library is used which uses the regulator; and the driver itself also needs to enable the regulator in some cases where the framework will not enable it. Commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate sysfs") already takes care of the backtrace which would trigger when creating a duplicate consumer symlink under /sys/class/regulator/regulator.%d in this scenario. Commit c33d442328f5 ("debugfs: make error message a bit more verbose") causes a new error to get logged in this scenario: [ 26.938425] debugfs: Directory 'wm5102-codec-MICVDD' with parent 'spi-WM510204:00-MICVDD' already present! There is no _nowarn variant of debugfs_create_dir(), but we can detect and avoid this problem by checking the return value of the earlier sysfs_create_link_nowarn() call. Add a check for the earlier sysfs_create_link_nowarn() failing with -EEXIST and skip the debugfs_create_dir() call in that case, avoiding this error getting logged. Fixes: c33d442328f5 ("debugfs: make error message a bit more verbose") Cc: Charles Keepax Signed-off-by: Hans de Goede Reviewed-by: Charles Keepax Link: https://lore.kernel.org/r/20210122183250.370571-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a4eb0c6e3621dd6451255763c4207549ce539d15 Author: Dmitry Osipenko Date: Fri Jan 22 22:17:34 2021 +0300 power: supply: smb347-charger: Fix interrupt usage if interrupt is unavailable [ Upstream commit 6996312642d2dad3070c3d276c7621f35e721f30 ] The IRQ=0 could be a valid interrupt number in kernel because interrupt numbers are virtual in a modern kernel. Hence fix the interrupt usage in a case if interrupt is unavailable by not overriding the interrupt number which is used by the driver. Note that currently Nexus 7 is the only know device which uses SMB347 kernel diver and it has a properly working interrupt, hence this patch doesn't fix any real problems, it's a minor cleanup/improvement. Fixes: 99298de5df92 ("power: supply: smb347-charger: Replace mutex with IRQ disable/enable") Signed-off-by: Dmitry Osipenko Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8f976dc92effc3f8c691cce48a57eb0901a5f3c2 Author: Samuel Holland Date: Sun Jan 24 09:24:21 2021 -0600 power: supply: axp20x_usb_power: Init work before enabling IRQs [ Upstream commit b5e8642ed95ff6ecc20cc6038fe831affa9d098c ] The IRQ handler calls mod_delayed_work() on power->vbus_detect. However, that work item is not initialized until after the IRQs are enabled. If an IRQ is already pending when the driver is probed, the driver calls mod_delayed_work() on an uninitialized work item, which causes an oops. Fixes: bcfb7ae3f50b ("power: supply: axp20x_usb_power: Only poll while offline") Signed-off-by: Samuel Holland Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 0e6828b9f1e67a6a59fc429790a552ad6568ed76 Author: Ahmed S. Darwish Date: Mon Jan 18 11:09:43 2021 +0100 scsi: isci: Pass gfp_t flags in isci_port_bc_change_received() [ Upstream commit 71dca5539fcf977aead0c9ea1962e70e78484b8e ] Use the new libsas event notifiers API, which requires callers to explicitly pass the gfp_t memory allocation flags. libsas sas_notify_port_event() is called from isci_port_bc_change_received(). Below is the context analysis for all of its call chains: host.c: sci_controller_error_handler(): atomic, irq handler (*) OR host.c: sci_controller_completion_handler(), atomic, tasklet (*) -> sci_controller_process_completions() -> sci_controller_event_completion() -> phy.c: sci_phy_event_handler() -> port.c: sci_port_broadcast_change_received() -> isci_port_bc_change_received() host.c: isci_host_init() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_initialize(), atomic (*) -> port_config.c: sci_port_configuration_agent_initialize() -> sci_mpc_agent_validate_phy_configuration() -> port.c: sci_port_add_phy() -> sci_port_set_phy() -> phy.c: sci_phy_set_port() -> port.c: sci_port_broadcast_change_received() -> isci_port_bc_change_received() port_config.c: apc_agent_timeout(), atomic, timer callback (*) -> sci_apc_agent_configure_ports() -> port.c: sci_port_add_phy() -> sci_port_set_phy() -> phy.c: sci_phy_set_port() -> port.c: sci_port_broadcast_change_received() -> isci_port_bc_change_received() phy.c: enter SCI state: *SCI_PHY_STOPPED* # Cont. from [1] -> sci_phy_stopped_state_enter() -> host.c: sci_controller_link_down() -> ->link_down_handler() == port_config.c: sci_apc_agent_link_down() -> port.c: sci_port_remove_phy() -> sci_port_clear_phy() -> phy.c: sci_phy_set_port() -> port.c: sci_port_broadcast_change_received() -> isci_port_bc_change_received() phy.c: enter SCI state: *SCI_PHY_STARTING* # Cont. from [2] -> sci_phy_starting_state_enter() -> host.c: sci_controller_link_down() -> ->link_down_handler() == port_config.c: sci_apc_agent_link_down() -> port.c: sci_port_remove_phy() -> sci_port_clear_phy() -> phy.c: sci_phy_set_port() -> port.c: sci_port_broadcast_change_received() -> isci_port_bc_change_received() [1] Call chains for entering state: *SCI_PHY_STOPPED* ----------------------------------------------------- host.c: isci_host_init() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_initialize(), atomic (*) -> phy.c: sci_phy_initialize() -> phy.c: sci_phy_link_layer_initialization() -> phy.c: sci_change_state(SCI_PHY_STOPPED) init.c: PCI ->remove() || PM_OPS ->suspend, process context (+) -> host.c: isci_host_deinit() -> sci_controller_stop_phys() -> phy.c: sci_phy_stop() -> sci_change_state(SCI_PHY_STOPPED) phy.c: isci_phy_control() spin_lock_irqsave(isci_host::scic_lock, ) -> sci_phy_stop(), atomic (*) -> sci_change_state(SCI_PHY_STOPPED) [2] Call chains for entering state: *SCI_PHY_STARTING* ------------------------------------------------------ phy.c: phy_sata_timeout(), atimer, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> sci_change_state(SCI_PHY_STARTING) host.c: phy_startup_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> sci_controller_start_next_phy() -> sci_phy_start() -> sci_change_state(SCI_PHY_STARTING) host.c: isci_host_start() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_start(), atomic (*) -> sci_controller_start_next_phy() -> sci_phy_start() -> sci_change_state(SCI_PHY_STARTING) phy.c: Enter SCI state *SCI_PHY_SUB_FINAL* # Cont. from [2A] -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_phy_starting_final_substate_enter() -> sci_change_state(SCI_PHY_READY) -> Enter SCI state: *SCI_PHY_READY* -> sci_phy_ready_state_enter() -> host.c: sci_controller_link_up() -> sci_controller_start_next_phy() -> sci_phy_start() -> sci_change_state(SCI_PHY_STARTING) phy.c: sci_phy_event_handler(), atomic, discussed earlier (*) -> sci_change_state(SCI_PHY_STARTING), 11 instances port.c: isci_port_perform_hard_reset() spin_lock_irqsave(isci_host::scic_lock, ) -> port.c: sci_port_hard_reset(), atomic (*) -> phy.c: sci_phy_reset() -> sci_change_state(SCI_PHY_RESETTING) -> enter SCI PHY state: *SCI_PHY_RESETTING* -> sci_phy_resetting_state_enter() -> sci_change_state(SCI_PHY_STARTING) [2A] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL* ------------------------------------------------------------ host.c: power_control_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> phy.c: sci_phy_consume_power_handler() -> phy.c: sci_change_state(SCI_PHY_SUB_FINAL) host.c: sci_controller_error_handler(): atomic, irq handler (*) OR host.c: sci_controller_completion_handler(), atomic, tasklet (*) -> sci_controller_process_completions() -> sci_controller_unsolicited_frame() -> phy.c: sci_phy_frame_handler() -> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER) -> sci_phy_starting_await_sas_power_substate_enter() -> host.c: sci_controller_power_control_queue_insert() -> phy.c: sci_phy_consume_power_handler() -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_controller_event_completion() -> phy.c: sci_phy_event_handler() -> sci_phy_start_sata_link_training() -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER) -> sci_phy_starting_await_sata_power_substate_enter -> host.c: sci_controller_power_control_queue_insert() -> phy.c: sci_phy_consume_power_handler() -> sci_change_state(SCI_PHY_SUB_FINAL) As can be seen from the "(*)" markers above, almost all the call-chains are atomic. The only exception, marked with "(+)", is a PCI ->remove() and PM_OPS ->suspend() cold path. Thus, pass GFP_ATOMIC to the libsas port event notifier. Note, the now-replaced libsas APIs used in_interrupt() to implicitly decide which memory allocation type to use. This was only partially correct, as it fails to choose the correct GFP flags when just preemption or interrupts are disabled. Such buggy code paths are marked with "(@)" in the call chains above. Link: https://lore.kernel.org/r/20210118100955.1761652-8-a.darwish@linutronix.de Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost") Cc: Artur Paszkiewicz Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9a5ee39a64455e25dcab2ff885e31f9df1cc8a77 Author: Ahmed S. Darwish Date: Mon Jan 18 11:09:42 2021 +0100 scsi: isci: Pass gfp_t flags in isci_port_link_up() [ Upstream commit 5ce7902902adb8d154d67ba494f06daa29360ef0 ] Use the new libsas event notifiers API, which requires callers to explicitly pass the gfp_t memory allocation flags. libsas sas_notify_port_event() is called from isci_port_link_up(). Below is the context analysis for all of its call chains: host.c: isci_host_init() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_initialize(), atomic (*) -> port_config.c: sci_port_configuration_agent_initialize() -> sci_mpc_agent_validate_phy_configuration() -> port.c: sci_port_add_phy() -> sci_port_general_link_up_handler() -> sci_port_activate_phy() -> isci_port_link_up() port_config.c: apc_agent_timeout(), atomic, timer callback (*) -> sci_apc_agent_configure_ports() -> port.c: sci_port_add_phy() -> sci_port_general_link_up_handler() -> sci_port_activate_phy() -> isci_port_link_up() phy.c: enter SCI state: *SCI_PHY_SUB_FINAL* # Cont. from [1] -> phy.c: sci_phy_starting_final_substate_enter() -> phy.c: sci_change_state(SCI_PHY_READY) -> enter SCI state: *SCI_PHY_READY* -> phy.c: sci_phy_ready_state_enter() -> host.c: sci_controller_link_up() -> .link_up_handler() == port_config.c: sci_apc_agent_link_up() -> port.c: sci_port_link_up() -> (continue at [A]) == port_config.c: sci_mpc_agent_link_up() -> port.c: sci_port_link_up() -> (continue at [A]) port_config.c: mpc_agent_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> ->link_up_handler() == port_config.c: sci_apc_agent_link_up() -> port.c: sci_port_link_up() -> (continue at [A]) == port_config.c: sci_mpc_agent_link_up() -> port.c: sci_port_link_up() -> (continue at [A]) [A] port.c: sci_port_link_up() -> sci_port_activate_phy() -> isci_port_link_up() -> sci_port_general_link_up_handler() -> sci_port_activate_phy() -> isci_port_link_up() [1] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL* ----------------------------------------------------------- host.c: power_control_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> phy.c: sci_phy_consume_power_handler() -> phy.c: sci_change_state(SCI_PHY_SUB_FINAL) host.c: sci_controller_error_handler(): atomic, irq handler (*) OR host.c: sci_controller_completion_handler(), atomic, tasklet (*) -> sci_controller_process_completions() -> sci_controller_unsolicited_frame() -> phy.c: sci_phy_frame_handler() -> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER) -> sci_phy_starting_await_sas_power_substate_enter() -> host.c: sci_controller_power_control_queue_insert() -> phy.c: sci_phy_consume_power_handler() -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_controller_event_completion() -> phy.c: sci_phy_event_handler() -> sci_phy_start_sata_link_training() -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER) -> sci_phy_starting_await_sata_power_substate_enter -> host.c: sci_controller_power_control_queue_insert() -> phy.c: sci_phy_consume_power_handler() -> sci_change_state(SCI_PHY_SUB_FINAL) As can be seen from the "(*)" markers above, all the call-chains are atomic. Pass GFP_ATOMIC to libsas port event notifier. Note, the now-replaced libsas APIs used in_interrupt() to implicitly decide which memory allocation type to use. This was only partially correct, as it fails to choose the correct GFP flags when just preemption or interrupts are disabled. Such buggy code paths are marked with "(@)" in the call chains above. Link: https://lore.kernel.org/r/20210118100955.1761652-7-a.darwish@linutronix.de Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost") Cc: Artur Paszkiewicz Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6c9822a2933e5c39dfa0d5a5660a132c37939ffd Author: Ahmed S. Darwish Date: Mon Jan 18 11:09:41 2021 +0100 scsi: isci: Pass gfp_t flags in isci_port_link_down() [ Upstream commit 885ab3b8926fdf9cdd7163dfad99deb9b0662b39 ] Use the new libsas event notifiers API, which requires callers to explicitly pass the gfp_t memory allocation flags. sas_notify_phy_event() is exclusively called by isci_port_link_down(). Below is the context analysis for all of its call chains: port.c: port_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> port_state_machine_change(..., SCI_PORT_FAILED) -> enter SCI port state: *SCI_PORT_FAILED* -> sci_port_failed_state_enter() -> isci_port_hard_reset_complete() -> isci_port_link_down() port.c: isci_port_perform_hard_reset() spin_lock_irqsave(isci_host::scic_lock, ) -> port.c: sci_port_hard_reset(), atomic (*) -> phy.c: sci_phy_reset() -> sci_change_state(SCI_PHY_RESETTING) -> enter SCI PHY state: *SCI_PHY_RESETTING* -> sci_phy_resetting_state_enter() -> port.c: sci_port_deactivate_phy() -> isci_port_link_down() port.c: enter SCI port state: *SCI_PORT_READY* # Cont. from [1] -> sci_port_ready_state_enter() -> isci_port_hard_reset_complete() -> isci_port_link_down() phy.c: enter SCI state: *SCI_PHY_STOPPED* # Cont. from [2] -> sci_phy_stopped_state_enter() -> host.c: sci_controller_link_down() -> ->link_down_handler() == port_config.c: sci_apc_agent_link_down() -> port.c: sci_port_remove_phy() -> sci_port_deactivate_phy() -> isci_port_link_down() == port_config.c: sci_mpc_agent_link_down() -> port.c: sci_port_link_down() -> sci_port_deactivate_phy() -> isci_port_link_down() phy.c: enter SCI state: *SCI_PHY_STARTING* # Cont. from [3] -> sci_phy_starting_state_enter() -> host.c: sci_controller_link_down() -> ->link_down_handler() == port_config.c: sci_apc_agent_link_down() -> port.c: sci_port_remove_phy() -> isci_port_link_down() == port_config.c: sci_mpc_agent_link_down() -> port.c: sci_port_link_down() -> sci_port_deactivate_phy() -> isci_port_link_down() [1] Call chains for 'enter SCI port state: *SCI_PORT_READY*' ------------------------------------------------------------ host.c: isci_host_init() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_initialize(), atomic (*) -> port_config.c: sci_port_configuration_agent_initialize() -> sci_mpc_agent_validate_phy_configuration() -> port.c: sci_port_add_phy() -> sci_port_general_link_up_handler() -> port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* host.c: isci_host_start() (@) spin_lock_irq(isci_host::scic_lock) -> host.c: sci_controller_start(), atomic (*) -> host.c: sci_port_start() -> port.c: port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* port_config.c: apc_agent_timeout(), atomic, timer callback (*) -> sci_apc_agent_configure_ports() -> port.c: sci_port_add_phy() -> sci_port_general_link_up_handler() -> port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* port_config.c: mpc_agent_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> ->link_up_handler() == port.c: sci_apc_agent_link_up() -> sci_port_general_link_up_handler() -> port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* == port.c: sci_mpc_agent_link_up() -> port.c: sci_port_link_up() -> sci_port_general_link_up_handler() -> port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* phy.c: enter SCI state: SCI_PHY_SUB_FINAL # Cont. from [1A] -> sci_phy_starting_final_substate_enter() -> sci_change_state(SCI_PHY_READY) -> enter SCI state: *SCI_PHY_READY* -> sci_phy_ready_state_enter() -> host.c: sci_controller_link_up() -> port_agent.link_up_handler() == port_config.c: sci_apc_agent_link_up() -> port.c: sci_port_link_up() -> sci_port_general_link_up_handler() -> port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* == port_config.c: sci_mpc_agent_link_up() -> port.c: sci_port_link_up() -> sci_port_general_link_up_handler() -> port_state_machine_change(, SCI_PORT_READY) -> enter port state *SCI_PORT_READY* [1A] Call chains for entering SCI state: *SCI_PHY_SUB_FINAL* ------------------------------------------------------------ host.c: power_control_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> phy.c: sci_phy_consume_power_handler() -> phy.c: sci_change_state(SCI_PHY_SUB_FINAL) host.c: sci_controller_error_handler(): atomic, irq handler (*) OR host.c: sci_controller_completion_handler(), atomic, tasklet (*) -> sci_controller_process_completions() -> sci_controller_unsolicited_frame() -> phy.c: sci_phy_frame_handler() -> sci_change_state(SCI_PHY_SUB_AWAIT_SAS_POWER) -> sci_phy_starting_await_sas_power_substate_enter() -> host.c: sci_controller_power_control_queue_insert() -> phy.c: sci_phy_consume_power_handler() -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_controller_event_completion() -> phy.c: sci_phy_event_handler() -> sci_phy_start_sata_link_training() -> sci_change_state(SCI_PHY_SUB_AWAIT_SATA_POWER) -> sci_phy_starting_await_sata_power_substate_enter -> host.c: sci_controller_power_control_queue_insert() -> phy.c: sci_phy_consume_power_handler() -> sci_change_state(SCI_PHY_SUB_FINAL) [2] Call chains for entering state: *SCI_PHY_STOPPED* ----------------------------------------------------- host.c: isci_host_init() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_initialize(), atomic (*) -> phy.c: sci_phy_initialize() -> phy.c: sci_phy_link_layer_initialization() -> phy.c: sci_change_state(SCI_PHY_STOPPED) init.c: PCI ->remove() || PM_OPS ->suspend, process context (+) -> host.c: isci_host_deinit() -> sci_controller_stop_phys() -> phy.c: sci_phy_stop() -> sci_change_state(SCI_PHY_STOPPED) phy.c: isci_phy_control() spin_lock_irqsave(isci_host::scic_lock, ) -> sci_phy_stop(), atomic (*) -> sci_change_state(SCI_PHY_STOPPED) [3] Call chains for entering state: *SCI_PHY_STARTING* ------------------------------------------------------ phy.c: phy_sata_timeout(), atimer, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> sci_change_state(SCI_PHY_STARTING) host.c: phy_startup_timeout(), atomic, timer callback (*) spin_lock_irqsave(isci_host::scic_lock, ) -> sci_controller_start_next_phy() -> sci_phy_start() -> sci_change_state(SCI_PHY_STARTING) host.c: isci_host_start() (@) spin_lock_irq(isci_host::scic_lock) -> sci_controller_start(), atomic (*) -> sci_controller_start_next_phy() -> sci_phy_start() -> sci_change_state(SCI_PHY_STARTING) phy.c: Enter SCI state *SCI_PHY_SUB_FINAL*, atomic, check above (*) -> sci_change_state(SCI_PHY_SUB_FINAL) -> sci_phy_starting_final_substate_enter() -> sci_change_state(SCI_PHY_READY) -> Enter SCI state: *SCI_PHY_READY* -> sci_phy_ready_state_enter() -> host.c: sci_controller_link_up() -> sci_controller_start_next_phy() -> sci_phy_start() -> sci_change_state(SCI_PHY_STARTING) phy.c: sci_phy_event_handler(), atomic, discussed earlier (*) -> sci_change_state(SCI_PHY_STARTING), 11 instances phy.c: enter SCI state: *SCI_PHY_RESETTING*, atomic, discussed (*) -> sci_phy_resetting_state_enter() -> sci_change_state(SCI_PHY_STARTING) As can be seen from the "(*)" markers above, almost all the call-chains are atomic. The only exception, marked with "(+)", is a PCI ->remove() and PM_OPS ->suspend() cold path. Thus, pass GFP_ATOMIC to the libsas phy event notifier. Note, The now-replaced libsas APIs used in_interrupt() to implicitly decide which memory allocation type to use. This was only partially correct, as it fails to choose the correct GFP flags when just preemption or interrupts are disabled. Such buggy code paths are marked with "(@)" in the call chains above. Link: https://lore.kernel.org/r/20210118100955.1761652-6-a.darwish@linutronix.de Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost") Cc: Artur Paszkiewicz Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fa33884303dc7eafb04659b688dc394c6b009fc1 Author: Ahmed S. Darwish Date: Mon Jan 18 11:09:40 2021 +0100 scsi: mvsas: Pass gfp_t flags to libsas event notifiers [ Upstream commit feb18e900f0048001ff375dca639eaa327ab3c1b ] mvsas calls the non _gfp version of the libsas event notifiers API, leading to the buggy call chains below: mvsas/mv_sas.c: mvs_work_queue() [process context] spin_lock_irqsave(mvs_info::lock, ) -> libsas/sas_event.c: sas_notify_phy_event() -> sas_alloc_event() -> in_interrupt() = false -> invalid GFP_KERNEL allocation -> libsas/sas_event.c: sas_notify_port_event() -> sas_alloc_event() -> in_interrupt() = false -> invalid GFP_KERNEL allocation Use the new event notifiers API instead, which requires callers to explicitly pass the gfp_t memory allocation flags. Below are context analysis for the modified functions: => mvs_bytes_dmaed(): Since it is invoked from both process and atomic contexts, let its callers pass the gfp_t flags. Call chains: scsi_scan.c: do_scsi_scan_host() [has msleep()] -> shost->hostt->scan_start() -> [mvsas/mv_init.c: Scsi_Host::scsi_host_template .scan_start = mvs_scan_start()] -> mvsas/mv_sas.c: mvs_scan_start() -> mvs_bytes_dmaed(..., GFP_KERNEL) mvsas/mv_sas.c: mvs_work_queue() spin_lock_irqsave(mvs_info::lock,) -> mvs_bytes_dmaed(..., GFP_ATOMIC) mvsas/mv_64xx.c: mvs_64xx_isr() || mvsas/mv_94xx.c: mvs_94xx_isr() -> mvsas/mv_chips.h: mvs_int_full() -> mvsas/mv_sas.c: mvs_int_port() -> mvs_bytes_dmaed(..., GFP_ATOMIC); => mvs_work_queue(): Invoked from process context, but it calls all the libsas event notifier APIs under a spin_lock_irqsave(). Pass GFP_ATOMIC. Link: https://lore.kernel.org/r/20210118100955.1761652-5-a.darwish@linutronix.de Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost") Cc: Jason Yan Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 333d5eed1f44319ab26970d0a0129d7d1ddb2792 Author: Ahmed S. Darwish Date: Mon Jan 18 11:09:39 2021 +0100 scsi: libsas: Introduce a _gfp() variant of event notifiers [ Upstream commit c2d0f1a65ab9fbabebb463bf36f50ea8f4633386 ] sas_alloc_event() uses in_interrupt() to decide which allocation should be used. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. The in_interrupt() check is also only partially correct, because it fails to choose the correct code path when just preemption or interrupts are disabled. For example, as in the following call chain: mvsas/mv_sas.c: mvs_work_queue() [process context] spin_lock_irqsave(mvs_info::lock, ) -> libsas/sas_event.c: sas_notify_phy_event() -> sas_alloc_event() -> in_interrupt() = false -> invalid GFP_KERNEL allocation -> libsas/sas_event.c: sas_notify_port_event() -> sas_alloc_event() -> in_interrupt() = false -> invalid GFP_KERNEL allocation Introduce sas_alloc_event_gfp(), sas_notify_port_event_gfp(), and sas_notify_phy_event_gfp(), which all behave like the non _gfp() variants but use a caller-passed GFP mask for allocations. For bisectability, all callers will be modified first to pass GFP context, then the non _gfp() libsas API variants will be modified to take a gfp_t by default. Link: https://lore.kernel.org/r/20210118100955.1761652-4-a.darwish@linutronix.de Fixes: 1c393b970e0f ("scsi: libsas: Use dynamic alloced work to avoid sas event lost") Cc: Jason Yan Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 04d7a4e2f658b7dabc91ab590aa40e6e5dfb3483 Author: John Garry Date: Mon Jan 18 11:09:38 2021 +0100 scsi: libsas: Remove notifier indirection [ Upstream commit 121181f3f839c29d8dd9fdc3cc9babbdc74227f8 ] LLDDs report events to libsas with .notify_port_event and .notify_phy_event callbacks. These callbacks are fixed and so there is no reason why the functions cannot be called directly, so do that. This neatens the code slightly, makes it more obvious, and reduces function pointer usage, which is generally a good thing. Downside is that there are 2x more symbol exports. [a.darwish@linutronix.de: Remove the now unused "sas_ha" local variables] Link: https://lore.kernel.org/r/20210118100955.1761652-3-a.darwish@linutronix.de Reviewed-by: Christoph Hellwig Reviewed-by: Jack Wang Signed-off-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 23e48113dda29183fbd4243d29a6642aa00460da Author: Krzysztof Kozlowski Date: Thu Jan 21 16:59:14 2021 +0100 regulator: s5m8767: Drop regulators OF node reference [ Upstream commit a5872bd3398d0ff2ce4c77794bc7837899c69024 ] The device node reference obtained with of_get_child_by_name() should be dropped on error paths. Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210121155914.48034-1-krzk@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2e3cc0aee88f47e67d4cb0e7988580529665bc20 Author: Pan Bian Date: Tue Jan 19 21:00:25 2021 -0800 spi: atmel: Put allocated master before return [ Upstream commit 21ea2743f015dbacec1831bdc8afc848db9c2b8c ] The allocated master is not released. Goto error handling label rather than directly return. Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring") Signed-off-by: Pan Bian Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring") Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210120050025.25426-1-bianpan2016@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 36912446735683e0ec322543f6e5733cfd738c90 Author: Pan Bian Date: Wed Jan 20 19:27:56 2021 -0800 regulator: s5m8767: Fix reference count leak [ Upstream commit dea6dd2ba63f8c8532addb8f32daf7b89a368a42 ] Call of_node_put() to drop references of regulators_np and reg_np before returning error code. Fixes: 9ae5cc75ceaa ("regulator: s5m8767: Pass descriptor instead of GPIO number") Signed-off-by: Pan Bian Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210121032756.49501-1-bianpan2016@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 065830e90f80df9b49ba706905438c009ade066f Author: David Howells Date: Fri Nov 20 19:04:23 2020 +0100 certs: Fix blacklist flag type confusion [ Upstream commit 4993e1f9479a4161fd7d93e2b8b30b438f00cb0f ] KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(), as these only take KEY_ALLOC_* flags. KEY_FLAG_KEEP has the same value as KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only key_create_or_update() uses it. LSMs using the key_alloc hook don't check that flag. KEY_FLAG_KEEP is then ignored but fortunately (again) the root user cannot write to the blacklist keyring, so it is not possible to remove a key/hash from it. Fix this by adding a KEY_ALLOC_SET_KEEP flag that tells key_alloc() to set KEY_FLAG_KEEP on the new key. blacklist_init() can then, correctly, pass this to keyring_alloc(). We can also use this in ima_mok_init() rather than setting the flag manually. Note that this doesn't fix an observable bug with the current implementation but it is required to allow addition of new hashes to the blacklist in the future without making it possible for them to be removed. Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring") Reported-by: Mickaël Salaün Signed-off-by: David Howells cc: Mickaël Salaün cc: Mimi Zohar Cc: David Woodhouse Signed-off-by: Sasha Levin commit ea32c4f3551f40269f1dc16a3842eba448e53d88 Author: Gabriel Krisman Bertazi Date: Tue Nov 24 15:28:02 2020 -0500 watch_queue: Drop references to /dev/watch_queue [ Upstream commit 8fe62e0c0e2efa5437f3ee81b65d69e70a45ecd2 ] The merged API doesn't use a watch_queue device, but instead relies on pipes, so let the documentation reflect that. Fixes: f7e47677e39a ("watch_queue: Add a key/keyring notification facility") Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: David Howells Acked-by: Jarkko Sakkinen Reviewed-by: Ben Boeckel Signed-off-by: Sasha Levin commit 2a987e824e8fe229591552ef19839309f3f3d474 Author: Pan Bian Date: Wed Jan 20 04:33:13 2021 -0800 regulator: axp20x: Fix reference cout leak [ Upstream commit e78bf6be7edaacb39778f3a89416caddfc6c6d70 ] Decrements the reference count of device node and its child node. Fixes: dfe7a1b058bb ("regulator: AXP20x: Add support for regulators subsystem") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210120123313.107640-1-bianpan2016@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8afd192f3f6ed4bea7db36057c970690f73ebc0f Author: Evan Benn Date: Wed Dec 9 22:03:55 2020 +0000 platform/chrome: cros_ec_proto: Add LID and BATTERY to default mask [ Upstream commit 852405d8efcbca0e02f14592fb1d1dcd0d3fb508 ] After 'platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT' some of the flags are not quite correct. LID_CLOSED is used to suspend the device, so it makes sense to ignore that. BATTERY events are also frequent and causing spurious wakes on elm/hana mt8173 devices. Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs") Signed-off-by: Evan Benn Reviewed-by: Brian Norris Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20201209220306.2.I3291bf83e4884c206b097ede34780e014fa3e265@changeid Signed-off-by: Sasha Levin commit f09f5275c6e72aa0e56d3d2751642565b8e861ff Author: Evan Benn Date: Wed Dec 9 22:03:54 2020 +0000 platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT [ Upstream commit 0944ea07baa748741563c8842122010fa9017d16 ] The host_event_code enum is 1-based, use EC_HOST_EVENT_MASK not BIT to generate the intended mask. This patch changes the behaviour of the mask, a following patch will restore the intended behaviour: 'Add LID and BATTERY to default mask' Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs") Signed-off-by: Evan Benn Reviewed-by: Brian Norris Signed-off-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20201209220306.1.I6133572c0ab3c6b95426f804bac2d3833e24acb1@changeid Signed-off-by: Sasha Levin commit 36455e1eb1afc31a25bbacdaba1ce16965e6ac5d Author: Andre Przywara Date: Mon Jan 18 00:09:12 2021 +0000 clk: sunxi-ng: h6: Fix clock divider range on some clocks [ Upstream commit 04ef679591c76571a9e7d5ca48316cc86fa0ef12 ] While comparing clocks between the H6 and H616, some of the M factor ranges were found to be wrong: the manual says they are only covering two bits [1:0], but our code had "5" in the number-of-bits field. By writing 0xff into that register in U-Boot and via FEL, it could be confirmed that bits [4:2] are indeed masked off, so the manual is right. Change to number of bits in the affected clock's description. Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU") Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210118000912.28116-1-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 6a1d8862ec64897e807e7841fd9be6b48e0d20fe Author: Parav Pandit Date: Wed Jan 13 14:17:01 2021 +0200 IB/mlx5: Add mutex destroy call to cap_mask_mutex mutex [ Upstream commit ab40530a2e0a7aca9a5187824c4fb072f3916e85 ] mutex_destroy() call for device's cap_mask_mutex mutex is missing, let's add it to annotate destruction. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/20210113121703.559778-4-leon@kernel.org Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 01f2e63a63eed7bd2167cd5b5704812f0d5caa31 Author: Yishai Hadas Date: Wed Dec 30 15:01:19 2020 +0200 RDMA/mlx5: Use the correct obj_id upon DEVX TIR creation [ Upstream commit 8798e4ad0abe0ba1221928a46561981c510be0c6 ] Use the correct obj_id upon DEVX TIR creation by strictly taking the tirn 24 bits and not the general obj_id which is 32 bits. Fixes: 7efce3691d33 ("IB/mlx5: Add obj create and destroy functionality") Link: https://lore.kernel.org/r/20201230130121.180350-2-leon@kernel.org Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 776f20a8035aeec01cec8ac77843283ca4bd6830 Author: Guido Günther Date: Mon Jan 18 17:31:10 2021 +0100 spi: imx: Don't print error on -EPROBEDEFER [ Upstream commit 8346633f2c87713a1852d802305e03555e9a9fce ] This avoids [ 0.962538] spi_imx 30820000.spi: bitbang start failed with -517 durig driver probe. Fixes: 8197f489f4c4 ("spi: imx: Fix failure path leak on GPIO request error correctly") Signed-off-by: Guido Günther Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/0f51ab42e7c7a3452f2f8652794d81584303ea0d.1610987414.git.agx@sigxcpu.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 214aa69cac91a723239118bbbfe77d5654ddff6b Author: Frank van der Linden Date: Thu Jan 14 22:21:46 2021 +0000 module: harden ELF info handling [ Upstream commit ec2a29593c83ed71a7f16e3243941ebfcf75fdf6 ] 5fdc7db644 ("module: setup load info before module_sig_check()") moved the ELF setup, so that it was done before the signature check. This made the module name available to signature error messages. However, the checks for ELF correctness in setup_load_info are not sufficient to prevent bad memory references due to corrupted offset fields, indices, etc. So, there's a regression in behavior here: a corrupt and unsigned (or badly signed) module, which might previously have been rejected immediately, can now cause an oops/crash. Harden ELF handling for module loading by doing the following: - Move the signature check back up so that it comes before ELF initialization. It's best to do the signature check to see if we can trust the module, before using the ELF structures inside it. This also makes checks against info->len more accurate again, as this field will be reduced by the length of the signature in mod_check_sig(). The module name is now once again not available for error messages during the signature check, but that seems like a fair tradeoff. - Check if sections have offset / size fields that at least don't exceed the length of the module. - Check if sections have section name offsets that don't fall outside the section name table. - Add a few other sanity checks against invalid section indices, etc. This is not an exhaustive consistency check, but the idea is to at least get through the signature and blacklist checks without crashing because of corrupted ELF info, and to error out gracefully for most issues that would have caused problems later on. Fixes: 5fdc7db6448a ("module: setup load info before module_sig_check()") Signed-off-by: Frank van der Linden Signed-off-by: Jessica Yu Signed-off-by: Sasha Levin commit 62ecd2b17d7078ceec69c6b3c55d14ecc4c95621 Author: Tom Rix Date: Mon Jan 18 13:19:55 2021 -0800 clocksource/drivers/mxs_timer: Add missing semicolon when DEBUG is defined [ Upstream commit 7da390694afbaed8e0f05717a541dfaf1077ba51 ] When DEBUG is defined this error occurs drivers/clocksource/mxs_timer.c:138:1: error: expected ‘;’ before ‘}’ token The preceding statement needs a semicolon. Replace pr_info() with pr_debug() and remove the unneeded ifdef. Fixes: eb8703e2ef7c ("clockevents/drivers/mxs: Migrate to new 'set-state' interface") Signed-off-by: Tom Rix Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210118211955.763609-1-trix@redhat.com Signed-off-by: Sasha Levin commit 9085a3d97b3190f7f79dade1058b6235b681a46e Author: Arnd Bergmann Date: Sun Jan 3 14:59:24 2021 +0100 clocksource/drivers/ixp4xx: Select TIMER_OF when needed [ Upstream commit 7a3b8758bd6e45f7b671723b5c9fa2b69d0787ae ] Compile-testing the ixp4xx timer with CONFIG_OF enabled but CONFIG_TIMER_OF disabled leads to a harmless warning: arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ixp4xx.o' being placed in section `__timer_of_table' Move the select statement from the platform code into the driver so it always gets enabled in configurations that rely on it. Fixes: 40df14cc5cc0 ("clocksource/drivers/ixp4xx: Add OF initialization support") Signed-off-by: Arnd Bergmann Reviewed-by: Linus Walleij Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210103135955.3808976-1-arnd@kernel.org Signed-off-by: Sasha Levin commit b5724b9f7bea810174889c08342b6f8a054f5904 Author: Randy Dunlap Date: Sat Jan 16 13:13:10 2021 -0800 power: supply: fix sbs-charger build, needs REGMAP_I2C [ Upstream commit a4bdea2004b28f47ab48ea99172eda8628f6fb44 ] CHARGER_SBS should select REGMAP_I2C since it uses API(s) that are provided by that Kconfig symbol. Fixes these errors: ../drivers/power/supply/sbs-charger.c:149:21: error: variable ‘sbs_regmap’ has initializer but incomplete type static const struct regmap_config sbs_regmap = { ../drivers/power/supply/sbs-charger.c:150:3: error: ‘const struct regmap_config’ has no member named ‘reg_bits’ .reg_bits = 8, ../drivers/power/supply/sbs-charger.c:155:23: error: ‘REGMAP_ENDIAN_LITTLE’ undeclared here (not in a function) .val_format_endian = REGMAP_ENDIAN_LITTLE, /* since based on SMBus */ ../drivers/power/supply/sbs-charger.c: In function ‘sbs_probe’: ../drivers/power/supply/sbs-charger.c:183:17: error: implicit declaration of function ‘devm_regmap_init_i2c’; did you mean ‘devm_request_irq’? [-Werror=implicit-function-declaration] chip->regmap = devm_regmap_init_i2c(client, &sbs_regmap); ../drivers/power/supply/sbs-charger.c: At top level: ../drivers/power/supply/sbs-charger.c:149:35: error: storage size of ‘sbs_regmap’ isn’t known static const struct regmap_config sbs_regmap = { Fixes: feb583e37f8a ("power: supply: add sbs-charger driver") Reported-by: Martin Mokrejs Signed-off-by: Randy Dunlap Tested-by: Martin Mokrejs Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 2904bfa3a8beaa29d54aa4ea7482b19a388071a6 Author: Dave Jiang Date: Fri Jan 15 14:53:07 2021 -0700 dmaengine: idxd: set DMA channel to be private [ Upstream commit c06e424be5f5184468c5f761c0d2cf1ed0a4e0fc ] Add DMA_PRIVATE attribute flag to idxd DMA channels. The dedicated WQs are expected to be used by a single client and not shared. While doing NTB testing this mistake was discovered, which prevented ntb_transport from requesting DSA wqs as DMA channels via dma_request_channel(). Reported-by: Srinijia Kambham Signed-off-by: Dave Jiang Tested-by: Srinijia Kambham Fixes: 8f47d1a5e545 ("dmaengine: idxd: connect idxd to dmaengine subsystem") Link: https://lore.kernel.org/r/161074758743.2184057.3388557138816350980.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 39a47e4776150e992713ddbf2948b5f3a6d46e4a Author: Bartosz Golaszewski Date: Thu Jan 14 11:22:17 2021 +0100 rtc: s5m: select REGMAP_I2C [ Upstream commit 1f0cbda3b452b520c5f3794f8f0e410e8bc7386a ] The rtc-s5m uses the I2C regmap but doesn't select it in Kconfig so depending on the configuration the build may fail. Fix it. Fixes: 959df7778bbd ("rtc: Enable compile testing for Maxim and Samsung drivers") Signed-off-by: Bartosz Golaszewski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210114102219.23682-2-brgl@bgdev.pl Signed-off-by: Sasha Levin commit 5d82f643b39d5e088093333ae03291325462757c Author: Claudiu Beznea Date: Wed Dec 16 14:57:31 2020 +0200 power: reset: at91-sama5d2_shdwc: fix wkupdbc mask [ Upstream commit 95aa21a3f1183260db1b0395e03df5bebc5ed641 ] According to datasheet WKUPDBC mask is b/w bits 26..24. Fixes: f80cb48843987 ("power: reset: at91-shdwc: add new shutdown controller driver") Signed-off-by: Claudiu Beznea Reviewed-by: Alexandre Belloni Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 1f844e41074a54ffa75f84406c7de8a1ee8ed501 Author: Jack Wang Date: Thu Dec 17 15:19:15 2020 +0100 RDMA/rtrs: Fix KASAN: stack-out-of-bounds bug [ Upstream commit 7fbc3c373eefc291ff96d48496106c106b7f81c6 ] When KASAN is enabled, we notice warning below: [ 483.436975] ================================================================== [ 483.437234] BUG: KASAN: stack-out-of-bounds in _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib] [ 483.437430] Read of size 4 at addr ffff88a195fd7d30 by task kworker/1:3/6954 [ 483.437731] CPU: 1 PID: 6954 Comm: kworker/1:3 Kdump: loaded Tainted: G O 5.4.82-pserver #5.4.82-1+feature+linux+5.4.y+dbg+20201210.1532+987e7a6~deb10 [ 483.437976] Hardware name: Supermicro Super Server/X11DDW-L, BIOS 3.3 02/21/2020 [ 483.438168] Workqueue: rtrs_server_wq hb_work [rtrs_core] [ 483.438323] Call Trace: [ 483.438486] dump_stack+0x96/0xe0 [ 483.438646] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib] [ 483.438802] print_address_description.constprop.6+0x1b/0x220 [ 483.438966] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib] [ 483.439133] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib] [ 483.439285] __kasan_report.cold.9+0x1a/0x32 [ 483.439444] ? _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib] [ 483.439597] kasan_report+0x10/0x20 [ 483.439752] _mlx5_ib_post_send+0x188a/0x2560 [mlx5_ib] [ 483.439910] ? update_sd_lb_stats+0xfb1/0xfc0 [ 483.440073] ? set_reg_wr+0x520/0x520 [mlx5_ib] [ 483.440222] ? update_group_capacity+0x340/0x340 [ 483.440377] ? find_busiest_group+0x314/0x870 [ 483.440526] ? update_sd_lb_stats+0xfc0/0xfc0 [ 483.440683] ? __bitmap_and+0x6f/0x100 [ 483.440832] ? __lock_acquire+0xa2/0x2150 [ 483.440979] ? __lock_acquire+0xa2/0x2150 [ 483.441128] ? __lock_acquire+0xa2/0x2150 [ 483.441279] ? debug_lockdep_rcu_enabled+0x23/0x60 [ 483.441430] ? lock_downgrade+0x390/0x390 [ 483.441582] ? __lock_acquire+0xa2/0x2150 [ 483.441729] ? __lock_acquire+0xa2/0x2150 [ 483.441876] ? newidle_balance+0x425/0x8f0 [ 483.442024] ? __lock_acquire+0xa2/0x2150 [ 483.442172] ? debug_lockdep_rcu_enabled+0x23/0x60 [ 483.442330] hb_work+0x15d/0x1d0 [rtrs_core] [ 483.442479] ? schedule_hb+0x50/0x50 [rtrs_core] [ 483.442627] ? lock_downgrade+0x390/0x390 [ 483.442781] ? process_one_work+0x40d/0xa50 [ 483.442931] process_one_work+0x4ee/0xa50 [ 483.443082] ? pwq_dec_nr_in_flight+0x110/0x110 [ 483.443231] ? do_raw_spin_lock+0x119/0x1d0 [ 483.443383] worker_thread+0x65/0x5c0 [ 483.443532] ? process_one_work+0xa50/0xa50 [ 483.451839] kthread+0x1e2/0x200 [ 483.451983] ? kthread_create_on_node+0xc0/0xc0 [ 483.452139] ret_from_fork+0x3a/0x50 The problem is we use wrong type when send wr, hw driver expect the type of IB_WR_RDMA_WRITE_WITH_IMM wr should be ib_rdma_wr, and doing container_of to access member. The fix is simple use ib_rdma_wr instread of ib_send_wr. Fixes: c0894b3ea69d ("RDMA/rtrs: core: lib functions shared between client and server modules") Link: https://lore.kernel.org/r/20201217141915.56989-20-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Reviewed-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e06f0e929c5fdbc3dcd7041d51216ea58792c86b Author: Jack Wang Date: Thu Dec 17 15:19:14 2020 +0100 RDMA/rtrs-srv: Init wr_cnt as 1 [ Upstream commit 6f5d1b3016d650f351e65c645a5eee5394547dd0 ] Fix up wr_avail accounting. if wr_cnt is 0, then we do SIGNAL for first wr, in completion we add queue_depth back, which is not right in the sense of tracking for available wr. So fix it by init wr_cnt to 1. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-19-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Signed-off-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit fba5f5e118b3e2689004937706b9314ba3625336 Author: Guoqing Jiang Date: Thu Dec 17 15:19:10 2020 +0100 RDMA/rtrs-clt: Refactor the failure cases in alloc_clt [ Upstream commit eab098246625e91c1cbd6e8f75b09e4c9c28a9fc ] Make all failure cases go to the common path to avoid duplicate code. And some issued existed before. 1. clt need to be freed to avoid memory leak. 2. return ERR_PTR(-ENOMEM) if kobject_create_and_add fails, because rtrs_clt_open checks the return value of by call "IS_ERR(clt)". Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-15-jinpu.wang@cloud.ionos.com Signed-off-by: Guoqing Jiang Reviewed-by: Md Haris Iqbal Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 608ea87d965a976e68e266805d1692cef605d223 Author: Jack Wang Date: Thu Dec 17 15:19:09 2020 +0100 RDMA/rtrs-srv: Fix missing wr_cqe [ Upstream commit 8537f2de6519945890a2b0f3739b23f32b5c0a89 ] We had a few places wr_cqe is not set, which could lead to NULL pointer deref or GPF in error case. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-14-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Reviewed-by: Md Haris Iqbal Signed-off-by: Guoqing Jiang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4d7e175f36e0e7fa5594a40be589ee38f72e38e0 Author: Guoqing Jiang Date: Thu Dec 17 15:19:03 2020 +0100 RDMA/rtrs: Call kobject_put in the failure path [ Upstream commit 424774c9f3fa100ef7d9cfb9ee211e2ba1cd5119 ] Per the comment of kobject_init_and_add, we need to free the memory by call kobject_put. Fixes: 215378b838df ("RDMA/rtrs: client: sysfs interface functions") Fixes: 91b11610af8d ("RDMA/rtrs: server: sysfs interface functions") Link: https://lore.kernel.org/r/20201217141915.56989-8-jinpu.wang@cloud.ionos.com Signed-off-by: Guoqing Jiang Reviewed-by: Md Haris Iqbal Reviewed-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9178805a1c737c49d57414f0d7b944e1e2ee9a1f Author: Guoqing Jiang Date: Thu Dec 17 15:19:02 2020 +0100 RDMA/rtrs-srv: Jump to dereg_mr label if allocate iu fails [ Upstream commit f77c4839ee8f4612dcb6601602329096030bd813 ] The rtrs_iu_free is called in rtrs_iu_alloc if memory is limited, so we don't need to free the same iu again. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-7-jinpu.wang@cloud.ionos.com Signed-off-by: Guoqing Jiang Reviewed-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3429e89505c850b704252281f0ed37d81ae515fa Author: Jack Wang Date: Thu Dec 17 15:19:01 2020 +0100 RDMA/rtrs-clt: Set mininum limit when create QP [ Upstream commit f47e4e3e71724f625958b0059f6c8ac5d44d27ef ] Currently rtrs when create_qp use a coarse numbers (bigger in general), which leads to hardware create more resources which only waste memory with no benefits. - SERVICE con, For max_send_wr/max_recv_wr, it's 2 times SERVICE_CON_QUEUE_DEPTH + 2 - IO con For max_send_wr/max_recv_wr, it's sess->queue_depth * 3 + 1 Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-6-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Reviewed-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 71b335154800e6886b13527a8f99b4248531a42a Author: Jack Wang Date: Thu Dec 17 15:19:00 2020 +0100 RDMA/rtrs-srv: Use sysfs_remove_file_self for disconnect [ Upstream commit f991fdac813f1598a9bb17b602ce04812ba9148c ] Remove self first to avoid deadlock, we don't want to use close_work to remove sess sysfs. Fixes: 91b11610af8d ("RDMA/rtrs: server: sysfs interface functions") Link: https://lore.kernel.org/r/20201217141915.56989-5-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Tested-by: Lutz Pogrell Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 92fa652008d801a0c405f15afcff982c6ee8ee01 Author: Jack Wang Date: Thu Dec 17 15:18:59 2020 +0100 RDMA/rtrs-srv: Release lock before call into close_sess [ Upstream commit 99f0c3807973359bba8f37d9198eea59fe38c32a ] In this error case, we don't need hold mutex to call close_sess. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20201217141915.56989-4-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Tested-by: Lutz Pogrell Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d6f63d0ab82905ac4a06814bc6b24ae9dea28845 Author: Jack Wang Date: Thu Dec 17 15:18:57 2020 +0100 RDMA/rtrs: Extend ibtrs_cq_qp_create [ Upstream commit 7490fd1fe836ba3c7eda7a4b1cfd9e44389ffda5 ] rtrs does not have same limit for both max_send_wr and max_recv_wr, To allow client and server set different values, export in a separate parameter for rtrs_cq_qp_create. Also fix the type accordingly, u32 should be used instead of u16. Fixes: c0894b3ea69d ("RDMA/rtrs: core: lib functions shared between client and server modules") Link: https://lore.kernel.org/r/20201217141915.56989-2-jinpu.wang@cloud.ionos.com Signed-off-by: Jack Wang Reviewed-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c6b812037a6657edb5a8480b29549006a9becc1f Author: Nicolas Boichat Date: Fri Jan 15 11:45:44 2021 +0000 of/fdt: Make sure no-map does not remove already reserved regions [ Upstream commit 8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ] If the device tree is incorrectly configured, and attempts to define a "no-map" reserved memory that overlaps with the kernel data/code, the kernel would crash quickly after boot, with no obvious clue about the nature of the issue. For example, this would happen if we have the kernel mapped at these addresses (from /proc/iomem): 40000000-41ffffff : System RAM 40080000-40dfffff : Kernel code 40e00000-411fffff : reserved 41200000-413e0fff : Kernel data And we declare a no-map shared-dma-pool region at a fixed address within that range: mem_reserved: mem_region { compatible = "shared-dma-pool"; reg = <0 0x40000000 0 0x01A00000>; no-map; }; To fix this, when removing memory regions at early boot (which is what "no-map" regions do), we need to make sure that the memory is not already reserved. If we do, __reserved_mem_reserve_reg will throw an error: [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory for node 'mem_region': base 0x0000000040000000, size 26 MiB and the code that will try to use the region should also fail, later on. We do not do anything for non-"no-map" regions, as memblock explicitly allows reserved regions to overlap, and the commit that this fixes removed the check for that precise reason. [ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ] Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap") Signed-off-by: Nicolas Boichat Reviewed-by: Stephen Boyd Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 3b0f824e9689116777d647b688a9cdcefa82b4e8 Author: KarimAllah Ahmed Date: Fri Jan 15 11:45:43 2021 +0000 fdt: Properly handle "no-map" field in the memory region [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ] Mark the memory region with NOMAP flag instead of completely removing it from the memory blocks. That makes the FDT handling consistent with the EFI memory map handling. Cc: Rob Herring Cc: Frank Rowand Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit cea5dc9e121b85189790168d019029f1857fbf3b Author: Colin Ian King Date: Fri Jan 15 13:15:24 2021 +0000 power: supply: cpcap-charger: Fix power_supply_put on null battery pointer [ Upstream commit 39196cfe10dd2b46ee28b44abbc0db4f4cb7822f ] Currently if the pointer battery is null there is a null pointer dereference on the call to power_supply_put. Fix this by only performing the put if battery is not null. Addresses-Coverity: ("Dereference after null check") Fixes: 4bff91bb3231 ("power: supply: cpcap-charger: Fix missing power_supply_put()") Signed-off-by: Colin Ian King Acked-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c2d2d168e64957559fe0328d09712c5b5051800b Author: Can Guo Date: Wed Jan 13 19:13:27 2021 -0800 scsi: ufs: Fix a possible NULL pointer issue [ Upstream commit fb7afe24ba1b7e27483be7d2ac3ed002e67eecd5 ] During system resume/suspend, hba could be NULL. In this case, do not touch eh_sem. Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and async scan") Link: https://lore.kernel.org/r/1610594010-7254-2-git-send-email-cang@codeaurora.org Acked-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dbf415f7c6a20ad12317ce4b8ab77d352896970a Author: Tony Lindgren Date: Sun Jan 10 21:53:50 2021 +0200 power: supply: cpcap-battery: Fix missing power_supply_put() [ Upstream commit 97456a24acb41b74ab6910f40fb8f09b206fd3b5 ] Fix missing power_supply_put(). Cc: Arthur Demchenkov Cc: Carl Philipp Klemm Cc: Merlijn Wajer Cc: Pavel Machek Fixes: 8b0134cc14b9 ("power: supply: cpcap-battery: Fix handling of lowered charger voltage") Signed-off-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 8dba893974799fa32db9b0f0822cbb37441f19ac Author: Tony Lindgren Date: Sun Jan 10 21:53:49 2021 +0200 power: supply: cpcap-charger: Fix missing power_supply_put() [ Upstream commit 4bff91bb3231882b530af794c92ac3a5fe199481 ] Fix missing power_supply_put(). Cc: Arthur Demchenkov Cc: Carl Philipp Klemm Cc: Merlijn Wajer Cc: Pavel Machek Fixes: 5688ea049233 ("power: supply: cpcap-charger: Allow changing constant charge voltage") Signed-off-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 7ac642e48280dd69f3fd4e62e6b30e08c3c778c6 Author: Yoshihiro Shimoda Date: Tue Jan 12 18:00:56 2021 +0900 mfd: bd9571mwv: Use devm_mfd_add_devices() [ Upstream commit c58ad0f2b052b5675d6394e03713ee41e721b44c ] To remove mfd devices when unload this driver, should use devm_mfd_add_devices() instead. Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver") Signed-off-by: Yoshihiro Shimoda Acked-for-MFD-by: Lee Jones Reviewed-by: Geert Uytterhoeven Reviewed-by: Matti Vaittinen Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8fe1901ad7cb1b5b88a74c2a3e83b5b1078a26d4 Author: Ferry Toth Date: Tue Jan 12 23:37:49 2021 +0100 dmaengine: hsu: disable spurious interrupt [ Upstream commit 035b73b2b3b2e074a56489a7bf84b6a8012c0e0d ] On Intel Tangier B0 and Anniedale the interrupt line, disregarding to have different numbers, is shared between HSU DMA and UART IPs. Thus on such SoCs we are expecting that IRQ handler is called in UART driver only. hsu_pci_irq was handling the spurious interrupt from HSU DMA by returning immediately. This wastes CPU time and since HSU DMA and HSU UART interrupt occur simultaneously they race to be handled causing delay to the HSU UART interrupt handling. Fix this by disabling the interrupt entirely. Fixes: 4831e0d9054c ("serial: 8250_mid: handle interrupt correctly in DMA case") Signed-off-by: Ferry Toth Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210112223749.97036-1-ftoth@exalondelft.nl Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 683ea7cffae8b67b7daa564f199fd8c4fa4fda03 Author: Vignesh Raghavendra Date: Tue Jan 12 19:44:03 2021 +0530 dmaengine: ti: k3-udma: Set rflow count for BCDMA split channels [ Upstream commit aecf9d38361090857aa58708e500ee79bed1e273 ] BCDMA RX channels have one flow per channel, therefore set the rflow_cnt to rchan_cnt. Without this patch, request for BCDMA RX channel allocation fails as rflow_cnt is 0 thus fails to reserve a rflow for the channel. Fixes: 8844898028d4 ("dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling") Signed-off-by: Vignesh Raghavendra Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210112141403.30286-1-vigneshr@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit be5df6a0d48890fb22a22a77676d7b9c25ad0699 Author: Nathan Chancellor Date: Tue Jan 12 12:12:14 2021 -0700 dmaengine: qcom: Always inline gpi_update_reg [ Upstream commit 0a6d3038d914b51d6860f23ea2b508590e8340de ] When building with CONFIG_UBSAN_UNSIGNED_OVERFLOW, clang decides not to inline gpi_update_reg, which causes a linkage failure around __bad_mask: ld.lld: error: undefined symbol: __bad_mask >>> referenced by bitfield.h:119 (include/linux/bitfield.h:119) >>> dma/qcom/gpi.o:(gpi_update_reg) in archive drivers/built-in.a >>> referenced by bitfield.h:119 (include/linux/bitfield.h:119) >>> dma/qcom/gpi.o:(gpi_update_reg) in archive drivers/built-in.a If gpi_update_reg is not inlined, the mask value will not be known at compile time so the check in field_multiplier stays in the final object file, causing the above linkage failure. Always inline gpi_update_reg so that this check can never fail. Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Link: https://github.com/ClangBuiltLinux/linux/issues/1243 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210112191214.1264793-1-natechancellor@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 649b59e044b033023cccd9f4950a6bb563fcb746 Author: Arnd Bergmann Date: Wed Dec 30 15:59:11 2020 +0100 rtc: rx6110: fix build against modular I2C [ Upstream commit def8550f543e6c9101f3e1a03160b2aab8c02e8a ] With CONFIG_I2C=m, the #ifdef section is disabled, as shown by this warning: drivers/rtc/rtc-rx6110.c:314:12: error: unused function 'rx6110_probe' [-Werror,-Wunused-function] Change the driver to use IS_ENABLED() instead, which works for both module and built-in subsystems. Fixes: afa819c2c6bf ("rtc: rx6110: add i2c support") Signed-off-by: Arnd Bergmann Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20201230145938.3254459-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 7edddd194121bdae17d6326b78e40b8169f57a6f Author: Christophe JAILLET Date: Sat Dec 12 17:25:35 2020 +0100 dmaengine: owl-dma: Fix a resource leak in the remove function [ Upstream commit 1f0a16f04113f9f0ab0c8e6d3abe661edab549e6 ] A 'dma_pool_destroy()' call is missing in the remove function. Add it. This call is already made in the error handling path of the probe function. Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201212162535.95727-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 34264b7f648033511a628aebf575aa5d8b81557f Author: Christophe JAILLET Date: Sat Dec 12 17:06:14 2020 +0100 dmaengine: fsldma: Fix a resource leak in an error handling path of the probe function [ Upstream commit b202d4e82531a62a33a6b14d321dd2aad491578e ] In case of error, the previous 'fsl_dma_chan_probe()' calls must be undone by some 'fsl_dma_chan_remove()', as already done in the remove function. It was added in the remove function in commit 77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as a module") Fixes: d3f620b2c4fe ("fsldma: simplify IRQ probing and handling") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201212160614.92576-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bbd3614023e90494ebfb7bdc9cd8648c9ff604e8 Author: Christophe JAILLET Date: Sat Dec 12 17:05:16 2020 +0100 dmaengine: fsldma: Fix a resource leak in the remove function [ Upstream commit cbc0ad004c03ad7971726a5db3ec84dba3dcb857 ] A 'irq_dispose_mapping()' call is missing in the remove function. Add it. This is needed to undo the 'irq_of_parse_and_map() call from the probe function and already part of the error handling path of the probe function. It was added in the probe function only in commit d3f620b2c4fe ("fsldma: simplify IRQ probing and handling") Fixes: 77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as a module") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201212160516.92515-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a146122b7b54d51aba1dab075e4648195dc31223 Author: Bernard Metzler Date: Fri Jan 8 13:58:45 2021 +0100 RDMA/siw: Fix handling of zero-sized Read and Receive Queues. [ Upstream commit 661f385961f06f36da24cf408d461f988d0c39ad ] During connection setup, the application may choose to zero-size inbound and outbound READ queues, as well as the Receive queue. This patch fixes handling of zero-sized queues, but not prevents it. Kamal Heib says in an initial error report: When running the blktests over siw the following shift-out-of-bounds is reported, this is happening because the passed IRD or ORD from the ulp could be zero which will lead to unexpected behavior when calling roundup_pow_of_two(), fix that by blocking zero values of ORD or IRD. UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 20 PID: 3957 Comm: kworker/u64:13 Tainted: G S 5.10.0-rc6 #2 Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016 Workqueue: iw_cm_wq cm_work_handler [iw_cm] Call Trace: dump_stack+0x99/0xcb ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold.11+0xb4/0xf3 ? down_write+0x183/0x3d0 siw_qp_modify.cold.8+0x2d/0x32 [siw] ? __local_bh_enable_ip+0xa5/0xf0 siw_accept+0x906/0x1b60 [siw] ? xa_load+0x147/0x1f0 ? siw_connect+0x17a0/0x17a0 [siw] ? lock_downgrade+0x700/0x700 ? siw_get_base_qp+0x1c2/0x340 [siw] ? _raw_spin_unlock_irqrestore+0x39/0x40 iw_cm_accept+0x1f4/0x430 [iw_cm] rdma_accept+0x3fa/0xb10 [rdma_cm] ? check_flush_dependency+0x410/0x410 ? cma_rep_recv+0x570/0x570 [rdma_cm] nvmet_rdma_queue_connect+0x1a62/0x2680 [nvmet_rdma] ? nvmet_rdma_alloc_cmds+0xce0/0xce0 [nvmet_rdma] ? lock_release+0x56e/0xcc0 ? lock_downgrade+0x700/0x700 ? lock_downgrade+0x700/0x700 ? __xa_alloc_cyclic+0xef/0x350 ? __xa_alloc+0x2d0/0x2d0 ? rdma_restrack_add+0xbe/0x2c0 [ib_core] ? __ww_mutex_die+0x190/0x190 cma_cm_event_handler+0xf2/0x500 [rdma_cm] iw_conn_req_handler+0x910/0xcb0 [rdma_cm] ? _raw_spin_unlock_irqrestore+0x39/0x40 ? trace_hardirqs_on+0x1c/0x150 ? cma_ib_handler+0x8a0/0x8a0 [rdma_cm] ? __kasan_kmalloc.constprop.7+0xc1/0xd0 cm_work_handler+0x121c/0x17a0 [iw_cm] ? iw_cm_reject+0x190/0x190 [iw_cm] ? trace_hardirqs_on+0x1c/0x150 process_one_work+0x8fb/0x16c0 ? pwq_dec_nr_in_flight+0x320/0x320 worker_thread+0x87/0xb40 ? __kthread_parkme+0xd1/0x1a0 ? process_one_work+0x16c0/0x16c0 kthread+0x35f/0x430 ? kthread_mod_delayed_work+0x180/0x180 ret_from_fork+0x22/0x30 Fixes: a531975279f3 ("rdma/siw: main include file") Fixes: f29dd55b0236 ("rdma/siw: queue pair methods") Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Fixes: b9be6f18cf9e ("rdma/siw: transmit path") Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Link: https://lore.kernel.org/r/20210108125845.1803-1-bmt@zurich.ibm.com Reported-by: Kamal Heib Reported-by: Yi Zhang Reported-by: kernel test robot Signed-off-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d7704a6a5cbec79ef76d37a7f44becd6da018363 Author: Randy Dunlap Date: Wed Dec 16 17:12:21 2020 -0800 HID: core: detect and skip invalid inputs to snto32() [ Upstream commit a0312af1f94d13800e63a7d0a66e563582e39aec ] Prevent invalid (0, 0) inputs to hid-core's snto32() function. Maybe it is just the dummy device here that is causing this, but there are hundreds of calls to snto32(0, 0). Having n (bits count) of 0 is causing the current UBSAN trap with a shift value of 0xffffffff (-1, or n - 1 in this function). Either of the value to shift being 0 or the bits count being 0 can be handled by just returning 0 to the caller, avoiding the following complex shift + OR operations: return value & (1 << (n - 1)) ? value | (~0U << n) : value; Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Signed-off-by: Randy Dunlap Reported-by: syzbot+1e911ad71dd4ea72e04a@syzkaller.appspotmail.com Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 758ed157fdae5e6a9ff3eeebebed46652b09c97f Author: Geert Uytterhoeven Date: Mon Oct 19 14:06:10 2020 +0200 clk: renesas: r8a779a0: Fix parent of CBFUSA clock [ Upstream commit 80d3e07ec509c5098d44e4f1416cc9f133fd436f ] According to Figure 8.1.1 ("Block Diagram of CPG (R-Car V3U-AD)") in the R-Car V3U Series User's Manual Rev. 0.5, the parent of the CBFUSA clock is EXTAL. Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U") Signed-off-by: Geert Uytterhoeven Reviewed-by: Yoshihiro Shimoda Tested-by: Wolfram Sang Link: https://lore.kernel.org/r/20201019120614.22149-3-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 12b034515e890684043852efe939d830a116ba1f Author: Geert Uytterhoeven Date: Mon Oct 19 14:06:09 2020 +0200 clk: renesas: r8a779a0: Remove non-existent S2 clock [ Upstream commit 5b30be15ca262d9cb2c36b173bb488e8d1952ea0 ] The S2 internal core clock does not exist on R-Car V3U. Remove it. Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U") Signed-off-by: Geert Uytterhoeven Reviewed-by: Yoshihiro Shimoda Tested-by: Wolfram Sang Link: https://lore.kernel.org/r/20201019120614.22149-2-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6b3cdd1d97c61c18f21d73b7e54baa1c62dffd47 Author: Andre Przywara Date: Wed Jan 6 14:32:46 2021 +0000 clk: sunxi-ng: h6: Fix CEC clock [ Upstream commit 756650820abd4770c4200763505b634a3c04e05e ] The CEC clock on the H6 SoC is a bit special, since it uses a fixed pre-dividier for one source clock (the PLL), but conveys the other clock (32K OSC) directly. We are using a fixed predivider array for that, but fail to use the right flag to actually activate that. Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU") Reported-by: Jernej Skrabec Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210106143246.11255-1-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 1c9339a5659f5f26a213276cdf3835de478bde58 Author: Pratyush Yadav Date: Wed Dec 23 00:14:20 2020 +0530 spi: cadence-quadspi: Abort read if dummy cycles required are too many [ Upstream commit ceeda328edeeeeac7579e9dbf0610785a3b83d39 ] The controller can only support up to 31 dummy cycles. If the command requires more it falls back to using 31. This command is likely to fail because the correct number of cycles are not waited upon. Rather than silently issuing an incorrect command, fail loudly so the caller can get a chance to find out the command can't be supported by the controller. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Pratyush Yadav Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 010c7de54f779ba56275fb6180447e3c446cbcc7 Author: Rayagonda Kokatanur Date: Mon Nov 2 09:24:32 2020 +0530 i2c: iproc: handle master read request [ Upstream commit e21d79778768e4e187b2892d662c6aaa01e1d399 ] Handle single or multi byte master read request with or without repeated start. Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode") Signed-off-by: Rayagonda Kokatanur Acked-by: Ray Jui Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7c0388c0b1d602af7f19ca03cbfbe5bcf3d0a8be Author: Rayagonda Kokatanur Date: Mon Nov 2 09:24:30 2020 +0530 i2c: iproc: update slave isr mask (ISR_MASK_SLAVE) [ Upstream commit 603e77af7b0704bdb057de0368f1f2b04fc9552c ] Update slave isr mask (ISR_MASK_SLAVE) to include remaining two slave interrupts. Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode") Signed-off-by: Rayagonda Kokatanur Acked-by: Ray Jui Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 609e4e6b9d9ba5dcc3c6b4e902eea5f7efd34fa7 Author: Rayagonda Kokatanur Date: Mon Nov 2 09:24:29 2020 +0530 i2c: iproc: handle only slave interrupts which are enabled [ Upstream commit 545f4011e156554d704d6278245d54543f6680d1 ] Handle only slave interrupts which are enabled. The IS_OFFSET register contains the interrupt status bits which will be set regardless of the enabling of the corresponding interrupt condition. One must therefore look at both IS_OFFSET and IE_OFFSET to determine whether an interrupt condition is set and enabled. Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode") Signed-off-by: Rayagonda Kokatanur Acked-by: Ray Jui Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 2861bf1f507e961699f0aea216db9f339bee835b Author: Jan Kara Date: Tue Dec 22 12:09:53 2020 +0100 quota: Fix memory leak when handling corrupted quota file [ Upstream commit a4db1072e1a3bd7a8d9c356e1902b13ac5deb8ef ] When checking corrupted quota file we can bail out and leak allocated info structure. Properly free info structure on error return. Reported-by: syzbot+77779c9b52ab78154b08@syzkaller.appspotmail.com Fixes: 11c514a99bb9 ("quota: Sanity-check quota file headers on load") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 7b0f0e83af4e26541af36f58b67297e3f28ba46d Author: Dmitry Baryshkov Date: Thu Dec 31 15:23:48 2020 +0300 arm64: dts: qcom: qrb5165-rb5: fix pm8009 regulators [ Upstream commit c3da02421230639bf6ee5462b70b58f5b7f3b7c6 ] Fix pm8009 compatibility string to reference pm8009 revision specific to sm8250 platform. Also add S2 regulator to be used for qca639x. Signed-off-by: Dmitry Baryshkov Fixes: b1d2674e6121 ("arm64: dts: qcom: Add basic devicetree support for QRB5165 RB5") Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20201231122348.637917-5-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a6db7d6195232987c99c8aa27c1c6b455b3307a9 Author: Dmitry Baryshkov Date: Thu Dec 31 15:23:47 2020 +0300 regulator: qcom-rpmh-regulator: add pm8009-1 chip revision [ Upstream commit 951384cabc5dfb09251d440dbc26058eba86f97e ] PM8009 has special revision (P=1), which is to be used for sm8250 platform. The major difference is the S2 regulator which supplies 0.95 V instead of 2.848V. Declare regulators data to be used for this chip revision. The datasheet calls the chip just pm8009-1, so use the same name. Signed-off-by: Dmitry Baryshkov Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20201231122348.637917-4-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fe7151072981c41ca5acb2bc110d6b4f6ef2a3b0 Author: Po-Hsu Lin Date: Mon Dec 28 12:34:59 2020 +0800 selftests/powerpc: Make the test check in eeh-basic.sh posix compliant [ Upstream commit 3db380570af7052620ace20c29e244938610ca71 ] The == operand is a bash extension, thus this will fail on Ubuntu with: ./eeh-basic.sh: 89: test: 2: unexpected operator As the /bin/sh on Ubuntu is pointed to DASH. Use -eq to fix this posix compatibility issue. Fixes: 996f9e0f93f162 ("selftests/powerpc: Fix eeh-basic.sh exit codes") Signed-off-by: Po-Hsu Lin Reviewed-by: Frederic Barrat Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201228043459.14281-1-po-hsu.lin@canonical.com Signed-off-by: Sasha Levin commit 3f3040b25e7e34e362776c917fb6790bb3bb6459 Author: Martin Blumenstingl Date: Sat Dec 26 13:15:56 2020 +0100 clk: meson: clk-pll: propagate the error from meson_clk_pll_set_rate() [ Upstream commit ccdc1f0836f8e37b558a424f1e491f929b2e7ede ] Popagate the error code from meson_clk_pll_set_rate() when the PLL does not lock with the new settings. Fixes: 722825dcd54b2e ("clk: meson: migrate plls clocks to clk_regmap") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20201226121556.975418-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit e5a7f576022b161dc112b541dba3642ad9be22cd Author: Martin Blumenstingl Date: Sat Dec 26 13:15:55 2020 +0100 clk: meson: clk-pll: make "ret" a signed integer [ Upstream commit 9e717285f0bd591d716fa0e7418f2cdaf756dd25 ] The error codes returned by meson_clk_get_pll_settings() are all negative. Make "ret" a signed integer in meson_clk_pll_set_rate() to make it match with the clk_ops.set_rate API as well as the data type returned by meson_clk_get_pll_settings(). Fixes: 8eed1db1adec6a ("clk: meson: pll: update driver for the g12a") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20201226121556.975418-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 79003c3cf8dabc5b21a09375f97ce67efcbf65ec Author: Martin Blumenstingl Date: Sat Dec 26 13:15:54 2020 +0100 clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL [ Upstream commit 2f290b7c67adf6459a17a4c978102af35cd62e4a ] The "rate" parameter in meson_clk_pll_set_rate() contains the new rate. Retrieve the old rate with clk_hw_get_rate() so we don't inifinitely try to switch from the new rate to the same rate again. Fixes: 7a29a869434e8b ("clk: meson: Add support for Meson clock controller") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20201226121556.975418-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit aa614bcab3f757b164374e490628f25c02f30a64 Author: Tony Lindgren Date: Wed Dec 30 12:19:11 2020 +0200 power: supply: cpcap: Add missing IRQF_ONESHOT to fix regression [ Upstream commit e62333e26be649bfc3c167b9f2bbca38b92332c5 ] Commit 25d76fed7ffe ("phy: cpcap-usb: Use IRQF_ONESHOT") started causing errors loading phy-cpcap-usb driver: cpcap_battery cpcap_battery.0: failed to register power supply genirq: Flags mismatch irq 211. 00002080 (se0conn) vs. 00000080 (se0conn) cpcap-usb-phy cpcap-usb-phy.0: could not get irq se0conn: -16 Let's fix this by adding the missing IRQF_ONESHOT to also cpcap-battery and cpcap-charger drivers. Fixes: 25d76fed7ffe ("phy: cpcap-usb: Use IRQF_ONESHOT") Reported-by: Merlijn Wajer Signed-off-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b83ca7e9d057882a0f6b4ff9e19947dddc385a0f Author: Zhang Qilong Date: Mon Nov 23 18:18:27 2020 +0800 HSI: Fix PM usage counter unbalance in ssi_hw_init [ Upstream commit aa57e77b3d28f0df07149d88c47bc0f3aa77330b ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: b209e047bc743 ("HSI: Introduce OMAP SSI driver") Signed-off-by: Zhang Qilong Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c5ba44b542cefa14e9700ac3f4e7e086ebf33ac1 Author: Eric W. Biederman Date: Thu Dec 17 09:42:00 2020 -0600 capabilities: Don't allow writing ambiguous v3 file capabilities [ Upstream commit 95ebabde382c371572297915b104e55403674e73 ] The v3 file capabilities have a uid field that records the filesystem uid of the root user of the user namespace the file capabilities are valid in. When someone is silly enough to have the same underlying uid as the root uid of multiple nested containers a v3 filesystem capability can be ambiguous. In the spirit of don't do that then, forbid writing a v3 filesystem capability if it is ambiguous. Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") Reviewed-by: Andrew G. Morgan Reviewed-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 665a38726bcd44d3e9f8c6452638ae263412bfac Author: Dmitry Torokhov Date: Fri Dec 18 10:03:12 2020 -0800 Input: imx_keypad - add dependency on HAS_IOMEM [ Upstream commit f5cace4b93d736cef348211ae0814cabdd26d86a ] devm_platform_ioremap_resource() depends on CONFIG_HAS_IOMEM, so let's add it to the dependencies when COMPILE_TEST is enabled. Reported-by: kernel test robot Fixes: c8834032ffe2 ("Input: imx_keypad - add COMPILE_TEST support") Link: https://lore.kernel.org/r/X9llpA3w1zlZCHXU@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 7f267c28452f01f78cb5aba9ef32f0944855b682 Author: Dmitry Torokhov Date: Fri Dec 18 10:01:33 2020 -0800 Input: da7280 - protect OF match table with CONFIG_OF [ Upstream commit 6d2ad82fece2f5adcafe77252614fcf7211dec28 ] The OF match table is only used when OF is enabled. Fixes: cd3f609823a5 ("Input: new da7280 haptic driver") Reported-by: kernel test robot Acked-by: Roy Im Link: https://lore.kernel.org/r/X9xRLVPt9eBi0CT6@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 596cdf77faa241a9aca11753ad06902fae6df187 Author: Dmitry Torokhov Date: Tue Dec 15 17:41:16 2020 -0800 Input: da7280 - fix missing error test [ Upstream commit 1e2020aa0da00051d94c4690c023c45d8f3834bd ] An "if" testing for error condition has accidentally been dropped from the code. Reported-by: kernel test robot Fixes: cd3f609823a5 ("Input: new da7280 haptic driver") Reviewed-by: Roy Im Link: https://lore.kernel.org/r/X9j8lGFgijzHyYZZ@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit bb86d1c693ce98f8e2ba8611f149fd6c7cc07ea2 Author: Nirmoy Das Date: Wed Feb 10 18:11:04 2021 +0100 drm/amdgpu/display: remove hdcp_srm sysfs on device removal [ Upstream commit e96b1b2974989c6a25507b527843ede7594efc85 ] Fixes: 9037246bb2da5 ("drm/amd/display: Add sysfs interface for set/get srm") Signed-off-by: Nirmoy Das Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0844f7ee5d132f2455afbdb3f44a0b6da640bc32 Author: Sebastian Andrzej Siewior Date: Sat Jan 23 21:10:25 2021 +0100 smp: Process pending softirqs in flush_smp_call_function_from_idle() [ Upstream commit f9d34595ae4feed38856b88769e2ba5af22d2548 ] send_call_function_single_ipi() may wake an idle CPU without sending an IPI. The woken up CPU will process the SMP-functions in flush_smp_call_function_from_idle(). Any raised softirq from within the SMP-function call will not be processed. Should the CPU have no tasks assigned, then it will go back to idle with pending softirqs and the NOHZ will rightfully complain. Process pending softirqs on return from flush_smp_call_function_queue(). Fixes: b2a02fc43a1f4 ("smp: Optimize send_call_function_single_ipi()") Reported-by: Jens Axboe Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210123201027.3262800-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit ad5b15a68f9a19136969672ebe7183cb89f1e1bd Author: Geert Uytterhoeven Date: Mon Feb 8 15:56:05 2021 +0100 irqchip/imx: IMX_INTMUX should not default to y, unconditionally [ Upstream commit a890caeb2ba40ca183969230e204ab144f258357 ] Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of IMX_INTMUX to ARCH_MXC, and ask the user in case of compile-testing. Fixes: 66968d7dfc3f5451 ("irqchip: Add COMPILE_TEST support for IMX_INTMUX") Signed-off-by: Geert Uytterhoeven Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210208145605.422943-1-geert+renesas@glider.be Signed-off-by: Sasha Levin commit c7fd492e3a450ca7178e82524d300aac93093b31 Author: Wang ShaoBo Date: Sun Nov 15 16:23:43 2020 +0800 ubifs: Fix error return code in alloc_wbufs() [ Upstream commit 42119dbe571eb419dae99b81dd20fa42f47464e1 ] Fix to return PTR_ERR() error code from the error handling case instead fo 0 in function alloc_wbufs(), as done elsewhere in this function. Fixes: 6a98bc4614de ("ubifs: Add authentication nodes to journal") Signed-off-by: Wang ShaoBo Reviewed-by: Sascha Hauer Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit c9a6c5eb7de43c1fb787cbcdbf01d1a187ed409a Author: Arnd Bergmann Date: Thu Jan 14 22:30:11 2021 +0100 ubifs: replay: Fix high stack usage, again [ Upstream commit 410b6de702ef84fea6e7abcb6620ef8bfc112fae ] An earlier commit moved out some functions to not be inlined by gcc, but after some other rework to remove one of those, clang started inlining the other one and ran into the same problem as gcc did before: fs/ubifs/replay.c:1174:5: error: stack frame size of 1152 bytes in function 'ubifs_replay_journal' [-Werror,-Wframe-larger-than=] Mark the function as noinline_for_stack to ensure it doesn't happen again. Fixes: f80df3851246 ("ubifs: use crypto_shash_tfm_digest()") Fixes: eb66eff6636d ("ubifs: replay: Fix high stack usage") Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 140d1eaa3e03abbd16b6fb7aea8ff5d973a6d3e9 Author: Dinghao Liu Date: Tue Jan 5 14:03:40 2021 +0800 ubifs: Fix memleak in ubifs_init_authentication [ Upstream commit 11b8ab3836454a2600e396f34731e491b661f9d5 ] When crypto_shash_digestsize() fails, c->hmac_tfm has not been freed before returning, which leads to memleak. Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support") Signed-off-by: Dinghao Liu Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit b034433208e3070e1fd2b8691af91292aeba9753 Author: Tom Rix Date: Wed Dec 30 06:56:04 2020 -0800 jffs2: fix use after free in jffs2_sum_write_data() [ Upstream commit 19646447ad3a680d2ab08c097585b7d96a66126b ] clang static analysis reports this problem fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed c->summary->sum_list_head = temp->u.next; ^~~~~~~~~~~~ In jffs2_sum_write_data(), in a loop summary data is handles a node at a time. When it has written out the node it is removed the summary list, and the node is deleted. In the corner case when a JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to jffs2_sum_disable_collecting(). jffs2_sum_disable_collecting() deletes the whole list which conflicts with the loop's deleting the list by parts. To preserve the old behavior of stopping the write midway, bail out of the loop after disabling summary collection. Fixes: 6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.") Signed-off-by: Tom Rix Reviewed-by: Nathan Chancellor Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 86d89a12dc7dd742c864726d3769d06d9f574996 Author: Colin Ian King Date: Thu Feb 11 13:01:08 2021 +0000 fs/jfs: fix potential integer overflow on shift of a int [ Upstream commit 4208c398aae4c2290864ba15c3dab7111f32bec1 ] The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where l2nb is 32 or more this can lead to an overflow. Avoid this by shifting the value 1LL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: b40c2e665cd5 ("fs/jfs: TRIM support for JFS Filesystem") Signed-off-by: Colin Ian King Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 54e5c1af224448a4b435bd0ff6bbba88f581468d Author: Sameer Pujar Date: Wed Feb 10 12:13:39 2021 +0530 ASoC: simple-card-utils: Fix device module clock [ Upstream commit 1e30f642cf2939bbdac82ea0dd3071232670b5ab ] If "clocks = <&xxx>" is specified from the CPU or Codec component device node, the clock is not getting enabled. Thus audio playback or capture fails. Fix this by populating "simple_dai->clk" field when clocks property is specified from device node as well. Also tidy up by re-organising conditional statements of parsing logic. Fixes: bb6fc620c2ed ("ASoC: simple-card-utils: add asoc_simple_card_parse_clk()") Cc: Kuninori Morimoto Signed-off-by: Sameer Pujar Link: https://lore.kernel.org/r/1612939421-19900-2-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d9ed69f5bf9599eee7ceec1d8a1f681b9f55eba Author: Lakshmi Ramasubramanian Date: Thu Feb 4 09:49:51 2021 -0800 ima: Free IMA measurement buffer after kexec syscall [ Upstream commit f31e3386a4e92ba6eda7328cb508462956c94c64 ] IMA allocates kernel virtual memory to carry forward the measurement list, from the current kernel to the next kernel on kexec system call, in ima_add_kexec_buffer() function. This buffer is not freed before completing the kexec system call resulting in memory leak. Add ima_buffer field in "struct kimage" to store the virtual address of the buffer allocated for the IMA measurement list. Free the memory allocated for the IMA measurement list in kimage_file_post_load_cleanup() function. Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Tyler Hicks Reviewed-by: Thiago Jung Bauermann Reviewed-by: Tyler Hicks Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list") Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 8783dbf0ad0d6f39b0de025935d5774f47c06aeb Author: Lakshmi Ramasubramanian Date: Thu Feb 4 09:49:50 2021 -0800 ima: Free IMA measurement buffer on error [ Upstream commit 6d14c6517885fa68524238787420511b87d671df ] IMA allocates kernel virtual memory to carry forward the measurement list, from the current kernel to the next kernel on kexec system call, in ima_add_kexec_buffer() function. In error code paths this memory is not freed resulting in memory leak. Free the memory allocated for the IMA measurement list in the error code paths in ima_add_kexec_buffer() function. Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Tyler Hicks Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list") Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 8e8660d5be88f6990e418915db0c186527250c8c Author: Pierre-Louis Bossart Date: Mon Feb 8 17:18:53 2021 -0600 ASoC: SOF: sof-pci-dev: add missing Up-Extreme quirk [ Upstream commit bd8036eb15263a720b8f846861c180b27d050a09 ] The UpExtreme board supports the community key and was missed in previous contributions. Add it to make sure the open firmware is picked by default without needing a symlink on the target. Fixes: 46207ca24545 ('ASoC: SOF: pci: change the default firmware path when the community key is used') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20210208231853.58761-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5c37f86b1c7510d7524f001ac0096b8f6b7ac7e9 Author: Chaitanya Kulkarni Date: Tue Feb 9 21:47:52 2021 -0800 nvmet: set status to 0 in case for invalid nsid [ Upstream commit 40244ad36bcfb796a6bb9e95bdcbf8ddf3134509 ] For unallocated namespace in nvmet_execute_identify_ns() don't set the status to NVME_SC_INVALID_NS, set it to zero. Fixes: bffcd507780e ("nvmet: set right status on error in id-ns handler") Signed-off-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b3ed699ccee2d0a5b1c2eebd1bea25156ca62fbb Author: Chaitanya Kulkarni Date: Wed Jan 13 17:33:54 2021 -0800 nvmet: remove extra variable in identify ns [ Upstream commit 3c7b224f1956ed232b24ed2eb2c54e4476c6acb2 ] We remove the extra local variable struct nvmet_ns in nvmet_execute_identify_ns() since req already has ns member that can be reused, this also eliminates the explicit call to nvmet_put_namespace() which is already present in the request completion path. Signed-off-by: Chaitanya Kulkarni Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d160a1c3ad6896ca5dee466a13b2c36af0994c40 Author: Keith Busch Date: Fri Feb 5 11:50:02 2021 -0800 nvme-multipath: set nr_zones for zoned namespaces [ Upstream commit 73a1a2298f3e9df24cea7a9aab412ba9470f6159 ] The bio based drivers only require the request_queue's nr_zones is set, so set this field in the head if the namespace path is zoned. Fixes: 240e6ee272c07 ("nvme: support for zoned namespaces") Reported-by: Minwoo Im Cc: Damien Le Moal Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 6d6898e9be787a65ef6fbebd8e67b2aea4774bb9 Author: Sagi Grimberg Date: Fri Feb 5 11:47:25 2021 -0800 nvmet-tcp: fix potential race of tcp socket closing accept_work [ Upstream commit 0fbcfb089a3f2f2a731d01f0aec8f7697a849c28 ] When we accept a TCP connection and allocate an nvmet-tcp queue we should make sure not to fully establish it or reference it as the connection may be already closing, which triggers queue release work, which does not fence against queue establishment. In order to address such a race, we make sure to check the sk_state and contain the queue reference to be done underneath the sk_callback_lock such that the queue release work correctly fences against it. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Reported-by: Elad Grupi Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4b17476d809273617d3317fa0d4ae78aa488d760 Author: Sagi Grimberg Date: Wed Feb 3 15:00:01 2021 -0800 nvmet-tcp: fix receive data digest calculation for multiple h2cdata PDUs [ Upstream commit fda871c0ba5d2eed2cd1c881573168129da70058 ] When a host sends multiple h2cdata PDUs for a single command, we should verify the data digest calculation per PDU and not per command. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Reported-by: Narayan Ayalasomayajula Tested-by: Narayan Ayalasomayajula Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 08324a2711ec4a7c4f89a4f8d1eb2b81625261ee Author: Hao Xu Date: Fri Feb 5 16:34:21 2021 +0800 io_uring: fix possible deadlock in io_uring_poll [ Upstream commit ed670c3f90a67d9e16ab6d8893be6f072d79cd4c ] Abaci reported follow issue: [ 30.615891] ====================================================== [ 30.616648] WARNING: possible circular locking dependency detected [ 30.617423] 5.11.0-rc3-next-20210115 #1 Not tainted [ 30.618035] ------------------------------------------------------ [ 30.618914] a.out/1128 is trying to acquire lock: [ 30.619520] ffff88810b063868 (&ep->mtx){+.+.}-{3:3}, at: __ep_eventpoll_poll+0x9f/0x220 [ 30.620505] [ 30.620505] but task is already holding lock: [ 30.621218] ffff88810e952be8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_enter+0x3f0/0x5b0 [ 30.622349] [ 30.622349] which lock already depends on the new lock. [ 30.622349] [ 30.623289] [ 30.623289] the existing dependency chain (in reverse order) is: [ 30.624243] [ 30.624243] -> #1 (&ctx->uring_lock){+.+.}-{3:3}: [ 30.625263] lock_acquire+0x2c7/0x390 [ 30.625868] __mutex_lock+0xae/0x9f0 [ 30.626451] io_cqring_overflow_flush.part.95+0x6d/0x70 [ 30.627278] io_uring_poll+0xcb/0xd0 [ 30.627890] ep_item_poll.isra.14+0x4e/0x90 [ 30.628531] do_epoll_ctl+0xb7e/0x1120 [ 30.629122] __x64_sys_epoll_ctl+0x70/0xb0 [ 30.629770] do_syscall_64+0x2d/0x40 [ 30.630332] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 30.631187] [ 30.631187] -> #0 (&ep->mtx){+.+.}-{3:3}: [ 30.631985] check_prevs_add+0x226/0xb00 [ 30.632584] __lock_acquire+0x1237/0x13a0 [ 30.633207] lock_acquire+0x2c7/0x390 [ 30.633740] __mutex_lock+0xae/0x9f0 [ 30.634258] __ep_eventpoll_poll+0x9f/0x220 [ 30.634879] __io_arm_poll_handler+0xbf/0x220 [ 30.635462] io_issue_sqe+0xa6b/0x13e0 [ 30.635982] __io_queue_sqe+0x10b/0x550 [ 30.636648] io_queue_sqe+0x235/0x470 [ 30.637281] io_submit_sqes+0xcce/0xf10 [ 30.637839] __x64_sys_io_uring_enter+0x3fb/0x5b0 [ 30.638465] do_syscall_64+0x2d/0x40 [ 30.638999] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 30.639643] [ 30.639643] other info that might help us debug this: [ 30.639643] [ 30.640618] Possible unsafe locking scenario: [ 30.640618] [ 30.641402] CPU0 CPU1 [ 30.641938] ---- ---- [ 30.642664] lock(&ctx->uring_lock); [ 30.643425] lock(&ep->mtx); [ 30.644498] lock(&ctx->uring_lock); [ 30.645668] lock(&ep->mtx); [ 30.646321] [ 30.646321] *** DEADLOCK *** [ 30.646321] [ 30.647642] 1 lock held by a.out/1128: [ 30.648424] #0: ffff88810e952be8 (&ctx->uring_lock){+.+.}-{3:3}, at: __x64_sys_io_uring_enter+0x3f0/0x5b0 [ 30.649954] [ 30.649954] stack backtrace: [ 30.650592] CPU: 1 PID: 1128 Comm: a.out Not tainted 5.11.0-rc3-next-20210115 #1 [ 30.651554] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 30.652290] Call Trace: [ 30.652688] dump_stack+0xac/0xe3 [ 30.653164] check_noncircular+0x11e/0x130 [ 30.653747] ? check_prevs_add+0x226/0xb00 [ 30.654303] check_prevs_add+0x226/0xb00 [ 30.654845] ? add_lock_to_list.constprop.49+0xac/0x1d0 [ 30.655564] __lock_acquire+0x1237/0x13a0 [ 30.656262] lock_acquire+0x2c7/0x390 [ 30.656788] ? __ep_eventpoll_poll+0x9f/0x220 [ 30.657379] ? __io_queue_proc.isra.88+0x180/0x180 [ 30.658014] __mutex_lock+0xae/0x9f0 [ 30.658524] ? __ep_eventpoll_poll+0x9f/0x220 [ 30.659112] ? mark_held_locks+0x5a/0x80 [ 30.659648] ? __ep_eventpoll_poll+0x9f/0x220 [ 30.660229] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 30.660885] ? trace_hardirqs_on+0x46/0x110 [ 30.661471] ? __io_queue_proc.isra.88+0x180/0x180 [ 30.662102] ? __ep_eventpoll_poll+0x9f/0x220 [ 30.662696] __ep_eventpoll_poll+0x9f/0x220 [ 30.663273] ? __ep_eventpoll_poll+0x220/0x220 [ 30.663875] __io_arm_poll_handler+0xbf/0x220 [ 30.664463] io_issue_sqe+0xa6b/0x13e0 [ 30.664984] ? __lock_acquire+0x782/0x13a0 [ 30.665544] ? __io_queue_proc.isra.88+0x180/0x180 [ 30.666170] ? __io_queue_sqe+0x10b/0x550 [ 30.666725] __io_queue_sqe+0x10b/0x550 [ 30.667252] ? __fget_files+0x131/0x260 [ 30.667791] ? io_req_prep+0xd8/0x1090 [ 30.668316] ? io_queue_sqe+0x235/0x470 [ 30.668868] io_queue_sqe+0x235/0x470 [ 30.669398] io_submit_sqes+0xcce/0xf10 [ 30.669931] ? xa_load+0xe4/0x1c0 [ 30.670425] __x64_sys_io_uring_enter+0x3fb/0x5b0 [ 30.671051] ? lockdep_hardirqs_on_prepare+0xde/0x180 [ 30.671719] ? syscall_enter_from_user_mode+0x2b/0x80 [ 30.672380] do_syscall_64+0x2d/0x40 [ 30.672901] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 30.673503] RIP: 0033:0x7fd89c813239 [ 30.673962] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 ec 2c 00 f7 d8 64 89 01 48 [ 30.675920] RSP: 002b:00007ffc65a7c628 EFLAGS: 00000217 ORIG_RAX: 00000000000001aa [ 30.676791] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd89c813239 [ 30.677594] RDX: 0000000000000000 RSI: 0000000000000014 RDI: 0000000000000003 [ 30.678678] RBP: 00007ffc65a7c720 R08: 0000000000000000 R09: 0000000003000000 [ 30.679492] R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000400ff0 [ 30.680282] R13: 00007ffc65a7c840 R14: 0000000000000000 R15: 0000000000000000 This might happen if we do epoll_wait on a uring fd while reading/writing the former epoll fd in a sqe in the former uring instance. So let's don't flush cqring overflow list, just do a simple check. Reported-by: Abaci Fixes: 6c503150ae33 ("io_uring: patch up IOPOLL overflow_flush sync") Signed-off-by: Hao Xu Reviewed-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8164e9000ea760df8db8c33a4b055465de425406 Author: Daniele Alessandrelli Date: Wed Feb 3 11:28:37 2021 +0000 crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key() [ Upstream commit a53ab94eb6850c3657392e2d2ce9b38c387a2633 ] The length ('len' parameter) passed to crypto_ecdh_decode_key() is never checked against the length encoded in the passed buffer ('buf' parameter). This could lead to an out-of-bounds access when the passed length is less than the encoded length. Add a check to prevent that. Fixes: 3c4b23901a0c7 ("crypto: ecdh - Add ECDH software support") Signed-off-by: Daniele Alessandrelli Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7e04afabec1c1381a3c69da3e26d883921f1e8dc Author: Jan Henrik Weinstock Date: Mon Feb 1 16:14:59 2021 +0100 hwrng: timeriomem - Fix cooldown period calculation [ Upstream commit e145f5565dc48ccaf4cb50b7cfc48777bed8c100 ] Ensure cooldown period tolerance of 1% is actually accounted for. Fixes: ca3bff70ab32 ("hwrng: timeriomem - Improve performance...") Signed-off-by: Jan Henrik Weinstock Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6cfa1849aa119aabb9fc99e267bd41dbbf5b8e48 Author: Imre Deak Date: Mon Feb 1 14:01:43 2021 +0200 drm/dp_mst: Don't cache EDIDs for physical ports [ Upstream commit 4b8878eefa0a3b65e2e016db49014ea66fb9fd45 ] Caching EDIDs for physical ports prevents updating the EDID if a port gets reconnected via a Connection Status Notification message, fix this. Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case") Cc: Wayne Lin Cc: Lyude Paul Signed-off-by: Imre Deak Reviewed-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210201120145.350258-2-imre.deak@intel.com (cherry picked from commit 468091531c2e5c49f55d8c6f1d036ce997d24e13) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit af26e888e6116d9796a9e190502f774822713c9e Author: Dan Carpenter Date: Wed Feb 3 12:54:24 2021 +0300 drm/virtio: fix an error code in virtio_gpu_init() [ Upstream commit 8d0cb8860a4551fa5998acd67ca6d9ce3015b1e2 ] If devm_request_mem_region() fails this code currently returns success but it should return -EBUSY. Fixes: 6076a9711dc5 ("drm/virtio: implement blob resources: probe for host visible region") Signed-off-by: Dan Carpenter Link: http://patchwork.freedesktop.org/patch/msgid/YBpy0GS7GfmafMfe@mwanda Signed-off-by: Gerd Hoffmann (cherry picked from commit eb988a2ee500d3297a1de048dc3c77b6c354e650) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit a968ef1017bd6dcac3b87c414d88ec3b23dc59d2 Author: Qinglang Miao Date: Fri Nov 27 17:44:38 2020 +0800 drm/lima: fix reference leak in lima_pm_busy [ Upstream commit de4248b744e8394f239c0dd0af34088399d27d94 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in a reference leak here. A new function pm_runtime_resume_and_get is introduced in [0] to keep usage counter balanced. So We fix the reference leak by replacing it with new function. [0] commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Fixes: 50de2e9ebbc0 ("drm/lima: enable runtime pm") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Qiang Yu Link: https://patchwork.freedesktop.org/patch/msgid/20201127094438.121003-1-miaoqinglang@huawei.com (cherry picked from commit de499781c97d96703af8a32d2b5e37fdb5b51568) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit cc66a93f1a2630b15233c0cfae3fa96a08030e84 Author: Maxime Ripard Date: Mon Jan 11 15:23:01 2021 +0100 drm/vc4: hdmi: Update the CEC clock divider on HSM rate change [ Upstream commit 47fa9a80270e20a0c4ddaffca1f144d22cc59620 ] As part of the enable sequence we might change the HSM clock rate if the pixel rate is different than the one we were already dealing with. On the BCM2835 however, the CEC clock derives from the HSM clock so any rate change will need to be reflected in the CEC clock divider to output 40kHz. Fixes: cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate") Reviewed-by: Dave Stevenson Signed-off-by: Maxime Ripard Acked-by: Hans Verkuil Tested-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-8-maxime@cerno.tech (cherry picked from commit a9dd0b9a5c3e11c79e6ff9c7fdf07c471732dcb6) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit d1ce2dc3f5c26d629044e7f40119d28e796a709e Author: Maxime Ripard Date: Mon Jan 11 15:23:00 2021 +0100 drm/vc4: hdmi: Compute the CEC clock divider from the clock rate [ Upstream commit 163a3ef681e5e9d5df558e855d86ccd4708d6200 ] The CEC clock divider needs to output a frequency of 40kHz from the HSM rate on the BCM2835. The driver used to have a fixed frequency for it, but that changed for the BCM2711 and we now need to compute it dynamically to maintain the proper rate. Fixes: cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate") Reviewed-by: Dave Stevenson Signed-off-by: Maxime Ripard Acked-by: Hans Verkuil Tested-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-7-maxime@cerno.tech (cherry picked from commit f1ceb9d10043683b89e5e5e5848fb4e855295762) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 7b13c09fc4dc3628b518324e56c192925a507865 Author: Dom Cobley Date: Mon Jan 11 15:22:59 2021 +0100 drm/vc4: hdmi: Restore cec physical address on reconnect [ Upstream commit 4d8602b8ec16f5721a4d1339c610a81f95df1856 ] Currently we call cec_phys_addr_invalidate on a hotplug deassert. That may be due to a TV power cycling, or an AVR being switched on (and switching edid). This makes CEC unusable since our controller wouldn't have a physical address anymore. Set it back up again on the hotplug assert. Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Acked-by: Dave Stevenson Acked-by: Hans Verkuil Tested-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-6-maxime@cerno.tech (cherry picked from commit b06eecb5158e5f3eb47b9d05aea8c259985cc5f7) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 59670152ea92224e10c386a16300d6d81da4174e Author: Dom Cobley Date: Mon Jan 11 15:22:58 2021 +0100 drm/vc4: hdmi: Fix up CEC registers [ Upstream commit 5a32bfd563e8b5766e57475c2c81c769e5a13f5d ] The commit 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction") forgot one CEC register, and made a copy and paste mistake for another one. Fix those mistakes. Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction") Reviewed-by: Dave Stevenson Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Acked-by: Hans Verkuil Tested-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-5-maxime@cerno.tech (cherry picked from commit 303085bc11bb7aebeeaaf09213f99fd7aa539a34) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 27e603fceba3bafcb3fd4850da634b2f1e3f43f1 Author: Dom Cobley Date: Mon Jan 11 15:22:57 2021 +0100 drm/vc4: hdmi: Fix register offset with longer CEC messages [ Upstream commit 4a59ed546c0511f01a4bf6b886fe34b6cce2513f ] The code prior to 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction") was relying on the fact that the register offset was incremented by 4 for each readl call. That worked since the register width is 4 bytes. However, since that commit the HDMI_READ macro is now taking an enum, and the offset doesn't increment by 4 but 1 now. Divide the index by 4 to fix this. Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction") Reviewed-by: Dave Stevenson Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Acked-by: Hans Verkuil Tested-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-4-maxime@cerno.tech (cherry picked from commit e9c9481f373eb7344f9e973eb28fc6e9d0f46485) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit fdf705a5178a71071ed972538e8ad2698316adcb Author: Dom Cobley Date: Mon Jan 11 15:22:56 2021 +0100 drm/vc4: hdmi: Move hdmi reset to bind [ Upstream commit 902dc5c19a8fecd3113dd41cc601b34557bdede9 ] The hdmi reset got moved to a later point in the commit 9045e91a476b ("drm/vc4: hdmi: Add reset callback"). However, the reset now occurs after vc4_hdmi_cec_init and so tramples the setup of registers like HDMI_CEC_CNTRL_1 This only affects pi0-3 as on pi4 the cec registers are in a separate block Fixes: 9045e91a476b ("drm/vc4: hdmi: Add reset callback") Reviewed-by: Dave Stevenson Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Acked-by: Hans Verkuil Tested-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-3-maxime@cerno.tech (cherry picked from commit 7155334f15f360f5c98391c5c7e12af4c13395c4) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 7a7da3a452bb31241c880f7a86caf2781a18ccb0 Author: Harald Freudenberger Date: Thu Jan 21 16:03:08 2021 +0100 s390/zcrypt: return EIO when msg retry limit reached [ Upstream commit d39fae45c97c67b1b4da04773f2bb5a2f29088c4 ] When a msg is retried because the lower ap layer returns -EAGAIN there is a retry limit (currently 10). When this limit is reached the last return code from the lower layer is returned, causing the userspace to get -1 on the ioctl with errno EAGAIN. This EAGAIN is misleading here. After 10 retry attempts the userspace should receive a clear failure indication like EINVAL or EIO or ENODEV. However, the reason why these retries all fail is unclear. On an invalid message EINVAL would be returned by the lower layer, and if devices go away or are not available an ENODEV is seen. So this patch now reworks the retry loops to return EIO to userspace when the retry limit is reached. Fixes: 91ffc519c199 ("s390/zcrypt: introduce msg tracking in zcrypt functions") Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 8713d08dd17cd778931596c65112cb6209a73f94 Author: Sean Christopherson Date: Thu Feb 4 17:24:58 2021 -0800 KVM: x86: Restore all 64 bits of DR6 and DR7 during RSM on x86-64 [ Upstream commit 2644312052d54e2e7543c7d186899a36ed22f0bf ] Restore the full 64-bit values of DR6 and DR7 when emulating RSM on x86-64, as defined by both Intel's SDM and AMD's APM. Note, bits 63:32 of DR6 and DR7 are reserved, so this is a glorified nop unless the SMM handler is poking into SMRAM, which it most definitely shouldn't be doing since both Intel and AMD list the DR6 and DR7 fields as read-only. Fixes: 660a5d517aaa ("KVM: x86: save/load state on SMM switch") Signed-off-by: Sean Christopherson Message-Id: <20210205012458.3872687-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit cd123dfb900c814522a1dc89bd0bd699c9dc821f Author: Jinyang He Date: Fri Feb 5 18:11:21 2021 +0800 MIPS: relocatable: Provide kaslr_offset() to get the kernel offset [ Upstream commit d4d3ef8b347b73aa60f60f4be06acf1643e79f34 ] Provide kaslr_offset() to get the kernel offset when KASLR is enabled. Error may occur before update_kaslr_offset(), so put it at the end of the offset branch. Fixes: a307a4ce9ecd ("MIPS: Loongson64: Add KASLR support") Reported-by: kernel test robot Signed-off-by: Jinyang He Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ba8158ea1d4445903b48cdad93bde4ba134f2875 Author: Qu Wenruo Date: Wed Jan 27 14:38:48 2021 +0800 btrfs: fix double accounting of ordered extent for subpage case in btrfs_invalidapge [ Upstream commit 951c80f83d61bd4b21794c8aba829c3c1a45c2d0 ] Commit dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could span across a page") make btrfs_invalidapage() to search all ordered extents. The offending code looks like this: again: start = page_start; ordered = btrfs_lookup_ordered_range(inode, start, page_end - start + 1); if (ordred) { end = min(page_end, ordered->file_offset + ordered->num_bytes - 1); /* Do the cleanup */ start = end + 1; if (start < page_end) goto again; } The behavior is indeed necessary for the incoming subpage support, but when it iterates through all the ordered extents, it also resets the search range @start. This means, for the following cases, we can double account the ordered extents, causing its bytes_left underflow: Page offset 0 16K 32K |<--- OE 1 --->|<--- OE 2 ---->| As the first iteration will find ordered extent (OE) 1, which doesn't cover the full page, thus after cleanup code, we need to retry again. But again label will reset start to page_start, and we got OE 1 again, which causes double accounting on OE 1, and cause OE 1's byte_left to underflow. This problem can only happen for subpage case, as for regular sectorsize == PAGE_SIZE case, we will always find a OE ends at or after page end, thus no way to trigger the problem. Move the again label after start = page_start. There will be more comprehensive rework to convert the open coded loop to a proper while loop for subpage support. Fixes: dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could span across a page") Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5001c81ac62106b39bd4e0645d80e6a3a61eeb14 Author: Zhihao Cheng Date: Fri Nov 20 09:08:04 2020 +0800 btrfs: clarify error returns values in __load_free_space_cache [ Upstream commit 3cc64e7ebfb0d7faaba2438334c43466955a96e8 ] Return value in __load_free_space_cache is not properly set after (unlikely) memory allocation failures and 0 is returned instead. This is not a problem for the caller load_free_space_cache because only value 1 is considered as 'cache loaded' but for clarity it's better to set the errors accordingly. Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1bc8582dc538b0f0e7f1d0c7929c76b2e665cd88 Author: Hui Wang Date: Mon Feb 8 18:38:57 2021 +0800 ASoC: SOF: debug: Fix a potential issue on string buffer termination [ Upstream commit 9037c3bde65d339017ef41d81cb58069ffc321d4 ] The function simple_write_to_buffer() doesn't add string termination at the end of buf, we need to handle it on our own. This change refers to the function tokenize_input() in debug.c and the function sof_dfsentry_trace_filter_write() in trace.c. Fixes: 091c12e1f50c ("ASoC: SOF: debug: add new debugfs entries for IPC flood test") Reviewed-by: Kai Vehmanen Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210208103857.75705-1-hui.wang@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 956796dd50deb04a9d92277e5ee60d21dcf85ad8 Author: Sathyanarayana Nujella Date: Fri Feb 5 09:14:28 2021 -0800 ASoC: rt5682: Fix panic in rt5682_jack_detect_handler happening during system shutdown [ Upstream commit 45a2702ce10993eda7a5b12690294782d565519c ] During Coldboot stress tests, system encountered the following panic. Panic logs depicts rt5682_i2c_shutdown() happened first and then later jack detect handler workqueue function triggered. This situation causes panic as rt5682_i2c_shutdown() resets codec. Fix this panic by cancelling all jack detection delayed work. Panic log: [ 20.936124] sof_pci_shutdown [ 20.940248] snd_sof_device_shutdown [ 20.945023] snd_sof_shutdown [ 21.126849] rt5682_i2c_shutdown [ 21.286053] rt5682_jack_detect_handler [ 21.291235] BUG: kernel NULL pointer dereference, address: 000000000000037c [ 21.299302] #PF: supervisor read access in kernel mode [ 21.305254] #PF: error_code(0x0000) - not-present page [ 21.311218] PGD 0 P4D 0 [ 21.314155] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 21.319206] CPU: 2 PID: 123 Comm: kworker/2:3 Tainted: G U 5.4.68 #10 [ 21.333687] ACPI: Preparing to enter system sleep state S5 [ 21.337669] Workqueue: events_power_efficient rt5682_jack_detect_handler [snd_soc_rt5682] [ 21.337671] RIP: 0010:rt5682_jack_detect_handler+0x6c/0x279 [snd_soc_rt5682] Fixes: a50067d4f3c1d ('ASoC: rt5682: split i2c driver into separate module') Signed-off-by: Jairaj Arava Signed-off-by: Sathyanarayana Nujella Reviewed-by: Pierre-Louis Bossart Reviewed-by: Shuming Fan Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20210205171428.2344210-1-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d963d7e8be8e6115e342010cc42a40b9b1f14b6a Author: Jun Nie Date: Mon Feb 1 21:29:41 2021 +0800 ASoC: qcom: lpass: Fix i2s ctl register bit map [ Upstream commit 5e3277ab3baff6db96ae44adf6f85d6f0f6502cc ] Fix bitwidth mapping in i2s ctl register per APQ8016 document. Fixes: b5022a36d28f ("ASoC: qcom: lpass: Use regmap_field for i2sctl and dmactl registers") Reviewed-by: Srinivas Kandagatla Reviewed-by: Stephan Gerhold Signed-off-by: Jun Nie Link: https://lore.kernel.org/r/20210201132941.460360-1-jun.nie@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3cea264b50d8d3abaa526307bc3316fe8965cf4d Author: Peter Zijlstra Date: Mon Feb 1 11:55:38 2021 +0100 locking/lockdep: Avoid unmatched unlock [ Upstream commit 7f82e631d236cafd28518b998c6d4d8dc2ef68f6 ] Commit f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI" inversions") overlooked that print_usage_bug() releases the graph_lock and called it without the graph lock held. Fixes: f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI" inversions") Reported-by: Dmitry Vyukov Signed-off-by: Peter Zijlstra (Intel) Acked-by: Waiman Long Link: https://lkml.kernel.org/r/YBfkuyIfB1+VRxXP@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 802c496ad6236e2553d4687fdd8295bebaabf38f Author: Pierre-Louis Bossart Date: Thu Feb 4 14:32:59 2021 -0600 ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A3E [ Upstream commit 5ab3ff4d66960be766a544886667e7c002f17fd6 ] We missed adding the TGL_HDMI quirk which is very much needed to expose the 4 display pipelines and will be required on TGL topologies. Fixes: e787f5b5b1406 ('ASoC: Intel: add support for new SoundWire hardware layout on TGL') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210204203312.27112-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6fadf213945c97019ffbe1f7659a670d052350d0 Author: Pierre-Louis Bossart Date: Thu Feb 4 14:33:01 2021 -0600 ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A32 [ Upstream commit 45c92ec32b43c6cb42341ebf07577eefed9d87ec ] We missed adding the TGL_HDMI quirk which is very much needed to expose the 4 display pipelines and will be required on TGL topologies. Fixes: 488cdbd8931fe ('ASoC: Intel: sof_sdw: add quirk for new TigerLake-SDCA device') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210204203312.27112-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit af81d7a217db3b9c041eec38e91c7986bd14333e Author: Pierre-Louis Bossart Date: Thu Feb 4 14:33:00 2021 -0600 ASoC: Intel: sof_sdw: add missing TGL_HDMI quirk for Dell SKU 0A5E [ Upstream commit f12bbc50f3b14c9b8ed902c6d1da980dd5addcce ] We missed adding the TGL_HDMI quirk which is very much needed to expose the 4 display pipelines and will be required on TGL topologies. Fixes: 9ad9bc59dde10 ('ASoC: Intel: sof_sdw: set proper flags for Dell TGL-H SKU 0A5E') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210204203312.27112-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd96c68b5b1701b10a15b19ff8ba0427f28f44a5 Author: Andrea Parri (Microsoft) Date: Wed Dec 9 08:08:25 2020 +0100 Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind() [ Upstream commit e3fa4b747f085d2cda09bba0533b86fa76038635 ] When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could invoke put_device(), that will eventually release the device and free the channel object (cf. vmbus_device_release()). However, a pointer to the object is dereferenced again later to load the primary_channel. The use-after-free can be avoided by noticing that this load/check is redundant if device_obj is non-NULL: primary_channel must be NULL if device_obj is non-NULL, cf. vmbus_add_channel_work(). Fixes: 54a66265d6754b ("Drivers: hv: vmbus: Fix rescind handling") Reported-by: Juan Vazquez Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20201209070827.29335-5-parri.andrea@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 45acd6e2eccf5f6ac63a39741e4b3f7bda47c56e Author: Yongqiang Niu Date: Mon Jan 11 15:43:44 2021 +0800 drm/mediatek: Check if fb is null [ Upstream commit b1d685b6467ac0d98fc63989f71b4ca9186be5d4 ] It's possible that state->base.fb is null. Add a check before access its format. Fixes: b6b1bb980ec4 ("drm/mediatek: Turn off Alpha bit when plane format has no alpha") Signed-off-by: Yongqiang Niu Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 4b6d5a571b30b0e5305d8aed8bdd21d2609fb170 Author: Sean Christopherson Date: Wed Feb 3 16:01:07 2021 -0800 KVM: nSVM: Don't strip host's C-bit from guest's CR3 when reading PDPTRs [ Upstream commit 2732be90235347a3be4babdc9f88a1ea93970b0b ] Don't clear the SME C-bit when reading a guest PDPTR, as the GPA (CR3) is in the guest domain. Barring a bizarre paravirtual use case, this is likely a benign bug. SME is not emulated by KVM, loading SEV guest PDPTRs is doomed as KVM can't use the correct key to read guest memory, and setting guest MAXPHYADDR higher than the host, i.e. overlapping the C-bit, would cause faults in the guest. Note, for SEV guests, stripping the C-bit is technically aligned with CPU behavior, but for KVM it's the greater of two evils. Because KVM doesn't have access to the guest's encryption key, ignoring the C-bit would at best result in KVM reading garbage. By keeping the C-bit, KVM will fail its read (unless userspace creates a memslot with the C-bit set). The guest will still undoubtedly die, as KVM will use '0' for the PDPTR value, but that's preferable to interpreting encrypted data as a PDPTR. Fixes: d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM") Cc: Tom Lendacky Cc: Brijesh Singh Signed-off-by: Sean Christopherson Message-Id: <20210204000117.3303214-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f38eaa38977bae1ab679806f17cab7629ff62356 Author: Srinivasa Rao Mandadapu Date: Tue Feb 2 11:57:27 2021 +0530 ASoC: qcom: Fix typo error in HDMI regmap config callbacks [ Upstream commit e681b1a6d706b4e54c3847bb822531b4660234f3 ] Had a typo in lpass platform driver that resulted in crash during suspend/resume with an HDMI dongle connected. The regmap read/write/volatile regesters validation callbacks in lpass-cpu were using MI2S rdma_channels count instead of hdmi_rdma_channels. This typo error causing to read registers from the regmap beyond the length of the mapping created by ioremap(). This fix avoids the need for reducing number hdmi_rdma_channels, which is done in commit 7dfe20ee92f6 ("ASoC: qcom: Fix number of HDMI RDMA channels on sc7180"). So reverting the same. Fixes: 7cb37b7bd0d3c ("ASoC: qcom: Add support for lpass hdmi driver") Signed-off-by: Srinivasa Rao Mandadapu Link: https://lore.kernel.org/r/20210202062727.22469-1-srivasam@codeaurora.org Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6fefe6cb6aa5a751fdb899aa5a27e7a83b06dc8b Author: Dehe Gu Date: Tue Feb 2 17:39:22 2021 +0800 f2fs: fix a wrong condition in __submit_bio [ Upstream commit 39f71b7e40e21805d6b15fc7750bdd9cab6a5010 ] We should use !F2FS_IO_ALIGNED() to check and submit_io directly. Fixes: 8223ecc456d0 ("f2fs: fix to add missing F2FS_IO_ALIGNED() condition") Reviewed-by: Chao Yu Signed-off-by: Dehe Gu Signed-off-by: Ge Qiu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 43b1862ce716d3869ebd8e70fea3279a296d2bfc Author: Dan Carpenter Date: Tue Feb 2 08:56:36 2021 +0300 drm/amdgpu: Prevent shift wrapping in amdgpu_read_mask() [ Upstream commit c915ef890d5dc79f483e1ca3b3a5b5f1a170690c ] If the user passes a "level" value which is higher than 31 then that leads to shift wrapping. The undefined behavior will lead to a syzkaller stack dump. Fixes: 5632708f4452 ("drm/amd/powerplay: add dpm force multiple levels on cz/tonga/fiji/polaris (v2)") Signed-off-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dadac6ab640678be53bb197cd144586edbe9db3b Author: Yi Chen Date: Thu Jan 28 17:02:56 2021 +0800 f2fs: fix to avoid inconsistent quota data [ Upstream commit 25fb04dbce6a0e165d28fd1fa8a1d7018c637fe8 ] Occasionally, quota data may be corrupted detected by fsck: Info: checkpoint state = 45 : crc compacted_summary unmount [QUOTA WARNING] Usage inconsistent for ID 0:actual (1543036928, 762) != expected (1543032832, 762) [ASSERT] (fsck_chk_quota_files:1986) --> Quota file is missing or invalid quota file content found. [QUOTA WARNING] Usage inconsistent for ID 0:actual (1352478720, 344) != expected (1352474624, 344) [ASSERT] (fsck_chk_quota_files:1986) --> Quota file is missing or invalid quota file content found. [FSCK] Unreachable nat entries [Ok..] [0x0] [FSCK] SIT valid block bitmap checking [Ok..] [FSCK] Hard link checking for regular file [Ok..] [0x0] [FSCK] valid_block_count matching with CP [Ok..] [0xdf299] [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x2b01] [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x2b01] [FSCK] valid_inode_count matched with CP [Ok..] [0x2665] [FSCK] free segment_count matched with CP [Ok..] [0xcb04] [FSCK] next block offset is free [Ok..] [FSCK] fixing SIT types [FSCK] other corrupted bugs [Fail] The root cause is: If we open file w/ readonly flag, disk quota info won't be initialized for this file, however, following mmap() will force to convert inline inode via f2fs_convert_inline_inode(), which may increase block usage for this inode w/o updating quota data, it causes inconsistent disk quota info. The issue will happen in following stack: open(file, O_RDONLY) mmap(file) - f2fs_convert_inline_inode - f2fs_convert_inline_page - f2fs_reserve_block - f2fs_reserve_new_block - f2fs_reserve_new_blocks - f2fs_i_blocks_write - dquot_claim_block inode->i_blocks increase, but the dqb_curspace keep the size for the dquots is NULL. To fix this issue, let's call dquot_initialize() anyway in both f2fs_truncate() and f2fs_convert_inline_inode() functions to avoid potential inconsistent quota data issue. Fixes: 0abd675e97e6 ("f2fs: support plain user/group quota") Signed-off-by: Daiyue Zhang Signed-off-by: Dehe Gu Signed-off-by: Junchao Jiang Signed-off-by: Ge Qiu Signed-off-by: Yi Chen Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c10d188ce35ba699cee13713b7e2e6d9e0aa09e5 Author: Christophe JAILLET Date: Sun Jan 24 08:39:55 2021 +0100 mtd: rawnand: intel: Fix an error handling path in 'ebu_dma_start()' [ Upstream commit 073abfa7ea9a5b0537d6f92b42baedaf82a04c53 ] If 'dmaengine_prep_slave_single()' fails, we must undo a previous 'dma_map_single()' call, as already done in all the other error handling paths of this function. Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Christophe JAILLET Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210124073955.728797-1-christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 0b9b0bde9250b9e3392817117e1864986c20651e Author: Manivannan Sadhasivam Date: Mon Jan 4 09:41:37 2021 +0530 mtd: parsers: afs: Fix freeing the part name memory in failure [ Upstream commit 7b844cf445f0a7daa68be0ce71eb2c88d68b0c5d ] In the case of failure while parsing the partitions, the iterator should be pre decremented by one before starting to free the memory allocated by kstrdup(). Because in the failure case, kstrdup() will not succeed and thus no memory will be allocated for the current iteration. Fixes: 1fca1f6abb38 ("mtd: afs: simplify partition parsing") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij Cc: Linus Walleij Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210104041137.113075-5-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin commit 1a509a2ddbd70d0cab972f9626fc05a2baaeb522 Author: Srinivas Kandagatla Date: Mon Feb 1 16:14:29 2021 +0000 ASoC: codecs: add missing max_register in regmap config [ Upstream commit e8820dbddbcad7e91daacf7d42a49d1d04a4e489 ] For some reason setting max_register was missed from regmap_config. Without this cat /sys/kernel/debug/regmap/sdw:0:217:2010:0:1/range actually throws below Warning. WARNING: CPU: 7 PID: 540 at drivers/base/regmap/regmap-debugfs.c:160 regmap_debugfs_get_dump_start.part.10+0x1e0/0x220 ... Call trace: regmap_debugfs_get_dump_start.part.10+0x1e0/0x220 regmap_reg_ranges_read_file+0xc0/0x2e0 full_proxy_read+0x64/0x98 vfs_read+0xa8/0x1e0 ksys_read+0x6c/0x100 __arm64_sys_read+0x1c/0x28 el0_svc_common.constprop.3+0x6c/0x190 do_el0_svc+0x24/0x90 el0_svc+0x14/0x20 el0_sync_handler+0x90/0xb8 el0_sync+0x158/0x180 ... Fixes: a0aab9e1404a ("ASoC: codecs: add wsa881x amplifier support") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210201161429.28060-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2248df3742230690ee9ee063f6e469a70dace747 Author: Sebastian Reichel Date: Sat Jan 23 18:29:45 2021 +0100 ASoC: cpcap: fix microphone timeslot mask [ Upstream commit de5bfae2fd962a9da99f56382305ec7966a604b9 ] The correct mask is 0x1f8 (Bit 3-8), but due to missing BIT() 0xf (Bit 0-3) was set instead. This means setting of CPCAP_BIT_MIC1_RX_TIMESLOT0 (Bit 3) still worked (part of both masks). On the other hand the code does not properly clear the other MIC timeslot bits. I think this is not a problem, since they are probably initialized to 0 and not touched by the driver anywhere else. But the mask also contains some wrong bits, that will be cleared. Bit 0 (CPCAP_BIT_SMB_CDC) should be safe, since the driver enforces it to be 0 anyways. Bit 1-2 are CPCAP_BIT_FS_INV and CPCAP_BIT_CLK_INV. This means enabling audio recording forces the codec into SND_SOC_DAIFMT_NB_NF mode, which is obviously bad. The bug probably remained undetected, because there are not many use cases for routing microphone to the CPU on platforms using cpcap and user base is small. I do remember having some issues with bad sound quality when testing voice recording back when I wrote the driver. It probably was this bug. Fixes: f6cdf2d3445d ("ASoC: cpcap: new codec") Reported-by: Dan Carpenter Signed-off-by: Sebastian Reichel Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20210123172945.3958622-1-sre@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a3e683a381485f7691cfaf5be9e332e3f24c5a88 Author: Florian Fainelli Date: Fri Jan 29 10:28:45 2021 -0800 ata: ahci_brcm: Add back regulators management [ Upstream commit 10340f8d7b6dd54e616339c8ccb2f397133ebea0 ] While reworking the resources management and departing from using ahci_platform_enable_resources() which did not allow a proper step separation like we need, we unfortunately lost the ability to control AHCI regulators. This broke some Broadcom STB systems that do expect regulators to be turned on to link up with attached hard drives. Fixes: c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management") Signed-off-by: Florian Fainelli Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7d139eb7944fcdc0e47d3734a0d2e89e3f6c18a3 Author: Will Deacon Date: Wed Jan 27 23:53:42 2021 +0000 mm: proc: Invalidate TLB after clearing soft-dirty page state [ Upstream commit 912efa17e5121693dfbadae29768f4144a3f9e62 ] Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double flush"), TLB invalidation is elided in tlb_finish_mmu() if no entries were batched via the tlb_remove_*() functions. Consequently, the page-table modifications performed by clear_refs_write() in response to a write to /proc//clear_refs do not perform TLB invalidation. Although this is fine when simply aging the ptes, in the case of clearing the "soft-dirty" state we can end up with entries where pte_write() is false, yet a writable mapping remains in the TLB. Fix this by avoiding the mmu_gather API altogether: managing both the 'tlb_flush_pending' flag on the 'mm_struct' and explicit TLB invalidation for the sort-dirty path, much like mprotect() does already. Fixes: 0758cd830494 ("asm-generic/tlb: avoid potential double flush”) Signed-off-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Yu Zhao Acked-by: Peter Zijlstra (Intel) Acked-by: Linus Torvalds Link: https://lkml.kernel.org/r/20210127235347.1402-2-will@kernel.org Signed-off-by: Sasha Levin commit 1c649f48e44da53dfdf3ad4ed75550464b8f03d6 Author: Biwen Li Date: Fri Jan 29 17:50:34 2021 +0800 irqchip/ls-extirq: add IRQCHIP_SKIP_SET_WAKE to the irqchip flags [ Upstream commit c60767421e102dfd1f4d99ad0cc7f8ba24461eb8 ] The ls-extirq driver doesn't implement the irq_set_wake() callback, while being wake-up capable. This results in ugly behaviours across suspend/resume cycles. Advertise this by adding IRQCHIP_SKIP_SET_WAKE to the irqchip flags Fixes: b16a1caf4686 ("irqchip/ls-extirq: Add LS1043A, LS1088A external interrupt support") Signed-off-by: Biwen Li Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210129095034.33821-1-biwen.li@oss.nxp.com Signed-off-by: Sasha Levin commit 22be6292f9334b2b6d8e39942c4d65e02859156c Author: Frantisek Hrbata Date: Fri Aug 28 11:28:46 2020 +0200 drm/nouveau: bail out of nouveau_channel_new if channel init fails [ Upstream commit eaba3b28401f50e22d64351caa8afe8d29509f27 ] Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC ioctl. This was reported by trinity[1] fuzzer. [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 71.088928] #PF: supervisor read access in kernel mode [ 71.094059] #PF: error_code(0x0000) - not-present page [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0 [ 71.104842] Oops: 0000 [#1] SMP NOPTI [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2 [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014 [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau] [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41 [ 71.147074] RSP: 0018:ffffb4a1809cfd38 EFLAGS: 00010246 [ 71.152526] RAX: 0000000000000000 RBX: ffff98cedbaa1d20 RCX: 00000000000003bf [ 71.159651] RDX: 00000000000003be RSI: 0000000000000000 RDI: 0000000000030160 [ 71.166774] RBP: ffff98cee776de00 R08: ffffdc0144198a08 R09: ffff98ceeefd4000 [ 71.173901] R10: ffff98cee7e81780 R11: 0000000000000001 R12: ffffb4a1809cfe08 [ 71.181214] R13: ffff98cee776d000 R14: ffff98cec519e000 R15: ffff98cee776def0 [ 71.188339] FS: 00007fd926250500(0000) GS:ffff98ceeac80000(0000) knlGS:0000000000000000 [ 71.196418] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.202155] CR2: 00000000000000a0 CR3: 0000000106622000 CR4: 00000000000406e0 [ 71.209297] Call Trace: [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm] [ 71.222421] drm_ioctl+0x211/0x3c0 [drm] [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau] [ 71.237285] ksys_ioctl+0x86/0xc0 [ 71.240595] __x64_sys_ioctl+0x16/0x20 [ 71.244340] do_syscall_64+0x4c/0x90 [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 71.253162] RIP: 0033:0x7fd925d4b88b [ 71.256731] Code: Bad RIP value. [ 71.259955] RSP: 002b:00007ffc743592d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 71.267514] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd925d4b88b [ 71.274637] RDX: 0000000000601080 RSI: 00000000c0586442 RDI: 0000000000000003 [ 71.281986] RBP: 00007ffc74359340 R08: 00007fd926016ce0 R09: 00007fd926016ce0 [ 71.289111] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000400620 [ 71.296235] R13: 00007ffc74359420 R14: 0000000000000000 R15: 0000000000000000 [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod [ 71.365269] CR2: 00000000000000a0 simplified reproducer ---------------------------------8<---------------------------------------- /* * gcc -o crashme crashme.c * ./crashme /dev/dri/renderD128 */ struct drm_nouveau_channel_alloc { uint32_t fb_ctxdma_handle; uint32_t tt_ctxdma_handle; int channel; uint32_t pushbuf_domains; /* Notifier memory */ uint32_t notifier_handle; /* DRM-enforced subchannel assignments */ struct { uint32_t handle; uint32_t grclass; } subchan[8]; uint32_t nr_subchan; }; static struct drm_nouveau_channel_alloc channel; int main(int argc, char *argv[]) { int fd; int rv; if (argc != 2) die("usage: %s ", 0, argv[0]); if ((fd = open(argv[1], O_RDONLY)) == -1) die("open %s", errno, argv[1]); if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 && errno == EACCES) die("ioctl %s", errno, argv[1]); close(fd); printf("PASS\n"); return 0; } ---------------------------------8<---------------------------------------- [1] https://github.com/kernelslacker/trinity Fixes: eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by: Frantisek Hrbata Reviewed-by: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 1227d25a19ff230f0ffffb9063f033919cdef523 Author: Christophe Leroy Date: Wed Jan 20 18:57:25 2021 +0000 crypto: talitos - Fix ctr(aes) on SEC1 [ Upstream commit 43a942d27eaaf33bca560121cbe42f3637e92880 ] While ctr(aes) requires the use of a special descriptor on SEC2 (see commit 70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")), that special descriptor doesn't work on SEC1, see commit e738c5f15562 ("powerpc/8xx: Add DT node for using the SEC engine of the MPC885"). However, the common nonsnoop descriptor works properly on SEC1 for ctr(aes). Add a second template for ctr(aes) that will be registered only on SEC1. Fixes: 70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos") Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c18c71f6e0202449381c86b3c452e5eacb7381cd Author: Christophe Leroy Date: Wed Jan 20 18:57:24 2021 +0000 crypto: talitos - Work around SEC6 ERRATA (AES-CTR mode data size error) [ Upstream commit 416b846757bcea20006a9197e67ba3a8b5b2a680 ] Talitos Security Engine AESU considers any input data size that is not a multiple of 16 bytes to be an error. This is not a problem in general, except for Counter mode that is a stream cipher and can have an input of any size. Test Manager for ctr(aes) fails on 4th test vector which has a length of 499 while all previous vectors which have a 16 bytes multiple length succeed. As suggested by Freescale, round up the input data length to the nearest 16 bytes. Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes") Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ae5c1589d012a27341c3d2e6afaedfd2e926a36c Author: Dan Carpenter Date: Thu Jan 28 12:36:52 2021 +0300 mtd: parser: imagetag: fix error codes in bcm963xx_parse_imagetag_partitions() [ Upstream commit 12ba8f8ce29fdd277f3100052eddc1afd2f5ea3f ] If the kstrtouint() calls fail, then this should return a negative error code but it currently returns success. Fixes: dd84cb022b31 ("mtd: bcm63xxpart: move imagetag parsing to its own parser") Signed-off-by: Dan Carpenter Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/YBKFtNaFHGYBj+u4@mwanda Signed-off-by: Sasha Levin commit b0a2bbe6142eec2ae4bcf61eb1209ce7030194e9 Author: Robin Murphy Date: Thu Jan 28 13:12:44 2021 +0000 perf/arm-cmn: Move IRQs when migrating context [ Upstream commit 1c8147ea89c883d1f4e20f1b1d9c879291430102 ] If we migrate the PMU context to another CPU, we need to remember to retarget the IRQs as well. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/e080640aea4ed8dfa870b8549dfb31221803eb6b.1611839564.git.robin.murphy@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ae33f15a72ba40370b079ba33da5e57d568aca19 Author: Robin Murphy Date: Thu Jan 28 13:12:43 2021 +0000 perf/arm-cmn: Fix PMU instance naming [ Upstream commit 79d7c3dca99fa96033695ddf5d495b775a3a137b ] Although it's neat to avoid the suffix for the typical case of a single PMU, it means systems with multiple CMN instances end up with inconsistent naming. I think it also breaks perf tool's "uncore alias" logic if the common instance prefix is also the full name of one. Avoid any surprises by not trying to be clever and simply numbering every instance, even when it might technically prove redundant. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/649a2281233f193d59240b13ed91b57337c77b32.1611839564.git.robin.murphy@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1cb08f474be787611b317001bf2ca0d90e29e15a Author: Ranjani Sridharan Date: Thu Jan 28 11:23:45 2021 +0200 ASoC: SOF: Intel: hda: cancel D0i3 work during runtime suspend [ Upstream commit 0084364d9678e9d722ee620ed916f2f9954abdbf ] Cancel the D0i3 work during runtime suspend as no streams are active at this point anyway. Fixes: 63e51fd33fef ("ASoC: SOF: Intel: cnl: Implement feature to support DSP D0i3 in S0") Signed-off-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210128092345.1033085-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ea6ccb7d20074a61eb46606ab1edd9c41c112192 Author: Srinivasa Rao Mandadapu Date: Wed Jan 27 20:48:24 2021 +0530 ASoC: qcom: lpass-cpu: Remove bit clock state check [ Upstream commit 6c28377b7114d04cf82eedffe9dcc8fa66ecec48 ] No need of BCLK state maintenance from driver side as clock_enable and clk_disable API's maintaing state counter. One of the major issue was spotted when Headset jack inserted while playback continues, due to same PCM device node opens twice for playaback/capture and closes once for capture and playback continues. It can resolve the errors in such scenarios. Fixes: b1824968221c ("ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF invalid state") Signed-off-by: Srinivasa Rao Mandadapu Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210127151824.8929-1-srivasam@codeaurora.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e9dcc5e5eab492e88689a0a7525ddc301bda0a6b Author: Chao Yu Date: Mon Jan 11 17:42:53 2021 +0800 f2fs: compress: fix potential deadlock [ Upstream commit 3afae09ffea5e08f523823be99a784675995d6bb ] generic/269 reports a hangtask issue, the root cause is ABBA deadlock described as below: Thread A Thread B - down_write(&sbi->gc_lock) -- A - f2fs_write_data_pages - lock all pages in cluster -- B - f2fs_write_multi_pages - f2fs_write_raw_pages - f2fs_write_single_data_page - f2fs_balance_fs - down_write(&sbi->gc_lock) -- A - f2fs_gc - do_garbage_collect - ra_data_block - pagecache_get_page -- B To fix this, it needs to avoid calling f2fs_balance_fs() if there is still cluster pages been locked in context of cluster writeback, so instead, let's call f2fs_balance_fs() in the end of f2fs_write_raw_pages() when all cluster pages were unlocked. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9ea33f83b151e840cba23f89e71ca37643219574 Author: Daeho Jeong Date: Wed Jan 6 08:49:28 2021 +0900 f2fs: fix null page reference in redirty_blocks [ Upstream commit df0736d70c4fa6ed711ba103b61880fe72bb4777 ] By Colin's static analysis, we found out there is a null page reference under low memory situation in redirty_blocks. I've made the page finding loop stop immediately and return an error not to cause further memory pressure when we run into a failure to find a page under low memory condition. Signed-off-by: Daeho Jeong Reported-by: Colin Ian King Fixes: 5fdb322ff2c2 ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE") Reviewed-by: Colin Ian King Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 17bd7926849e3e8ec24842d28993d8336067ba92 Author: Qais Yousef Date: Tue Jan 19 12:07:55 2021 +0000 sched/eas: Don't update misfit status if the task is pinned [ Upstream commit 0ae78eec8aa64e645866e75005162603a77a0f49 ] If the task is pinned to a cpu, setting the misfit status means that we'll unnecessarily continuously attempt to migrate the task but fail. This continuous failure will cause the balance_interval to increase to a high value, and eventually cause unnecessary significant delays in balancing the system when real imbalance happens. Caught while testing uclamp where rt-app calibration loop was pinned to cpu 0, shortly after which we spawn another task with high util_clamp value. The task was failing to migrate after over 40ms of runtime due to balance_interval unnecessary expanded to a very high value from the calibration loop. Not done here, but it could be useful to extend the check for pinning to verify that the affinity of the task has a cpu that fits. We could end up in a similar situation otherwise. Fixes: 3b1baa6496e6 ("sched/fair: Add 'group_misfit_task' load-balance type") Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Quentin Perret Acked-by: Valentin Schneider Link: https://lkml.kernel.org/r/20210119120755.2425264-1-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 08df8cbd034cde36229c7c60c7f1ec505270f7f8 Author: Judy Hsiao Date: Wed Jan 27 21:56:20 2021 +0800 ASoC: max98373: Fixes a typo in max98373_feedback_get [ Upstream commit ded055eea679139f11bd808795d9697b430d1c7d ] The snd_soc_put_volsw in max98373_feedback_get is a typo, change it to snd_soc_get_volsw. Fixes: 349dd23931d1 ("ASoC: max98373: don't access volatile registers in bias level off") Signed-off-by: Judy Hsiao Link: https://lore.kernel.org/r/20210127135620.1143942-1-judyhsiao@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e61927d07b04c633b6156b57a8db58fb7610c003 Author: Lad Prabhakar Date: Wed Jan 20 10:01:48 2021 +0100 media: i2c/Kconfig: Select FWNODE for OV772x sensor [ Upstream commit b7cdd6453ca2c2449c5270f2d0ae88b644a1d2fb ] Fix OV772x build breakage by selecting V4L2_FWNODE config: ia64-linux-ld: drivers/media/i2c/ov772x.o: in function `ov772x_probe': ov772x.c:(.text+0x1ee2): undefined reference to `v4l2_fwnode_endpoint_alloc_parse' ia64-linux-ld: ov772x.c:(.text+0x1f12): undefined reference to `v4l2_fwnode_endpoint_free' ia64-linux-ld: ov772x.c:(.text+0x2212): undefined reference to `v4l2_fwnode_endpoint_alloc_parse' Fixes: 8a10b4e3601e ("media: i2c: ov772x: Parse endpoint properties") Reported-by: kernel test robot Signed-off-by: Lad Prabhakar Acked-by: Jacopo Mondi Reviewed-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bd2e658ae5c81323a65ae23013b935bfc959d2cd Author: Laurent Pinchart Date: Sun Dec 20 15:11:13 2020 +0100 media: uvcvideo: Accept invalid bFormatIndex and bFrameIndex values [ Upstream commit dc9455ffae02d7b7fb51ba1e007fffcb9dc5d890 ] The Renkforce RF AC4K 300 Action Cam 4K reports invalid bFormatIndex and bFrameIndex values when negotiating the video probe and commit controls. The UVC descriptors report a single supported format and frame size, with bFormatIndex and bFrameIndex both equal to 2, but the video probe and commit controls report bFormatIndex and bFrameIndex set to 1. The device otherwise operates correctly, but the driver rejects the values and fails the format try operation. Fix it by ignoring the invalid indices, and assuming that the format and frame requested by the driver are accepted by the device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=210767 Fixes: 8a652a17e3c0 ("media: uvcvideo: Ensure all probed info is returned to v4l2") Reported-by: Till Dörges Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e02b9e28230865d9b8d4b33a4a64fade70c5c477 Author: Tom Rix Date: Mon Jan 18 14:45:13 2021 +0100 media: pxa_camera: declare variable when DEBUG is defined [ Upstream commit 031b9212eeee365443aaef013360ea6cded7b2c4 ] When DEBUG is defined this error occurs drivers/media/platform/pxa_camera.c:1410:7: error: ‘i’ undeclared (first use in this function) for (i = 0; i < vb->num_planes; i++) ^ The variable 'i' is missing, so declare it. Fixes: 6f28435d1c15 ("[media] media: platform: pxa_camera: trivial move of functions") Signed-off-by: Tom Rix Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d780594bad56029554ffeadcf3aa437947281532 Author: yangerkun Date: Mon Jan 25 20:49:36 2021 +0800 mtd: phram: use div_u64_rem to stop overwrite len in phram_setup [ Upstream commit dc2b3e5cbc8087224fcd8698b0dc56131e0bf37d ] We now support user to set erase page size, and use do_div between len and erase size to determine the reasonableness for the erase size. However, do_div is a macro and will overwrite the value of len. Which results a mtd device with unexcepted size. Fix it by use div_u64_rem. Fixes: ffad560394de ("mtd: phram: Allow the user to set the erase page size.") Signed-off-by: yangerkun Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210125124936.651812-1-yangerkun@huawei.com Signed-off-by: Sasha Levin commit 1ff3568dad78f5089eac0c4de9792983562c9fdc Author: Tom Rix Date: Sun Jan 17 23:21:38 2021 +0100 media: mtk-vcodec: fix argument used when DEBUG is defined [ Upstream commit a04e187d231086a1313fd635ac42bdbc997137ad ] When DEBUG is defined this error occurs drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c:306:41: error: ‘i’ undeclared (first use in this function) mtk_v4l2_debug(2, "reg[%d] base=0x%p", i, dev->reg_base[VENC_SYS]); Reviewing the old line mtk_v4l2_debug(2, "reg[%d] base=0x%p", i, dev->reg_base[i]); All the i's need to be changed to VENC_SYS. Fix a similar error for VENC_LT_SYS. Fixes: 0dc4b3286125 ("media: mtk-vcodec: venc: support SCP firmware") Signed-off-by: Tom Rix Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 968a7e9a04f8fa57ed4c8dad1a59c1d2f2625a9e Author: Christophe JAILLET Date: Sat Jan 16 22:21:46 2021 +0100 media: cx25821: Fix a bug when reallocating some dma memory [ Upstream commit b2de3643c5024fc4fd128ba7767c7fb8b714bea7 ] This function looks like a realloc. However, if 'risc->cpu != NULL', the memory will be freed, but never reallocated with the bigger 'size'. Explicitly set 'risc->cpu' to NULL, so that the reallocation is correctly performed a few lines below. [hverkuil: NULL != risc->cpu -> risc->cpu] Fixes: 5ede94c70553 ("[media] cx25821: remove bogus btcx_risc dependency) Signed-off-by: Christophe JAILLET Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f655fb2923f90acdaff508533038f588aa5ceb63 Author: Luo Meng Date: Wed Nov 25 02:34:37 2020 +0100 media: qm1d1c0042: fix error return code in qm1d1c0042_init() [ Upstream commit fcf8d018bdca0453b8d6359062e6bc1512d04c38 ] Fix to return a negative error code from the error handling case instead of 0 in function qm1d1c0042_init(), as done elsewhere in this function. Fixes: ab4d14528fdf ("[media] em28xx: add support for PLEX PX-BCUD (ISDB-S)") Reported-by: Hulk Robot Signed-off-by: Luo Meng Acked-by: Akihiro Tsukada Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 12a848b3612a1d6748de2a27df94f96511922a0c Author: Dan Carpenter Date: Fri Nov 20 17:27:18 2020 +0100 media: atomisp: Fix a buffer overflow in debug code [ Upstream commit 625993166b551d633917ca35d4afb7b46d7451b4 ] The "pad" variable is a user controlled string and we haven't properly clamped it at this point so the debug code could print from beyond the of the array. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fa0829fc98ea53b303eaf974dcdb7b99b08babaf Author: Daniel W. S. Almeida Date: Thu Dec 24 16:04:00 2020 +0100 media: vidtv: psi: fix missing crc for PMT [ Upstream commit 0a933a7f73d6c545dcbecb4f7a92d272aef4417b ] The PMT write function was refactored and this broke the CRC computation. Fix it. Fixes: db9569f67e2e ("media: vidtv: cleanup PMT write table function") Signed-off-by: Daniel W. S. Almeida Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 78b134feb0c72ad5c79787974021d9c73d28584f Author: Joe Perches Date: Sun Aug 23 20:13:31 2020 +0200 media: lmedm04: Fix misuse of comma [ Upstream commit 59a3e78f8cc33901fe39035c1ab681374bba95ad ] There's a comma used instead of a semicolon that causes multiple statements to be executed after an if instead of just the intended single statement. Replace the comma with a semicolon. Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb") Signed-off-by: Joe Perches Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2eb93424d58d798afde0be11344d9c3d0bb2fa97 Author: Daniel Scally Date: Thu Jan 7 14:28:24 2021 +0100 media: software_node: Fix refcounts in software_node_get_next_child() [ Upstream commit fb5ec981adf08b94e6ce27ca16b7765c94f4513c ] The software_node_get_next_child() function currently does not hold references to the child software_node that it finds or put the ref that is held against the old child - fix that. Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the firmware node framework") Reviewed-by: Andy Shevchenko Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Scally Reviewed-by: Heikki Krogerus Acked-by: Greg Kroah-Hartman Acked-by: Rafael J. Wysocki Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 95007a610edeaf7a066dc75c6d0b0916537d582e Author: Mario Kleiner Date: Thu Jan 21 07:17:03 2021 +0100 drm/amd/display: Fix HDMI deep color output for DCE 6-11. [ Upstream commit efa18405baa55a864c61d2f3cc6fe4d363818eb3 ] This fixes corrupted display output in HDMI deep color 10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3. It will hopefully also provide fixes for other DCE's up to DCE-11, assuming those will need similar fixes, but i could not test that for HDMI due to lack of suitable hw, so viewer discretion is advised. dce110_stream_encoder_hdmi_set_stream_attribute() is used for HDMI setup on all DCE's and is missing color_depth assignment. dce110_program_pix_clk() is used for pixel clock setup on HDMI for DCE 6-11, and is missing color_depth assignment. Additionally some of the underlying Atombios specific encoder and pixelclock setup functions are missing code which is in the classic amdgpu kms modesetting path and the in the radeon kms driver for DCE6/DCE8. encoder_control_digx_v3() - Was missing setup code wrt. amdgpu and radeon kms classic drivers. Added here, but untested due to lack of suitable test hw. encoder_control_digx_v4() - Added missing setup code. Successfully tested on AMD mullins / DCE-8.3 with HDMI deep color output at 10 bpc and 12 bpc. Note that encoder_control_digx_v5() has proper setup code in place and is used, e.g., by DCE-11.2, but this code wasn't used for deep color setup due to the missing cntl.color_depth setup in the calling function for HDMI. set_pixel_clock_v5() - Missing setup code wrt. classic amdgpu/radeon kms. Added here, but untested due to lack of hw. set_pixel_clock_v6() - Missing setup code added. Successfully tested on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI deep color output with 10 bpc or 12 bpc. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Reviewed-by: Nicholas Kazlauskas Signed-off-by: Mario Kleiner Cc: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f216e914106bb6558e6c4a2b84c0c58a895f6fd6 Author: Mario Kleiner Date: Thu Jan 21 07:17:02 2021 +0100 drm/amd/display: Fix 10/12 bpc setup in DCE output bit depth reduction. [ Upstream commit 1916866dfa4aaceba1a70db83fde569387649d93 ] In set_clamp(), the comments and definitions for the COLOR_DEPTH_101010 and COLOR_DEPTH_121212 cases directly contradict the code comment which explains how this should work, whereas the COLOR_DEPTH_888 case is consistent with the code comments. Comment says the bitmask should be chosen to align to the top-most 10 or 12 MSB's on a 14 bit bus, but the implementation contradicts that: 10 bit case sets a mask for 12 bpc clamping, whereas 12 bit case sets a mask for 14 bpc clamping. Note that during my limited testing on DCE-8.3 (HDMI deep color) and DCE-11.2 (DP deep color), this didn't have any obvious ill effects, neither did fixing it change anything obvious for the better, so this fix may be inconsequential on DCE, and just reduce the confusion of innocent bystanders when reading the code and trying to investigate problems with 10 bpc+ output. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Mario Kleiner Cc: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7cd35a83aa84d5dd86b60ec6d86039fa3059db2e Author: Finn Thain Date: Mon Jan 18 17:19:40 2021 +1100 macintosh/adb-iop: Use big-endian autopoll mask [ Upstream commit c396dd2ec5bbd1cb80eafe32a72ab6bd6b17cb5a ] As usual, the available documentation is inadequate and leaves endianness unspecified for message data. However, testing shows that this patch does improve correctness. The mistake should have been detected earlier but it was obscured by other bugs. In testing, this patch reinstated pre-v5.9 behaviour. The old driver bugs remain and ADB input devices may stop working. But that appears to be unrelated. Cc: Joshua Thompson Fixes: c66da95a39ec ("macintosh/adb-iop: Implement SRQ autopolling") Tested-by: Stan Johnson Signed-off-by: Finn Thain Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210125074524.3027452-1-geert@linux-m68k.org Signed-off-by: Sasha Levin commit db10f3338e87ec9e09fe6440121294a6d13d3698 Author: Pan Bian Date: Tue Jan 19 04:33:11 2021 -0800 bsg: free the request before return error code [ Upstream commit 0f7b4bc6bb1e57c48ef14f1818df947c1612b206 ] Free the request rq before returning error code. Fixes: 972248e9111e ("scsi: bsg-lib: handle bidi requests without block layer help") Signed-off-by: Pan Bian Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b720e3d5a67c810e103a53f2ea603014ad0e2e2a Author: Guchun Chen Date: Thu Jan 14 15:45:48 2021 +0800 drm/amdgpu: toggle on DF Cstate after finishing xgmi injection [ Upstream commit fe2d9f5abf19f2b3688b3b8da4e42f8d07886847 ] Fixes: 5c23e9e05e42 ("drm/amdgpu: Update RAS XGMI error inject sequence") Signed-off-by: Guchun Chen Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 706410da1e3410fb194efe81046c93ceed49f6bc Author: Qinglang Miao Date: Tue Dec 1 20:56:31 2020 +0800 drm/tegra: Fix reference leak when pm_runtime_get_sync() fails [ Upstream commit dcdfe2712b68f1e9dbf4f1a96ad59b80e5cc0ef7 ] The PM reference count is not expected to be incremented on return in these Tegra functions. However, pm_runtime_get_sync() will increment the PM reference count even on failure. Forgetting to put the reference again will result in a leak. Replace it with pm_runtime_resume_and_get() to keep the usage counter balanced. Fixes: fd67e9c6ed5a ("drm/tegra: Do not implement runtime PM") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5069373cae8a8fa010b5284ab8b7c650f933b1ac Author: Nathan Chancellor Date: Thu Jan 14 10:34:16 2021 -0700 MIPS: Compare __SYNC_loongson3_war against 0 [ Upstream commit 8790ccf8daf1a8c53b6cb8ce0c9a109274bd3fa8 ] When building with clang when CONFIG_CPU_LOONGSON3_WORKAROUNDS is enabled: In file included from lib/errseq.c:4: In file included from ./include/linux/atomic.h:7: ./arch/mips/include/asm/atomic.h:52:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] ATOMIC_OPS(atomic64, s64) ^ ./arch/mips/include/asm/atomic.h:40:9: note: expanded from macro 'ATOMIC_OPS' return cmpxchg(&v->counter, o, n); ^ ./arch/mips/include/asm/cmpxchg.h:194:7: note: expanded from macro 'cmpxchg' if (!__SYNC_loongson3_war) ^ ./arch/mips/include/asm/sync.h:147:34: note: expanded from macro '__SYNC_loongson3_war' # define __SYNC_loongson3_war (1 << 31) ^ While it is not wrong that the result of this shift is always true in a boolean context, it is not a problem here. Regardless, the warning is really noisy so rather than making the shift a boolean implicitly, use it in an equality comparison so the shift is used as an integer value. Fixes: 4d1dbfe6cbec ("MIPS: atomic: Emit Loongson3 sync workarounds within asm") Fixes: a91f2a1dba44 ("MIPS: cmpxchg: Omit redundant barriers for Loongson3") Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Acked-by: Nick Desaulniers Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ebd7426b1267433d052fcf54b46d00f0e9338da5 Author: Alexander Lobakin Date: Sun Jan 10 11:56:28 2021 +0000 MIPS: properly stop .eh_frame generation [ Upstream commit 894ef530012fb5078466efdfb2c15d8b2f1565cd ] Commit 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") added -fno-asynchronous-unwind-tables to KBUILD_CFLAGS to prevent compiler from emitting .eh_frame symbols. However, as MIPS heavily uses CFI, that's not enough. Use the approach taken for x86 (as it also uses CFI) and explicitly put CFI symbols into the .debug_frame section (except for VDSO). This allows us to drop .eh_frame from DISCARDS as it's no longer being generated. Fixes: 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") Suggested-by: Kees Cook Signed-off-by: Alexander Lobakin Reviewed-by: Kees Cook Reviewed-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 78a73b99ac50c6dae3b42d82418301df60960d53 Author: Tomi Valkeinen Date: Wed Jan 13 10:00:27 2021 +0100 media: ti-vpe: cal: fix write to unallocated memory [ Upstream commit 5a402af5e19f215689e8bf3cc244c21d94eba3c4 ] The asd allocated with v4l2_async_notifier_add_fwnode_subdev() must be of size cal_v4l2_async_subdev, otherwise access to cal_v4l2_async_subdev->phy will go to unallocated memory. Fixes: 8fcb7576ad19 ("media: ti-vpe: cal: Allow multiple contexts per subdev notifier") Signed-off-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 21ceb483c2f833b999afd669c3f7dfd123f5b661 Author: Rui Miguel Silva Date: Thu Jan 7 11:47:26 2021 +0100 media: imx7: csi: Fix pad link validation [ Upstream commit f5ffb81f51376eb5a12e8c4cb4871426c65bb2af ] We can not make the assumption that the bound subdev is always a CSI mux, in i.MX6UL/i.MX6ULL that is not the case. So, just get the entity selected by source directly upstream from the CSI. Fixes: 86e02d07871c ("media: imx5/6/7: csi: Mark a bound video mux as a CSI mux") Reported-by: Fabio Estevam Signed-off-by: Rui Miguel Silva Tested-by: Fabio Estevam Tested-by: Sébastien Szymanski Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 934fa59be5e791f396f072cef7f4023d70ae8c28 Author: Fabio Estevam Date: Thu Jan 7 11:47:25 2021 +0100 media: imx7: csi: Fix regression for parallel cameras on i.MX6UL [ Upstream commit 9bac67214fbf4b5f23463f7742ccf69bfe684cbd ] Commit 86e02d07871c ("media: imx5/6/7: csi: Mark a bound video mux as a CSI mux") made an incorrect assumption that for imx7-media-csi, the bound subdev must always be a CSI mux. On i.MX6UL/i.MX6ULL there is no CSI mux at all, so do not return an error when the entity is not a video mux and assign the IMX_MEDIA_GRP_ID_CSI_MUX group id only when appropriate. This is the same approach as done in imx-media-csi.c and it fixes the csi probe regression on i.MX6UL. Tested on a imx6ull-evk board. Fixes: 86e02d07871c ("media: imx5/6/7: csi: Mark a bound video mux as a CSI mux") Signed-off-by: Fabio Estevam Signed-off-by: Rui Miguel Silva Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b0e5d228430ed45b3942b410e02dc05c60f03e1b Author: Giulio Benetti Date: Thu Jan 14 09:17:32 2021 +0100 drm/sun4i: tcon: fix inverted DCLK polarity [ Upstream commit 67f4aeb2b41a0629abde3794d463547f60b0cbdd ] During commit 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_* macros have been changed to avoid ambiguity but just because of this ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning _SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but instead of swapping phase values, let's adopt an easier approach Maxime suggested: It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to invert DCLK polarity and this makes things really easier than before. So let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE as bit 26 and activating according to bus_flags the same way it is done for all the other signals polarity. Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") Suggested-by: Maxime Ripard Signed-off-by: Giulio Benetti Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210114081732.9386-1-giulio.benetti@benettiengineering.com Signed-off-by: Sasha Levin commit 1a2e8fc906021a99dcd49b75195ec490da4c89d0 Author: Xuewen Yan Date: Fri Dec 18 17:27:52 2020 +0800 sched/fair: Avoid stale CPU util_est value for schedutil in task dequeue [ Upstream commit 8c1f560c1ea3f19e22ba356f62680d9d449c9ec2 ] CPU (root cfs_rq) estimated utilization (util_est) is currently used in dequeue_task_fair() to drive frequency selection before it is updated. with: CPU_util : rq->cfs.avg.util_avg CPU_util_est : rq->cfs.avg.util_est CPU_utilization : max(CPU_util, CPU_util_est) task_util : p->se.avg.util_avg task_util_est : p->se.avg.util_est dequeue_task_fair(): /* (1) CPU_util and task_util update + inform schedutil about CPU_utilization changes */ for_each_sched_entity() /* 2 loops */ (dequeue_entity() ->) update_load_avg() -> cfs_rq_util_change() -> cpufreq_update_util() ->...-> sugov_update_[shared\|single] -> sugov_get_util() -> cpu_util_cfs() /* (2) CPU_util_est and task_util_est update */ util_est_dequeue() cpu_util_cfs() uses CPU_utilization which could lead to a false (too high) utilization value for schedutil in task ramp-down or ramp-up scenarios during task dequeue. To mitigate the issue split the util_est update (2) into: (A) CPU_util_est update in util_est_dequeue() (B) task_util_est update in util_est_update() Place (A) before (1) and keep (B) where (2) is. The latter is necessary since (B) relies on task_util update in (1). Fixes: 7f65ea42eb00 ("sched/fair: Add util_est on top of PELT") Signed-off-by: Xuewen Yan Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/1608283672-18240-1-git-send-email-xuewen.yan94@gmail.com Signed-off-by: Sasha Levin commit 1515d61bd9ee830734de74864d423dbc8390b625 Author: Jiri Olsa Date: Tue Jan 5 00:02:37 2021 +0100 crypto: bcm - Rename struct device_private to bcm_device_private [ Upstream commit f7f2b43eaf6b4cfe54c75100709be31d5c4b52c8 ] Renaming 'struct device_private' to 'struct bcm_device_private', because it clashes with 'struct device_private' from 'drivers/base/base.h'. While it's not a functional problem, it's causing two distinct type hierarchies in BTF data. It also breaks build with options: CONFIG_DEBUG_INFO_BTF=y CONFIG_CRYPTO_DEV_BCM_SPU=y as reported by Qais Yousef [1]. [1] https://lore.kernel.org/lkml/20201229151352.6hzmjvu3qh6p2qgg@e107158-lin/ Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Jiri Olsa Tested-by: Qais Yousef Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 425951b2256f9fb202da126fe93a930f5d052446 Author: Marco Chiappero Date: Mon Jan 4 15:35:15 2021 +0000 crypto: qat - replace CRYPTO_AES with CRYPTO_LIB_AES in Kconfig [ Upstream commit 4f1a02e75a2eedfddd10222c0fe61d2a04d80099 ] Use CRYPTO_LIB_AES in place of CRYPTO_AES in the dependences for the QAT common code. Fixes: c0e583ab2016 ("crypto: qat - add CRYPTO_AES to Kconfig dependencies") Reported-by: Ard Biesheuvel Signed-off-by: Marco Chiappero Acked-by: Ard Biesheuvel Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b00582072debcd897bed00400fa4a803a9758069 Author: Dinghao Liu Date: Sun Jan 10 16:02:53 2021 +0800 evm: Fix memleak in init_desc [ Upstream commit ccf11dbaa07b328fa469415c362d33459c140a37 ] tmp_tfm is allocated, but not freed on subsequent kmalloc failure, which leads to a memory leak. Free tmp_tfm. Fixes: d46eb3699502b ("evm: crypto hash replaced by shash") Signed-off-by: Dinghao Liu [zohar@linux.ibm.com: formatted/reworded patch description] Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 977630fee781c66ad2263568da2c18428aea7593 Author: Stephan Gerhold Date: Fri Dec 11 21:32:55 2020 +0100 ASoC: qcom: qdsp6: Move frontend AIFs to q6asm-dai [ Upstream commit 6fd8d2d275f74baa7ac17b2656da1235f56dab99 ] At the moment it is necessary to set up the DAPM routes between front-end AIF<->DAI explicitly in the device tree, e.g. using audio-routing = "MM_DL1", "MultiMedia1 Playback", "MM_DL3", "MultiMedia3 Playback", "MM_DL4", "MultiMedia4 Playback", "MultiMedia2 Capture", "MM_UL2"; This is prone to mistakes and (sadly) there is no clear error if one of these routes is missing. :( Actually, this should not be necessary because the ASoC core normally automatically links AIF<->DAI within snd_soc_dapm_link_dai_widgets(). This is done using the "stname" parameter of SND_SOC_DAPM_AIF_IN/OUT. For SND_SOC_DAPM_AIF_IN("MM_DL1", "MultiMedia1 Playback", 0, 0, 0, 0), it should create the route from above: MM_DL1 <-> MultiMedia1 Playback. This does not work at the moment because the AIF widget (MM_DL1) and the DAI widget (MultiMedia1 Playback) belong to different DAPM contexts (q6routing / q6asm-dai). Fix this by declaring the AIF widgets in the same driver as the DAIs (q6asm-dai). Now the routes above are created automatically and no longer need to be specified in the device tree. This is also more consistent with the back-end AIFs which are already declared in q6afe-dais instead of q6routing. q6routing should only link the components together using mixers. Cc: Srinivas Kandagatla Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20201211203255.148246-1-stephan@gerhold.net Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 33f54ec318e6c7c526cca67b395a7f943b6f047f Author: Dan Carpenter Date: Fri Dec 11 13:07:59 2020 +0300 ASoC: cs42l56: fix up error handling in probe [ Upstream commit 856fe64da84c95a1d415564b981ae3908eea2a76 ] There are two issues with this code. The first error path forgot to set the error code and instead returns success. The second error path doesn't clean up. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X9NE/9nK9/TuxuL+@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 889385a944b76458e93db333823b85632a3acd9c Author: Zhang Changzhong Date: Fri Dec 4 09:27:58 2020 +0100 media: aspeed: fix error return code in aspeed_video_setup_video() [ Upstream commit d497fcdab02996a4510d5dd0d743447c737c317a ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Reported-by: Hulk Robot Signed-off-by: Zhang Changzhong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1689542262dc32073410f31a008a53d6be05ebb4 Author: Dinghao Liu Date: Sat Jan 2 09:26:37 2021 +0100 media: tm6000: Fix memleak in tm6000_start_stream [ Upstream commit 76aaf8a96771c16365b8510f1fb97738dc88026e ] When usb_clear_halt() fails, dvb->bulk_urb->transfer_buffer and dvb->bulk_urb should be freed just like when usb_submit_urb() fails. Fixes: 3169c9b26fffa ("V4L/DVB (12788): tm6000: Add initial DVB-T support") Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9e421dd6e33c08ea0c5b9c1b607c447854571227 Author: Dinghao Liu Date: Sat Jan 2 07:27:22 2021 +0100 media: media/pci: Fix memleak in empress_init [ Upstream commit 15d0c52241ecb1c9d802506bff6f5c3f7872c0df ] When vb2_queue_init() fails, dev->empress_dev should be released just like other error handling paths. Fixes: 2ada815fc48bb ("[media] saa7134: convert to vb2") Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c28ea5110e4c1d1468bbbc45408258fe28df7845 Author: Dinghao Liu Date: Mon Dec 28 14:02:05 2020 +0100 media: em28xx: Fix use-after-free in em28xx_alloc_urbs [ Upstream commit a26efd1961a18b91ae4cd2e433adbcf865b40fa3 ] When kzalloc() fails, em28xx_uninit_usb_xfer() will free usb_bufs->buf and set it to NULL. Thus the later access to usb_bufs->buf[i] will lead to null pointer dereference. Also the kfree(usb_bufs->buf) after that is redundant. Fixes: d571b592c6206 ("media: em28xx: don't use coherent buffer for DMA transfers") Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d025f2666daada41eb6081ec5e74e646d13e0d82 Author: Christophe JAILLET Date: Sat Dec 12 18:41:19 2020 +0100 media: vsp1: Fix an error handling path in the probe function [ Upstream commit 7113469dafc2d545fa4fa9bc649c31dc27db492e ] A previous 'rcar_fcp_get()' call must be undone in the error handling path, as already done in the remove function. Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support") Signed-off-by: Christophe JAILLET Reviewed-by: Geert Uytterhoeven Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a255af7b796d45656e71618f5baf72df2a675aee Author: Dan Carpenter Date: Wed Dec 9 07:51:30 2020 +0100 media: camss: missing error code in msm_video_register() [ Upstream commit 9c67ed2ab299123872be14a3dc2ea44ce7e4538b ] This error path returns success but it should return -EINVAL. Fixes: cba3819d1e93 ("media: camss: Format configuration per hardware version") Signed-off-by: Dan Carpenter Reviewed-by: Robert Foss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2b5d3eefb76e4f3f428c552838f573fe37f8a360 Author: Dan Carpenter Date: Wed Dec 9 07:50:34 2020 +0100 media: camss: Fix signedness bug in video_enum_fmt() [ Upstream commit b00481bdca2d77fdae5f71517c09fd3b30eba57d ] This test has a problem because we want to know if "k" is -1 or a positive value less than "f->index". But the "f->index" variable is a u32 so if "k == -1" then -1 gets type promoted to UINT_MAX which is larger than "f->index". I've added an explicit test to check for -1. Fixes: a3d412d4b9f3 ("media: Revert "media: camss: Make use of V4L2_CAP_IO_MC"") Signed-off-by: Dan Carpenter Reviewed-by: Robert Foss Reviewed-by: Andrey Konovalov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a35126ff55e7b92c1f883d762eceb8a3d151b5a0 Author: Zhang Changzhong Date: Fri Dec 4 09:29:34 2020 +0100 media: mtk-vcodec: fix error return code in vdec_vp9_decode() [ Upstream commit 4397efebf039be58e98c81a194a26100eba597bb ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: dea42fb79f4f ("media: mtk-vcodec: reset segment data then trig decoder") Reported-by: Hulk Robot Signed-off-by: Zhang Changzhong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3d046caec3c8e6f89db75a57e5631b9d396f8a02 Author: Ezequiel Garcia Date: Mon Jan 4 21:34:40 2021 +0100 media: imx: Fix csc/scaler unregister [ Upstream commit 89b14485caa4b7b2eaf70be0064f0978e68ebeee ] The csc/scaler device private struct is released by ipu_csc_scaler_video_device_release(), which can be called by video_unregister_device() if there are no users of the underlying struct video device. Therefore, the mutex can't be held when calling video_unregister_device() as its memory may be freed by it, leading to a kernel oops. Fortunately, the fix is quite simple as no locking is needed when calling video_unregister_device(): v4l2-core already has its own internal locking, and the structures are also properly refcounted. Fixes: a8ef0488cc59 ("media: imx: add csc/scaler mem2mem device") Signed-off-by: Ezequiel Garcia Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a6a6716d6d938527d984450f77ace1db9c0bd09e Author: Ezequiel Garcia Date: Mon Jan 4 21:34:39 2021 +0100 media: imx: Unregister csc/scaler only if registered [ Upstream commit bb2216548a2b13cf2942a058b475438a7a6bb028 ] The csc/scaler device pointer (imxmd->m2m_vdev) is assigned after the imx media device v4l2-async probe completes, therefore we need to check if the device is non-NULL before trying to unregister it. This can be the case if the non-completed imx media device is unbinded (or the driver is removed), leading to a kernel oops. Fixes: a8ef0488cc59 ("media: imx: add csc/scaler mem2mem device") Signed-off-by: Ezequiel Garcia Reviewed-by: Philipp Zabel Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b518748ad3f66df9bfd734980cb1c12d57ae4d9f Author: Jacopo Mondi Date: Mon Dec 21 18:52:20 2020 +0100 media: i2c: ov5670: Fix PIXEL_RATE minimum value [ Upstream commit dc1eb7c9c290cba52937c9a224b22a400bb0ffd7 ] The driver currently reports a single supported value for V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0, which is very risky, as userspace might accidentally use it as divider when calculating the time duration of a line. Fix this by using as minimum the only supported value when registering the control. Fixes: 5de35c9b8dcd1 ("media: i2c: Add Omnivision OV5670 5M sensor support") Signed-off-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cdde346705e6beeb34ccd44ba3520a44feb8138c Author: Andy Shevchenko Date: Mon Dec 14 16:28:32 2020 +0100 media: ipu3-cio2: Build only for x86 [ Upstream commit 3ef5e42d281ea108f4ccdca186de4ce20a346326 ] According to the original code in the driver it was never assumed to work with big page sizes: unsigned short type followed by PAGE_SHIFT and PAGE_MASK which may be different on non-x86 architectures. Recently LKP found an issue on non-x86 architectures due to above mentioned limitations. Since Sakari acknowledges that it's not really useful to be able to compile this elsewhere, mark it x86 only. Fixes: a31d19f88932 ("media: ipu3: allow building it with COMPILE_TEST on non-x86 archs") Reported-by: kernel test robot Suggested-by: Sakari Ailus Signed-off-by: Andy Shevchenko Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4b0a1cd29a6b7ac2eafeba2dac3fb05d0d434af7 Author: Simon Ser Date: Sun Jan 10 13:51:03 2021 +0100 drm/fourcc: fix Amlogic format modifier masks [ Upstream commit cc3283f8f41f741fbaef63d0503d8fb4a7919100 ] The comment says the layout and options use 8 bits, and the shift uses 8 bits. However the mask is 0xf, ie. 0b00001111 (4 bits). This could be surprising when introducing new layouts or options that take more than 4 bits, as this would silently drop the high bits. Make the masks consistent with the comment and the shift. Found when writing a drm_info patch [1]. [1]: https://github.com/ascent12/drm_info/pull/67 Signed-off-by: Simon Ser Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression") Cc: Neil Armstrong Cc: Sam Ravnborg Cc: Kevin Hilman Cc: Daniel Vetter Acked-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20210110125103.15447-1-contact@emersion.fr Signed-off-by: Sasha Levin commit 896f08f9bb74d45a278fac0534fab95fcc605477 Author: Chia-I Wu Date: Thu Jan 7 13:07:26 2021 -0800 drm/virtio: make sure context is created in gem open [ Upstream commit 8aeef9d4f48917ce85710949b079548974b4a638 ] The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is the first ioctl on the drm_file. Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl") Cc: Gurchetan Singh Cc: Gerd Hoffmann Signed-off-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20210107210726.269584-1-olvaffe@gmail.com Reviewed-by: Gurchetan Singh Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 4800d3e84e0d5f8544b6d8f3fde1f0d860047980 Author: Nathan Chancellor Date: Tue Jan 5 13:15:48 2021 -0700 MIPS: lantiq: Explicitly compare LTQ_EBU_PCC_ISTAT against 0 [ Upstream commit c6f2a9e17b9bef7677caddb1626c2402f3e9d2bd ] When building xway_defconfig with clang: arch/mips/lantiq/irq.c:305:48: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ^ ~~~~~~~~~~~~~~~~~ arch/mips/lantiq/irq.c:305:48: note: use '&' for a bitwise operation if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ^~ & arch/mips/lantiq/irq.c:305:48: note: remove constant to silence this warning if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ~^~~~~~~~~~~~~~~~~~~~ 1 error generated. Explicitly compare the constant LTQ_EBU_PCC_ISTAT against 0 to fix the warning. Additionally, remove the unnecessary parentheses as this is a simple conditional statement and shorthand '== 0' to '!'. Fixes: 3645da0276ae ("OF: MIPS: lantiq: implement irq_domain support") Link: https://github.com/ClangBuiltLinux/linux/issues/807 Reported-by: Dmitry Golovin Signed-off-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5d1e07d9c11144df5005b64327e14d7d82f700b2 Author: Nathan Chancellor Date: Tue Jan 5 13:34:56 2021 -0700 MIPS: c-r4k: Fix section mismatch for loongson2_sc_init [ Upstream commit c58734eee6a2151ba033c0dcb31902c89e310374 ] When building with clang, the following section mismatch warning occurs: WARNING: modpost: vmlinux.o(.text+0x24490): Section mismatch in reference from the function r4k_cache_init() to the function .init.text:loongson2_sc_init() This should have been fixed with commit ad4fddef5f23 ("mips: fix Section mismatch in reference") but it was missed. Remove the improper __init annotation like that commit did. Fixes: 078a55fc824c ("MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code") Link: https://github.com/ClangBuiltLinux/linux/issues/787 Signed-off-by: Nathan Chancellor Reviewed-by: Huacai Chen Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 552d169dc11671b1c165d6eb27df0908b35f9e6f Author: Chenyang Li Date: Sat Dec 26 16:56:07 2020 +0800 drm/amdgpu: Fix macro name _AMDGPU_TRACE_H_ in preprocessor if condition [ Upstream commit 956e20eb0fbb206e5e795539db5469db099715c8 ] Add an underscore in amdgpu_trace.h line 24 "_AMDGPU_TRACE_H". Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Reviewed-by: Guchun Chen Reviewed-by: Paul Menzel Signed-off-by: Chenyang Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6eddd494682c74400de80d1a0e6fb831e35343c3 Author: Wang Xiaojun Date: Wed Nov 11 11:14:52 2020 +0800 drm: rcar-du: Fix the return check of of_parse_phandle and of_find_device_by_node [ Upstream commit 8d7d33f6be06f929ac2c5e8ea2323fec272790d4 ] of_parse_phandle and of_find_device_by_node may return NULL which cannot be checked by IS_ERR. Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances") Signed-off-by: Wang Xiaojun Reported-by: Hulk Robot Acked-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Kieran Bingham [Replace -ENODEV with -EINVAL] Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 9bb9cb93ec7f27c1015e8604288bb6a58f5b318f Author: Laurent Pinchart Date: Fri Dec 4 13:43:58 2020 +0200 drm: rcar-du: Fix crash when using LVDS1 clock for CRTC [ Upstream commit 53ced169373aab52d3b5da0fee6a342002d1876d ] On D3 and E3 platforms, the LVDS encoder includes a PLL that can generate a clock for the corresponding CRTC, used even when the CRTC output to a non-LVDS port. This mechanism is supported by the driver, but the implementation is broken in dual-link LVDS mode. In that case, the LVDS1 drm_encoder is skipped, which causes a crash when trying to access its bridge later on. Fix this by storing bridge pointers internally instead of retrieving them from the encoder. The rcar_du_device encoders field isn't used anymore and can be dropped. Fixes: 8e8fddab0d0a ("drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode") Signed-off-by: Laurent Pinchart Reviewed-by: Jacopo Mondi Reviewed-by: Kieran Bingham Signed-off-by: Sasha Levin commit f2adf52894a8c5c984a30fa543009cf6e41c01d3 Author: Qinglang Miao Date: Fri Nov 27 17:44:44 2020 +0800 drm: rcar-du: Fix PM reference leak in rcar_cmm_enable() [ Upstream commit 136ce7684bc1ff4a088812f600c63daca50b32c2 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in a reference leak here. A new function pm_runtime_resume_and_get is introduced in [0] to keep usage counter balanced. So We fix the reference leak by replacing it with new funtion. [0] dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Acked-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit e1b1cdba485641e3b1f4cb12623dcf11852f8cfb Author: Marco Elver Date: Tue Nov 24 12:02:09 2020 +0100 kcsan: Rewrite kcsan_prandom_u32_max() without prandom_u32_state() [ Upstream commit 71a076f4a61a6c779794ad286f356b39725edc3b ] Rewrite kcsan_prandom_u32_max() to not depend on code that might be instrumented, removing any dependency on lib/random32.c. The rewrite implements a simple linear congruential generator, that is sufficient for our purposes (for udelay() and skip_watch counter randomness). The initial motivation for this was to allow enabling KCSAN for kernel/sched (remove KCSAN_SANITIZE := n from kernel/sched/Makefile), with CONFIG_DEBUG_PREEMPT=y. Without this change, we could observe recursion: check_access() [via instrumentation] kcsan_setup_watchpoint() reset_kcsan_skip() kcsan_prandom_u32_max() get_cpu_var() preempt_disable() preempt_count_add() [in kernel/sched/core.c] check_access() [via instrumentation] Note, while this currently does not affect an unmodified kernel, it'd be good to keep a KCSAN kernel working when KCSAN_SANITIZE := n is removed from kernel/sched/Makefile to permit testing scheduler code with KCSAN if desired. Fixes: cd290ec24633 ("kcsan: Use tracing-safe version of prandom") Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 2a771d12dc4a17245dc76dc87c60ef2d9e2a318d Author: Arnd Bergmann Date: Sun Jan 3 14:53:17 2021 +0100 ASoC: fsl_aud2htx: select SND_SOC_IMX_PCM_DMA [ Upstream commit a1f31cc4e98e1833f53fd2c6e9a218d6b86f5388 ] The newly added driver requires DMA support and fails to build when that is disabled: aarch64-linux-ld: sound/soc/fsl/fsl_aud2htx.o: in function `fsl_aud2htx_probe': fsl_aud2htx.c:(.text+0x3e0): undefined reference to `imx_pcm_dma_init' Fixes: 8a24c834c053 ("ASoC: fsl_aud2htx: Add aud2htx module driver") Signed-off-by: Arnd Bergmann Acked-by: Nicolin Chen Link: https://lore.kernel.org/r/20210103135327.3630973-1-arnd@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 05a6578c5f8a46a1a7aa6a05636cc67eb6602054 Author: Dan Carpenter Date: Mon Dec 14 12:54:47 2020 +0100 media: allegro: Fix use after free on error [ Upstream commit ce814ad4bb52bfc7c0472e6da0aa742ab88f4361 ] The "channel" is added to the "dev->channels" but then if v4l2_m2m_ctx_init() fails then we free "channel" but it's still on the list so it could lead to a use after free. Let's not add it to the list until after v4l2_m2m_ctx_init() succeeds. Fixes: cc62c74749a3 ("media: allegro: add missed checks in allegro_open()") Signed-off-by: Dan Carpenter Reviewed-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e290cf88b4c3d208afc2866e1b0590ea1dd7dba5 Author: Christophe JAILLET Date: Sat Dec 19 08:52:07 2020 +0100 hwrng: ingenic - Fix a resource leak in an error handling path [ Upstream commit c4ff41b93d1f10d1b8be258c31a0436c5769fc00 ] In case of error, we should call 'clk_disable_unprepare()' to undo a previous 'clk_prepare_enable()' call, as already done in the remove function. Fixes: 406346d22278 ("hwrng: ingenic - Add hardware TRNG for Ingenic X1830") Signed-off-by: Christophe JAILLET Tested-by: 周琰杰 (Zhou Yanjie) Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cf9244b86ef05af7c32eb776830634d62d3b5b31 Author: Ard Biesheuvel Date: Thu Dec 17 19:55:15 2020 +0100 crypto: arm64/aes-ce - really hide slower algos when faster ones are enabled [ Upstream commit 15deb4333cd6d4e1e3216582e4c531ec40a6b060 ] Commit 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if faster driver is enabled") intended to hide modes from the plain NEON driver that are also implemented by the faster bit sliced NEON one if both are enabled. However, the defined() CPP function does not detect if the bit sliced NEON driver is enabled as a module. So instead, let's use IS_ENABLED() here. Fixes: 69b6f2e817e5b ("crypto: arm64/aes-neon - limit exposed routines if ...") Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ca8eab038953736c8b8989a2c235f9c411eecfbc Author: Corentin Labbe Date: Mon Dec 14 20:02:30 2020 +0000 crypto: sun4i-ss - fix kmap usage [ Upstream commit 9bc3dd24e7dccd50757db743a3635ad5b0497e6e ] With the recent kmap change, some tests which were conditional on CONFIG_DEBUG_HIGHMEM now are enabled by default. This permit to detect a problem in sun4i-ss usage of kmap. sun4i-ss uses two kmap via sg_miter (one for input, one for output), but using two kmap at the same time is hard: "the ordering has to be correct and with sg_miter that's probably hard to get right." (quoting Tlgx) So the easiest solution is to never have two sg_miter/kmap open at the same time. After each use of sg_miter, I store the current index, for being able to resume sg_miter to the right place. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ae2cb3a92706ef15dacc311aeb984a7ba1c5a1d4 Author: Corentin Labbe Date: Mon Dec 14 20:02:25 2020 +0000 crypto: sun4i-ss - linearize buffers content must be kept [ Upstream commit 583513510a7acd2306787865bcd19ebb2f629d42 ] When running the non-optimized cipher function, SS produce partial random output. This is due to linearize buffers being reseted after each loop. For preserving stack, instead of moving them back to start of function, I move them in sun4i_ss_ctx. Fixes: 8d3bcb9900ca ("crypto: sun4i-ss - reduce stack usage") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 52fa9078c2795bf42db82b81ed1b7ef6e0dda42c Author: Linus Walleij Date: Mon Dec 14 23:22:10 2020 +0100 drm/panel: s6e63m0: Support max-brightness [ Upstream commit 1f20bf5921de420071fdb1d55cda7550ae137bcd ] The "max-brightness" is a standard backlight property that we need to support for the Samsung GT-I8190 Golden because the display will go black if we crank up the brightness too high. As the platform needs this ability to give picture this is a regression fix along with the addition of the property to the GT-I8190 device tree. Cc: Stephan Gerhold Fixes: 9c3f0a0dd6a1 ("drm/panel: s6e63m0: Implement 28 backlight levels") Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201214222210.238081-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin commit 49103b3b61ef6c19a428c95794e1b5419787c62f Author: Maxime Ripard Date: Tue Dec 15 16:42:37 2020 +0100 drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check [ Upstream commit 320e84dc6111ecc1c957e2b186d4d2bafee6bde2 ] Commit 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits") was intended to compute the pixel rate to make sure we remain within the boundaries of what the hardware can provide. However, unlike what mode_valid was checking for, we forgot to take into account the clock doubling flag that can be set for modes. Let's honor that flag if it's there. Acked-by: Thomas Zimmermann Reported-by: Thomas Zimmermann Reviewed-by: Dave Stevenson Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits") Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-4-maxime@cerno.tech Signed-off-by: Sasha Levin commit bd67ad100f29afd453570f8f4a8bb87ae55e882b Author: Guido Günther Date: Wed Nov 18 09:29:49 2020 +0100 drm/panel: mantix: Tweak init sequence [ Upstream commit dd396dbc4d7811c1567cc43faa4b9ad68094c44d ] We've seen some (non permanent) burn in and bad white balance on some of the panels. Adding this bit from a vendor supplied sequence fixes it. Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel") Signed-off-by: Guido Günther Reviewed-by: Linus Walleij Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/8451831b60d5ecb73a156613d98218a31bd55680.1605688147.git.agx@sigxcpu.org Signed-off-by: Sasha Levin commit 6c7ab3f15178cf67061e81c9e1ab85c76b97e3b9 Author: Linus Walleij Date: Sat Dec 5 13:22:29 2020 +0100 drm/panel: s6e63m0: Fix init sequence again [ Upstream commit 47b1adc1d2a3b39233a56e183296b335222c9a6d ] The DSI version of the panel behaved instable and close scrutiny of the vendor driver from the Samsung GT-S8190 shows a different initialization sequence for the DSI mode panel than the DPI mode panel. Make the initialization depend on whether we are in DSI or DPI mode and handle the differences. After this the panel on the GT-I8190 becomes much more stable. Also spell out some more custom DCS commands found in the vendor source code to cut down a bit on magic where we can. Fixes: f0aee45ffc8b ("drm/panel: s6e63m0: Fix init sequence") Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg Cc: Stephan Gerhold Link: https://patchwork.freedesktop.org/patch/msgid/20201205122229.1952980-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin commit d8d020f60d142e46aeb79236289ae5f237cee9f9 Author: Chuhong Yuan Date: Thu Dec 3 22:42:48 2020 +0800 drm/fb-helper: Add missed unlocks in setcmap_legacy() [ Upstream commit 0a260e731d6c4c17547ac275a2cde888a9eb4a3d ] setcmap_legacy() does not call drm_modeset_unlock_all() in some exits, add the missed unlocks with goto to fix it. Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths") Signed-off-by: Chuhong Yuan Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201203144248.418281-1-hslester96@gmail.com Signed-off-by: Sasha Levin commit a2c28a54feccd5bae2439b8928b3988d1f0c23db Author: Dan Carpenter Date: Thu Dec 3 11:40:48 2020 +0300 gma500: clean up error handling in init [ Upstream commit 15ccc39b3aab667c6fa131206f01f31bfbccdf6a ] The main problem with this error handling was that it didn't clean up if i2c_add_numbered_adapter() failed. This code is pretty old, and doesn't match with today's checkpatch.pl standards so I took the opportunity to tidy it up a bit. I changed the NULL comparison, and removed the WARNING message if kzalloc() fails and updated the label names. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Signed-off-by: Dan Carpenter Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/X8ikkAqZfnDO2lu6@mwanda Signed-off-by: Sasha Levin commit 487f0b26e06c7a4752d8da8cd8f83044ec8fab82 Author: Simon Ser Date: Mon Nov 30 16:26:12 2020 +0000 drm: document that user-space should force-probe connectors [ Upstream commit a7e2e1c50450c6a0f020b35960edecbe25dde520 ] It seems like we can't have nice things, so let's just document the disappointing behaviour instead. The previous version assumed the kernel would perform the probing work when appropriate, however this is not the case today. Update the documentation to reflect reality. v2: - Improve commit message to explain why this change is made (Pekka) - Keep the bit about flickering (Daniel) - Explain when user-space should force-probe, and when it shouldn't (Daniel) Signed-off-by: Simon Ser Fixes: 2ac5ef3b2362 ("drm: document drm_mode_get_connector") Reviewed-by: Daniel Vetter Reviewed-by: Pekka Paalanen Cc: Ville Syrjala Link: https://patchwork.freedesktop.org/patch/msgid/AxqLnTAsFCRishOVB5CLsqIesmrMrm7oytnOVB7oPA@cp7-web-043.plabs.ch Signed-off-by: Sasha Levin commit 1864f2b5036ddd44ba22213f5ca640699be14c06 Author: Jialin Zhang Date: Mon Nov 30 10:02:16 2020 +0800 drm/gma500: Fix error return code in psb_driver_load() [ Upstream commit 6926872ae24452d4f2176a3ba2dee659497de2c4 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers") Reported-by: Hulk Robot Signed-off-by: Jialin Zhang Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201130020216.1906141-1-zhangjialin11@huawei.com Signed-off-by: Sasha Levin commit 99ff6a6b8d863f4388ac67121f634f81c20490df Author: Randy Dunlap Date: Thu Nov 26 19:17:52 2020 -0800 fbdev: aty: SPARC64 requires FB_ATY_CT [ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ] It looks like SPARC64 requires FB_ATY_CT to build without errors, so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled instead of using "default y if SPARC64 && PCI", which is not strong enough to prevent build errors. As it currently is, FB_ATY_CT can be disabled, resulting in build errors: ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined! ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined! Reviewed-by: Geert Uytterhoeven Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev") Signed-off-by: Randy Dunlap Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Cc: Tomi Valkeinen Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: Daniel Vetter Cc: David Airlie Cc: Bartlomiej Zolnierkiewicz Cc: Geert Uytterhoeven Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 4d97d9ebe73846d18c8e1fd145a602bf8a1995d6 Author: Bjarni Jonasson Date: Tue Feb 16 16:29:44 2021 +0100 net: phy: mscc: coma mode disabled for VSC8514 [ Upstream commit ca0d7fd0a58dfc9503775dae7daee341c115e0c7 ] The 'coma mode' (configurable through sw or hw) provides an optional feature that may be used to control when the PHYs become active. The typical usage is to synchronize the link-up time across all PHY instances. This patch releases coma mode if not done by hardware, otherwise the phys will not link-up. Fixes: e4f9ba642f0b ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by: Steen Hegelund Signed-off-by: Bjarni Jonasson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 72e17930cdd5a03f8ff13883966bf140f15f5d4d Author: Bjarni Jonasson Date: Tue Feb 16 16:29:43 2021 +0100 net: phy: mscc: improved serdes calibration applied to VSC8514 [ Upstream commit 85e97f0b984eb36cba0ecaf87c66a9f7445d73dc ] The current IB serdes calibration algorithm (performed by the onboard 8051) has proven to be unstable for the VSC8514 QSGMII phy. A new algorithm has been developed based on 'Frequency-offset Jittered-Injection' or 'FoJi' method which solves all known issues. This patch disables the 8051 algorithm and replaces it with the new FoJi algorithm. The calibration is now performed in a new file (mscc_serdes.c), which can act as an placeholder for future serdes configurations. Fixes: e4f9ba642f0b ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by: Steen Hegelund Signed-off-by: Bjarni Jonasson Tested-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 371e1442df094a154feeb5a3ad48b42cd063ee84 Author: Alex Elder Date: Mon Feb 15 15:54:34 2021 -0600 net: ipa: initialize all resources [ Upstream commit 25c5a7e89b1de80f4b04ad5365b2e05fefd92279 ] We configure the minimum and maximum number of various types of IPA resources in ipa_resource_config(). It iterates over resource types in the configuration data and assigns resource limits to each resource group for each type. Unfortunately, we are repeatedly initializing the resource data for the first type, rather than initializing each of the types whose limits are specified. Fix this bug. Fixes: 4a0d7579d466e ("net: ipa: avoid going past end of resource group array") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5db88cecfd926aedfb478e962a3df587e7e1273 Author: Dany Madden Date: Fri Feb 12 15:16:30 2021 -0500 ibmvnic: change IBMVNIC_MAX_IND_DESCS to 16 [ Upstream commit a6f2fe5f108c11ff8023d07f9c00cc3c9c3203b8 ] The supported indirect subcrq entries on Power8 is 16. Power9 supports 128. Redefined this value to 16 to minimize the driver from having to reset when migrating between Power9 and Power8. In our rx/tx performance testing, we found no performance difference between 16 and 128 at this time. Fixes: f019fb6392e5 ("ibmvnic: Introduce indirect subordinate Command Response Queue buffer") Signed-off-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c21d8e7d1369a24fcb4eaa47459a8045d2601b8b Author: Maxim Mikityanskiy Date: Wed Feb 10 09:25:28 2021 +0200 net/mlx5e: Fix CQ params of ICOSQ and async ICOSQ [ Upstream commit ebf79b6be67c0a77a9ab7cdf74c43fd7d9619f0c ] The commit mentioned below has split the parameters of ICOSQ and async ICOSQ, but it contained a typo: the CQ parameters were swapped for ICOSQ and async ICOSQ. Async ICOSQ is longer than the normal ICOSQ, and the CQ size must be the same as the size of the corresponding SQ, but due to this bug, the CQ of async ICOSQ was much shorter than async ICOSQ itself. It led to overflows of the CQ with such messages in dmesg, in particular, when running multiple kTLS-offloaded streams: mlx5_core 0000:08:00.0: cq_err_event_notifier:529:(pid 9422): CQ error on CQN 0x406, syndrome 0x1 mlx5_core 0000:08:00.0 eth2: mlx5e_cq_error_event: cqn=0x000406 event=0x04 This commit fixes the issue by using the corresponding parameters for ICOSQ and async ICOSQ. Fixes: c293ac927fbb ("net/mlx5e: Refactor build channel params") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 5b2b4d2e0921981712a579f4bfa1bffa7a1e23c2 Author: Raed Salem Date: Sun Jan 24 22:40:23 2021 +0200 net/mlx5e: Enable striding RQ for Connect-X IPsec capable devices [ Upstream commit e4484d9df5000a18916e0bbcee50828eac8e293e ] This limitation was inherited by previous Innova (FPGA) IPsec implementation, it uses its private set of RQ handlers which does not support striding rq, for Connect-X this is no longer true. Fix by keeping this limitation only for Innova IPsec supporting devices, as otherwise this limitation effectively wrongly blocks striding RQs for all future Connect-X devices for all flows even if IPsec offload is not used. Fixes: 2d64663cd559 ("net/mlx5: IPsec: Add HW crypto offload support") Signed-off-by: Raed Salem Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit f5f3b5800e7aa54341ba6d104caf2543b9a38b37 Author: Parav Pandit Date: Tue Jan 12 16:13:22 2021 +0200 net/mlx5e: E-switch, Fix rate calculation for overflow [ Upstream commit 0e22bfb7c046e7c8ae339f396e78a0976633698c ] rate_bytes_ps is a 64-bit field. It passed as 32-bit field to apply_police_params(). Due to this when police rate is higher than 4Gbps, 32-bit calculation ignores the carry. This results in incorrect rate configurationn the device. Fix it by performing 64-bit calculation. Fixes: fcb64c0f5640 ("net/mlx5: E-Switch, add ingress rate support") Signed-off-by: Parav Pandit Reviewed-by: Eli Cohen Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 38a038fecbd46a2859e05293ab3514ae8e5b4627 Author: Joel Stanley Date: Wed Feb 10 22:16:51 2021 +1030 soc: aspeed: socinfo: Add new systems [ Upstream commit d0e72be77e7995923fac73f27cf7a75d3d1a4dec ] Aspeed's u-boot sdk has been updated with the SoC IDs for the AST2605 variant, as well as A2 and A3 variants of the 2600 family. >From u-boot's arch/arm/mach-aspeed/ast2600/scu_info.c: SOC_ID("AST2600-A0", 0x0500030305000303), SOC_ID("AST2600-A1", 0x0501030305010303), SOC_ID("AST2620-A1", 0x0501020305010203), SOC_ID("AST2600-A2", 0x0502030305010303), SOC_ID("AST2620-A2", 0x0502020305010203), SOC_ID("AST2605-A2", 0x0502010305010103), SOC_ID("AST2600-A3", 0x0503030305030303), SOC_ID("AST2620-A3", 0x0503020305030203), SOC_ID("AST2605-A3", 0x0503010305030103), Fixes: e0218dca5787 ("soc: aspeed: Add soc info driver") Link: https://lore.kernel.org/r/20210210114651.334324-1-joel@jms.id.au Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 0487a33ddf50bdc81f1209f509fa7023b430b619 Author: Venkata Lakshmi Narayana Gubba Date: Fri Feb 5 21:07:16 2021 +0530 Bluetooth: hci_qca: Fixed issue during suspend [ Upstream commit 55c0bd77479b60ea29fd390faf4545cfb3a1d79e ] If BT SoC is running with ROM FW then just return in qca_suspend function as ROM FW does not support in-band sleep. Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend") Signed-off-by: Venkata Lakshmi Narayana Gubba Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit b9244c7f9eba250b56e26dea950a3c726fdd2b61 Author: Venkata Lakshmi Narayana Gubba Date: Tue Feb 2 20:27:42 2021 +0530 Bluetooth: hci_qca: check for SSR triggered flag while suspend [ Upstream commit 1bb0c66332babc5cbc4581d962da0b03af9f23e8 ] QCA_IBS_DISABLED flag will be set after memorydump started from controller.Currently qca_suspend() is waiting for SSR to complete based on flag QCA_IBS_DISABLED.Added to check for QCA_SSR_TRIGGERED flag too. Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend") Signed-off-by: Venkata Lakshmi Narayana Gubba Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 78bd77824d67f94466ef9b032b734ffbff110995 Author: Matthias Brugger Date: Sun Jan 31 11:17:26 2021 +0100 arm64: dts: mt8183: Fix GCE include path [ Upstream commit 18d6e3f6744d6105ab61de790170cb60534eeebc ] The header file of GCE should be for MT8183 SoC instead of MT8173. Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183") Reported-by: CK Hu Signed-off-by: Matthias Brugger Reviewed-by: Chun-Kuang Hu Link: https://lore.kernel.org/r/20210131101726.804-1-matthias.bgg@kernel.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit fe38fc32c41b2be391d57aa32ef7ec88b60f84d5 Author: Peter Geis Date: Thu Jan 7 16:56:59 2021 +0000 ARM: tegra: ouya: Fix eMMC on specific bootloaders [ Upstream commit 3029a563ac0ccd39b9dc53eadfb9c0e3fb57a449 ] Ouya fails to detect the eMMC module when booted via certain bootloaders. Fastboot and hard-kexec bootloaders fail while u-boot does not. It was discovered that the issue manifests if the sdmmc4 alternate configuration clock pin is input disabled. Ouya uses sdmmc4 in the primary pin configuration. It is unknown why this occurs, though it is likely related to other eMMC limitations experienced on Ouya. For now, fix it by enabling input on cam_mclk_pcc0. Fixes: d7195ac5c9c5 ("ARM: tegra: Add device-tree for Ouya") Reported-by: Matt Merhar Tested-by: Matt Merhar Signed-off-by: Peter Geis Acked-by: Thierry Reding Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit fb2436e247b656326b8c24a0fa28cbe043d73296 Author: Pali Rohár Date: Mon Jan 25 16:02:27 2021 +0100 net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips [ Upstream commit 426c6cbc409cbda9ab1a9dbf15d3c2ef947eb8c1 ] The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King Signed-off-by: Russell King Signed-off-by: Pali Rohár Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e6c45085c0c00ed135d191f16ca28c9ada9231d3 Author: Enric Balletbo i Serra Date: Wed Jan 13 22:57:23 2021 +0100 arm64: dts: mt8183: Add missing power-domain for pwm0 node [ Upstream commit 2f99fb6e46b0e982bb6ab18b24a08fa318f740ea ] The MT8183 display PWM device will not work until the associated power-domain is enabled. Add the power-domain reference to the node allows the display PWM driver to operate and the backlight turn on. Fixes: f15722c0fef0 ("arm64: dts: mt8183: Add pwm and backlight node") Signed-off-by: Enric Balletbo i Serra Reviewed-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20210113215723.71966-1-enric.balletbo@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit fe4a4ab0dfeaf91a4b887c4bab527516baef62ce Author: Yongqiang Niu Date: Thu Jan 28 19:23:08 2021 +0800 arm64: dts: mt8183: refine gamma compatible name [ Upstream commit 9a2cb5eba7ad4fa7ccb3a4aa754f5263111e8f96 ] mt8183 gamma is different with mt8173 remove mt8173 compatible name for mt8183 gamma Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183") Signed-off-by: Yongqiang Niu Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20210128112314.1304160-3-hsinyi@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit a3fc70eb23dbe713a7e277e04b5b7c52446e2fa3 Author: Yongqiang Niu Date: Thu Jan 28 19:23:07 2021 +0800 arm64: dts: mt8183: rename rdma fifo size [ Upstream commit 431368c2648b59e5485a1b5f1276a83d885fb44b ] property name must include only lowercase and '-' Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183") Signed-off-by: Yongqiang Niu Signed-off-by: Hsin-Yi Wang Reviewed-by: Chun-Kuang Hu Reviewed-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20210128112314.1304160-2-hsinyi@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 67cac1827aa8b30293de9c03d73e74c3ecd81410 Author: Andrii Nakryiko Date: Mon Jan 25 22:50:18 2021 -0800 selftests/bpf: Don't exit on failed bpf_testmod unload [ Upstream commit 86ce322d21eb032ed8fdd294d0fb095d2debb430 ] Fix bug in handling bpf_testmod unloading that will cause test_progs exiting prematurely if bpf_testmod unloading failed. This is especially problematic when running a subset of test_progs that doesn't require root permissions and doesn't rely on bpf_testmod, yet will fail immediately due to exit(1) in unload_bpf_testmod(). Fixes: 9f7fa225894c ("selftests/bpf: Add bpf_testmod kernel module for testing") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210126065019.1268027-1-andrii@kernel.org Signed-off-by: Sasha Levin commit 0e0389b78cdfe15dda4c98ae166764da537ef1ca Author: Sami Tolvanen Date: Wed Jan 13 15:23:11 2021 -0800 x86/sgx: Fix the return type of sgx_init() [ Upstream commit 31bf92881714fe9962d43d097b5114a9b4ad0a12 ] device_initcall() expects a function of type initcall_t, which returns an integer. Change the signature of sgx_init() to match. Fixes: e7e0545299d8c ("x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections") Signed-off-by: Sami Tolvanen Signed-off-by: Borislav Petkov Reviewed-by: Darren Kenny Reviewed-by: Jarkko Sakkinen Link: https://lkml.kernel.org/r/20210113232311.277302-1-samitolvanen@google.com Signed-off-by: Sasha Levin commit 3752f11db175b94cf63e95f4f92d8a93e4aedb23 Author: Linus Torvalds Date: Tue Jan 19 10:49:19 2021 -0800 tty: implement read_iter [ Upstream commit dd78b0c483e33225e0e0782b0ed887129b00f956 ] Now that the ldisc read() function takes kernel pointers, it's fairly straightforward to make the tty file operations use .read_iter() instead of .read(). That automatically gives us vread() and friends, and also makes it possible to do .splice_read() on ttys again. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Reported-by: Oliver Giles Cc: Christoph Hellwig Cc: Greg Kroah-Hartman Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c075867d710865fe579d0f5b03392149a832596a Author: Linus Torvalds Date: Mon Jan 18 13:31:30 2021 -0800 tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer [ Upstream commit 3b830a9c34d5897be07176ce4e6f2d75e2c8cfd7 ] The tty line discipline .read() function was passed the final user pointer destination as an argument, which doesn't match the 'write()' function, and makes it very inconvenient to do a splice method for ttys. This is a conversion to use a kernel buffer instead. NOTE! It does this by passing the tty line discipline ->read() function an additional "cookie" to fill in, and an offset into the cookie data. The line discipline can fill in the cookie data with its own private information, and then the reader will repeat the read until either the cookie is cleared or it runs out of data. The only real user of this is N_HDLC, which can use this to handle big packets, even if the kernel buffer is smaller than the whole packet. Cc: Christoph Hellwig Cc: Greg Kroah-Hartman Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 02ef0a78d520014d67eec51a21a0f04d9097c995 Author: Dmitry Baryshkov Date: Thu Dec 17 21:33:41 2020 +0300 arm64: dts: qcom: qrb5165-rb5: fix uSD pins drive strength [ Upstream commit abf2c58aaa776cf43daf0fc4fd20082c71583c6b ] Lower drive strength for microSD data and CMD pins from 16 to 10. This fixes spurious card removal issues observed on some boards. Also this change allows us to re-enable 1.8V support, which seems to work with lowered drive strength. Signed-off-by: Dmitry Baryshkov Cc: Veerabhadrarao Badiganti Fixes: 53a8ccf1c7e5 ("arm64: dts: qcom: rb5: Add support for uSD card") Link: https://lore.kernel.org/r/20201217183341.3186402-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 596ab96935d20d1908d5cf90cde21e66fb0ec994 Author: Dmitry Baryshkov Date: Sat Jan 9 04:12:52 2021 +0300 arm64: dts: qcom: sm8250: correct sdhc_2 xo clk [ Upstream commit 74097d805edb9305a2a588a8ece82d2495ff5a88 ] sdhc_2 uses 19200000 Hz clock rather than wrongly specified xo_board (39400000 Hz). Specify correct clock to fix DLL setup for SDR104 mode. Signed-off-by: Dmitry Baryshkov Fixes: c4cf0300be84 ("arm64: dts: qcom: sm8250: Add support for SDC2") Link: https://lore.kernel.org/r/20210109011252.3436533-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fde1ac11120d71f3193e116bc6437be139338639 Author: Andrii Nakryiko Date: Mon Jan 11 23:55:17 2021 -0800 selftests/bpf: Sync RCU before unloading bpf_testmod [ Upstream commit 635599bace259a2c42741c3ea61bfa7be6f15556 ] If some of the subtests use module BTFs through ksyms, they will cause bpf_prog to take a refcount on bpf_testmod module, which will prevent it from successfully unloading. Module's refcnt is decremented when bpf_prog is freed, which generally happens in RCU callback. So we need to trigger syncronize_rcu() in the kernel, which can be achieved nicely with membarrier(MEMBARRIER_CMD_SHARED) or membarrier(MEMBARRIER_CMD_GLOBAL) syscall. So do that in kernel_sync_rcu() and make it available to other test inside the test_progs. This synchronize_rcu() is called before attempting to unload bpf_testmod. Fixes: 9f7fa225894c ("selftests/bpf: Add bpf_testmod kernel module for testing") Suggested-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Acked-by: Hao Luo Link: https://lore.kernel.org/bpf/20210112075520.4103414-5-andrii@kernel.org Signed-off-by: Sasha Levin commit f644edfeff384645b7a40f36658caaeda2fc9ccd Author: Andrii Nakryiko Date: Mon Jan 11 23:55:16 2021 -0800 bpf: Declare __bpf_free_used_maps() unconditionally [ Upstream commit 936f8946bdb48239f4292812d4d2e26c6d328c95 ] __bpf_free_used_maps() is always defined in kernel/bpf/core.c, while include/linux/bpf.h is guarding it behind CONFIG_BPF_SYSCALL. Move it out of that guard region and fix compiler warning. Fixes: a2ea07465c8d ("bpf: Fix missing prog untrack in release_maps") Reported-by: kernel test robot Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210112075520.4103414-4-andrii@kernel.org Signed-off-by: Sasha Levin commit 12191279d343f1b1555264882660995869f089a4 Author: Erwan Le Ray Date: Wed Jan 6 17:21:56 2021 +0100 serial: stm32: fix DMA initialization error handling [ Upstream commit e7997f7ff7f8154d477f6f976698d868a2ac3934 ] DMA initialization error handling is not properly implemented in the driver. Fix DMA initialization error handling by: - moving TX DMA descriptor request error handling in a new dedicated fallback_err label - adding error handling to TX DMA descriptor submission - adding error handling to RX DMA descriptor submission This patch depends on '24832ca3ee85 ("tty: serial: stm32-usart: Remove set but unused 'cookie' variables")' which unfortunately doesn't include a "Fixes" tag. Fixes: 3489187204eb ("serial: stm32: adding dma support") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210106162203.28854-2-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d157410b6cce1b24a19edf5f205d30097c83da33 Author: Venkata Lakshmi Narayana Gubba Date: Wed Dec 30 22:47:08 2020 +0530 Bluetooth: hci_qca: Wait for SSR completion during suspend [ Upstream commit ad3a9c0ec2d2baed936cfdd05870f9d1e1f40e0e ] During SSR after memory dump collection,BT controller will be powered off, powered on and then FW will be downloaded.During suspend if BT controller is powered off due to SSR then we should wait until SSR is completed and then suspend. Fixes: 2be43abac5a8 ("Bluetooth: hci_qca: Wait for timeout during suspend") Signed-off-by: Venkata Lakshmi Narayana Gubba Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 27f8ad85e2739c998573b659644b800f074f92a0 Author: Rafał Miłecki Date: Tue Dec 8 11:49:50 2020 +0100 arm64: dts: broadcom: bcm4908: use proper NAND binding [ Upstream commit 56098be85d19cd56b59d7b3854ea035cc8cb9e95 ] BCM4908 has controller that needs different IRQ handling just like the BCM63138. Describe it properly. On Linux this change fixes: brcmstb_nand ff801800.nand: timeout waiting for command 0x9 brcmstb_nand ff801800.nand: intfc status d0000000 Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 2d6765feeac067b872de1062ad096d815b61ccf3 Author: Abhishek Pandit-Subedi Date: Mon Dec 7 16:12:54 2020 -0800 Bluetooth: Remove hci_req_le_suspend_config [ Upstream commit 295fa2a5647b13681594bb1bcc76c74619035218 ] Add a missing SUSPEND_SCAN_ENABLE in passive scan, remove the separate function for configuring le scan during suspend and update the request complete function to clear both enable and disable tasks. Fixes: dce0a4be8054 ("Bluetooth: Set missing suspend task bits") Reviewed-by: Alain Michaud Signed-off-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 4a3e64550b19b13fc23d7fa2e519b9554a2b4eb0 Author: Vladimir Oltean Date: Tue Feb 16 12:16:28 2021 +0200 net: enetc: fix destroyed phylink dereference during unbind [ Upstream commit 3af409ca278d4a8d50e91f9f7c4c33b175645cf3 ] The following call path suggests that calling unregister_netdev on an interface that is up will first bring it down. enetc_pf_remove -> unregister_netdev -> unregister_netdevice_queue -> unregister_netdevice_many -> dev_close_many -> __dev_close_many -> enetc_close -> enetc_stop -> phylink_stop However, enetc first destroys the phylink instance, then calls unregister_netdev. This is already dissimilar to the setup (and error path teardown path) from enetc_pf_probe, but more than that, it is buggy because it is invalid to call phylink_stop after phylink_destroy. So let's first unregister the netdev (and let the .ndo_stop events consume themselves), then destroy the phylink instance, then free the netdev. Fixes: 71b77a7a27a3 ("enetc: Migrate to PHYLINK and PCS_LYNX") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit badce8f2bc13e5e466ae2c040fbeeb89578154dc Author: Maxime Chevallier Date: Tue Feb 16 10:25:35 2021 +0100 net: mvneta: Remove per-cpu queue mapping for Armada 3700 [ Upstream commit cf9bf871280d9e0a8869d98c2602d29caf69dfa3 ] According to Errata #23 "The per-CPU GbE interrupt is limited to Core 0", we can't use the per-cpu interrupt mechanism on the Armada 3700 familly. This is correctly checked for RSS configuration, but the initial queue mapping is still done by having the queues spread across all the CPUs in the system, both in the init path and in the cpu_hotplug path. Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700 SoC") Signed-off-by: Maxime Chevallier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f32a524c844d69664af13e304a4d09ec416ee801 Author: Shyam Sundar S K Date: Wed Feb 17 00:37:10 2021 +0530 net: amd-xgbe: Fix network fluctuations when using 1G BELFUSE SFP [ Upstream commit 9eab3fdb419916f66a72d1572f68d82cd9b3f963 ] Frequent link up/down events can happen when a Bel Fuse SFP part is connected to the amd-xgbe device. Try to avoid the frequent link issues by resetting the PHY as documented in Bel Fuse SFP datasheets. Fixes: e722ec82374b ("amd-xgbe: Update the BelFuse quirk to support SGMII") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 50b63f194efa1a66583d20470a50704d6db95a95 Author: Shyam Sundar S K Date: Wed Feb 17 00:37:09 2021 +0530 net: amd-xgbe: Reset link when the link never comes back [ Upstream commit 84fe68eb67f9499309cffd97c1ba269de125ff14 ] Normally, auto negotiation and reconnect should be automatically done by the hardware. But there seems to be an issue where auto negotiation has to be restarted manually. This happens because of link training and so even though still connected to the partner the link never "comes back". This needs an auto-negotiation restart. Also, a change in xgbe-mdio is needed to get ethtool to recognize the link down and get the link change message. This change is only required in a backplane connection mode. Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7e78073feb53cf3d446e3274a108eeb6df5f4af7 Author: Shyam Sundar S K Date: Wed Feb 17 00:37:08 2021 +0530 net: amd-xgbe: Fix NETDEV WATCHDOG transmit queue timeout warning [ Upstream commit 186edbb510bd60e748f93975989ccba25ee99c50 ] The current driver calls netif_carrier_off() late in the link tear down which can result in a netdev watchdog timeout. Calling netif_carrier_off() immediately after netif_tx_stop_all_queues() avoids the warning. ------------[ cut here ]------------ NETDEV WATCHDOG: enp3s0f2 (amd-xgbe): transmit queue 0 timed out WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x20d/0x220 Modules linked in: amd_xgbe(E) amd-xgbe 0000:03:00.2 enp3s0f2: Link is Down CPU: 3 PID: 0 Comm: swapper/3 Tainted: G E Hardware name: AMD Bilby-RV2/Bilby-RV2, BIOS RBB1202A 10/18/2019 RIP: 0010:dev_watchdog+0x20d/0x220 Code: 00 49 63 4e e0 eb 92 4c 89 e7 c6 05 c6 e2 c1 00 01 e8 e7 ce fc ff 89 d9 48 RSP: 0018:ffff90cfc28c3e88 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff90cfc28d63c0 RBP: ffff90cfb977845c R08: 0000000000000050 R09: 0000000000196018 R10: ffff90cfc28c3ef8 R11: 0000000000000000 R12: ffff90cfb9778000 R13: 0000000000000003 R14: ffff90cfb9778480 R15: 0000000000000010 FS: 0000000000000000(0000) GS:ffff90cfc28c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f240ff2d9d0 CR3: 00000001e3e0a000 CR4: 00000000003406e0 Call Trace: ? pfifo_fast_reset+0x100/0x100 call_timer_fn+0x2b/0x130 run_timer_softirq+0x3e8/0x440 ? enqueue_hrtimer+0x39/0x90 Fixes: e722ec82374b ("amd-xgbe: Update the BelFuse quirk to support SGMII") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c823a434b70b6b8190d1fbb5ace4ed15f075db3f Author: Shyam Sundar S K Date: Wed Feb 17 00:37:07 2021 +0530 net: amd-xgbe: Reset the PHY rx data path when mailbox command timeout [ Upstream commit 30b7edc82ec82578f4f5e6706766f0a9535617d3 ] Sometimes mailbox commands timeout when the RX data path becomes unresponsive. This prevents the submission of new mailbox commands to DXIO. This patch identifies the timeout and resets the RX data path so that the next message can be submitted properly. Fixes: 549b32af9f7c ("amd-xgbe: Simplify mailbox interface rate change code") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 486f5e4d9d33f14d11b4e3446819091a9e1a39ed Author: Bjarni Jonasson Date: Tue Feb 16 16:29:42 2021 +0100 net: phy: mscc: adding LCPLL reset to VSC8514 [ Upstream commit 3cc2c646be0b22037f31c958e96c0544a073d108 ] At Power-On Reset, transients may cause the LCPLL to lock onto a clock that is momentarily unstable. This is normally seen in QSGMII setups where the higher speed 6G SerDes is being used. This patch adds an initial LCPLL Reset to the PHY (first instance) to avoid this issue. Fixes: e4f9ba642f0b ("net: phy: mscc: add support for VSC8514 PHY.") Signed-off-by: Steen Hegelund Signed-off-by: Bjarni Jonasson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f984701ca13a213c5ab7023833a81909679d4499 Author: Vladimir Oltean Date: Tue Feb 16 13:14:46 2021 +0200 net: dsa: felix: don't deinitialize unused ports [ Upstream commit 42b5adbbac03bdb396192316c015fa3e64ffd5a1 ] ocelot_init_port is called only if dsa_is_unused_port == false, however ocelot_deinit_port is called unconditionally. This causes a warning in the skb_queue_purge inside ocelot_deinit_port saying that the spin lock protecting ocelot_port->tx_skbs was not initialized. Fixes: e5fb512d81d0 ("net: mscc: ocelot: deinitialize only initialized ports") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1bfa72d34487caec2882ff7eeef0558e8ba2803a Author: Vladimir Oltean Date: Fri Jan 15 04:11:15 2021 +0200 net: dsa: felix: perform teardown in reverse order of setup [ Upstream commit d19741b0f54487cf3a11307900f8633935cd2849 ] In general it is desirable that cleanup is the reverse process of setup. In this case I am not seeing any particular issue, but with the introduction of devlink-sb for felix, a non-obvious decision had to be made as to where to put its cleanup method. When there's a convention in place, that decision becomes obvious. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d052b2e6a933dc22e59ee074ca6abd2ef2377250 Author: Sukadev Bhattiprolu Date: Fri Feb 12 20:42:50 2021 -0800 ibmvnic: serialize access to work queue on remove [ Upstream commit 4a41c421f3676fdeea91733cf434dcf319c4c351 ] The work queue is used to queue reset requests like CHANGE-PARAM or FAILOVER resets for the worker thread. When the adapter is being removed the adapter state is set to VNIC_REMOVING and the work queue is flushed so no new work is added. However the check for adapter being removed is racy in that the adapter can go into REMOVING state just after we check and we might end up adding work just as it is being flushed (or after). The ->rwi_lock is already being used to serialize queue/dequeue work. Extend its usage ensure there is no race when scheduling/flushing work. Fixes: 6954a9e4192b ("ibmvnic: Flush existing work items before device removal") Signed-off-by: Sukadev Bhattiprolu Cc:Uwe Kleine-König Cc:Saeed Mahameed Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8db126a7729914fd03d805078ae5592acca8999d Author: Lijun Pan Date: Fri Feb 12 20:49:00 2021 -0600 ibmvnic: skip send_request_unmap for timeout reset [ Upstream commit 7d3a7b9ea59ddb223aec59b45fa1713c633aaed4 ] Timeout reset will trigger the VIOS to unmap it automatically, similarly as FAILVOER and MOBILITY events. If we unmap it in the linux side, we will see errors like "30000003: Error 4 in REQUEST_UNMAP_RSP". So, don't call send_request_unmap for timeout reset. Fixes: ed651a10875f ("ibmvnic: Updated reset handling") Signed-off-by: Lijun Pan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d3ad096158c3bce3c3a11dc5dfa118cf407bfd34 Author: Lijun Pan Date: Fri Feb 12 20:48:40 2021 -0600 ibmvnic: add memory barrier to protect long term buffer [ Upstream commit 42557dab78edc8235aba5b441f2eb35f725a0ede ] dma_rmb() barrier is added to load the long term buffer before copying it to socket buffer; and dma_wmb() barrier is added to update the long term buffer before it being accessed by VIOS (virtual i/o server). Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Lijun Pan Acked-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c5fdd4de87dcd827cf82f808d5fc3726c1acaae Author: Ilya Leoshkevich Date: Fri Feb 12 05:04:08 2021 +0100 bpf: Clear subreg_def for global function return values [ Upstream commit 45159b27637b0fef6d5ddb86fc7c46b13c77960f ] test_global_func4 fails on s390 as reported by Yauheni in [1]. The immediate problem is that the zext code includes the instruction, whose result needs to be zero-extended, into the zero-extension patchlet, and if this instruction happens to be a branch, then its delta is not adjusted. As a result, the verifier rejects the program later. However, according to [2], as far as the verifier's algorithm is concerned and as specified by the insn_no_def() function, branching insns do not define anything. This includes call insns, even though one might argue that they define %r0. This means that the real problem is that zero extension kicks in at all. This happens because clear_caller_saved_regs() sets BPF_REG_0's subreg_def after global function calls. This can be fixed in many ways; this patch mimics what helper function call handling already does. [1] https://lore.kernel.org/bpf/20200903140542.156624-1-yauheni.kaliuta@redhat.com/ [2] https://lore.kernel.org/bpf/CAADnVQ+2RPKcftZw8d+B1UwB35cpBhpF5u3OocNh90D9pETPwg@mail.gmail.com/ Fixes: 51c39bb1d5d1 ("bpf: Introduce function-by-function verification") Reported-by: Yauheni Kaliuta Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210212040408.90109-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 864f6c3a6e74333c9cd9a8731e91b96cbe49957b Author: Colin Ian King Date: Mon Feb 15 12:05:32 2021 +0000 b43: N-PHY: Fix the update of coef for the PHY revision >= 3case [ Upstream commit 4773acf3d4b50768bf08e9e97a204819e9ea0895 ] The documentation for the PHY update [1] states: Loop 4 times with index i If PHY Revision >= 3 Copy table[i] to coef[i] Otherwise Set coef[i] to 0 the copy of the table to coef is currently implemented the wrong way around, table is being updated from uninitialized values in coeff. Fix this by swapping the assignment around. [1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/ Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration") Addresses-Coverity: ("Uninitialized scalar variable") Signed-off-by: Colin Ian King Acked-by: Larry Finger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7800c06a0394636fa6e2ea38c6c64d101b391b64 Author: Ayush Sawal Date: Mon Feb 15 17:12:26 2021 +0530 cxgb4/chtls/cxgbit: Keeping the max ofld immediate data size same in cxgb4 and ulds [ Upstream commit 2355a6773a2cb0d2dce13432dde78497f1d6617b ] The Max imm data size in cxgb4 is not similar to the max imm data size in the chtls. This caused an mismatch in output of is_ofld_imm() of cxgb4 and chtls. So fixed this by keeping the max wreq size of imm data same in both chtls and cxgb4 as MAX_IMM_OFLD_TX_DATA_WR_LEN. As cxgb4's max imm. data value for ofld packets is changed to MAX_IMM_OFLD_TX_DATA_WR_LEN. Using the same in cxgbit also. Fixes: 36bedb3f2e5b8 ("crypto: chtls - Inline TLS record Tx") Signed-off-by: Ayush Sawal Acked-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 77371ababba81ce7039dfcce02942a3b8541e066 Author: Robert Hancock Date: Fri Feb 12 18:17:48 2021 -0600 net: axienet: Handle deferred probe on clock properly [ Upstream commit 57baf8cc70ea4cf5503c9d42f31f6a86d7f5ff1a ] This driver is set up to use a clock mapping in the device tree if it is present, but still work without one for backward compatibility. However, if getting the clock returns -EPROBE_DEFER, then we need to abort and return that error from our driver initialization so that the probe can be retried later after the clock is set up. Move clock initialization to earlier in the process so we do not waste as much effort if the clock is not yet available. Switch to use devm_clk_get_optional and abort initialization on any error reported. Also enable the clock regardless of whether the controller is using an MDIO bus, as the clock is required in any case. Fixes: 09a0354cadec267be7f ("net: axienet: Use clock framework to get device clock rate") Signed-off-by: Robert Hancock Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ca90ff61d52267f6df337900ff2c4fa925fca56b Author: Eric Dumazet Date: Fri Feb 12 15:22:13 2021 -0800 tcp: fix SO_RCVLOWAT related hangs under mem pressure [ Upstream commit f969dc5a885736842c3511ecdea240fbb02d25d9 ] While commit 24adbc1676af ("tcp: fix SO_RCVLOWAT hangs with fat skbs") fixed an issue vs too small sk_rcvbuf for given sk_rcvlowat constraint, it missed to address issue caused by memory pressure. 1) If we are under memory pressure and socket receive queue is empty. First incoming packet is allowed to be queued, after commit 76dfa6082032 ("tcp: allow one skb to be received per socket under memory pressure") But we do not send EPOLLIN yet, in case tcp_data_ready() sees sk_rcvlowat is bigger than skb length. 2) Then, when next packet comes, it is dropped, and we directly call sk->sk_data_ready(). 3) If application is using poll(), tcp_poll() will then use tcp_stream_is_readable() and decide the socket receive queue is not yet filled, so nothing will happen. Even when sender retransmits packets, phases 2) & 3) repeat and flow is effectively frozen, until memory pressure is off. Fix is to consider tcp_under_memory_pressure() to take care of global memory pressure or memcg pressure. Fixes: 24adbc1676af ("tcp: fix SO_RCVLOWAT hangs with fat skbs") Signed-off-by: Eric Dumazet Reported-by: Arjun Roy Suggested-by: Wei Wang Reviewed-by: Wei Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e837d00276d50e2c89d5afa605af795191b95c7 Author: Matthieu Baerts Date: Fri Feb 12 15:20:28 2021 -0800 selftests: mptcp: fix ACKRX debug message [ Upstream commit f384221a381751508f390b36d0e51bd5a7beb627 ] Info from received MPCapable SYN were printed instead of the ones from received MPCapable 3rd ACK. Fixes: fed61c4b584c ("selftests: mptcp: make 2nd net namespace use tcp syn cookies unconditionally") Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f8d5d68b66fdd83246fb14499dee7abab7ddeef Author: Jesper Dangaard Brouer Date: Tue Feb 9 14:38:14 2021 +0100 bpf: Fix bpf_fib_lookup helper MTU check for SKB ctx [ Upstream commit 2c0a10af688c02adcf127aad29e923e0056c6b69 ] BPF end-user on Cilium slack-channel (Carlo Carraro) wants to use bpf_fib_lookup for doing MTU-check, but *prior* to extending packet size, by adjusting fib_params 'tot_len' with the packet length plus the expected encap size. (Just like the bpf_check_mtu helper supports). He discovered that for SKB ctx the param->tot_len was not used, instead skb->len was used (via MTU check in is_skb_forwardable() that checks against netdev MTU). Fix this by using fib_params 'tot_len' for MTU check. If not provided (e.g. zero) then keep existing TC behaviour intact. Notice that 'tot_len' for MTU check is done like XDP code-path, which checks against FIB-dst MTU. V16: - Revert V13 optimization, 2nd lookup is against egress/resulting netdev V13: - Only do ifindex lookup one time, calling dev_get_by_index_rcu(). V10: - Use same method as XDP for 'tot_len' MTU check Fixes: 4c79579b44b1 ("bpf: Change bpf_fib_lookup to return lookup status") Reported-by: Carlo Carraro Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/161287789444.790810.15247494756551413508.stgit@firesoul Signed-off-by: Sasha Levin commit 7aaa11d8dd0c1cd8d4be21bc786c4e39c226ec1f Author: Jun'ichi Nomura Date: Tue Feb 9 08:24:52 2021 +0000 bpf, devmap: Use GFP_KERNEL for xdp bulk queue allocation [ Upstream commit 7d4553b69fb335496c597c31590e982485ebe071 ] The devmap bulk queue is allocated with GFP_ATOMIC and the allocation may fail if there is no available space in existing percpu pool. Since commit 75ccae62cb8d42 ("xdp: Move devmap bulk queue into struct net_device") moved the bulk queue allocation to NETDEV_REGISTER callback, whose context is allowed to sleep, use GFP_KERNEL instead of GFP_ATOMIC to let percpu allocator extend the pool when needed and avoid possible failure of netdev registration. As the required alignment is natural, we can simply use alloc_percpu(). Fixes: 75ccae62cb8d42 ("xdp: Move devmap bulk queue into struct net_device") Signed-off-by: Jun'ichi Nomura Signed-off-by: Daniel Borkmann Cc: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20210209082451.GA44021@jeru.linux.bs1.fc.nec.co.jp Signed-off-by: Sasha Levin commit 9e684f7fceed9267b37c2bb5cc379eff453fdac6 Author: Yonghong Song Date: Thu Feb 11 16:59:26 2021 -0800 bpf: Fix an unitialized value in bpf_iter [ Upstream commit 17d8beda277a36203585943e70c7909b60775fd5 ] Commit 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") cached btf_id in struct bpf_iter_target_info so later on if it can be checked cheaply compared to checking registered names. syzbot found a bug that uninitialized value may occur to bpf_iter_target_info->btf_id. This is because we allocated bpf_iter_target_info structure with kmalloc and never initialized field btf_id afterwards. This uninitialized btf_id is typically compared to a u32 bpf program func proto btf_id, and the chance of being equal is extremely slim. This patch fixed the issue by using kzalloc which will also prevent future likely instances due to adding new fields. Fixes: 15d83c4d7cef ("bpf: Allow loading of a bpf_iter program") Reported-by: syzbot+580f4f2a272e452d55cb@syzkaller.appspotmail.com Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210212005926.2875002-1-yhs@fb.com Signed-off-by: Sasha Levin commit 703df6ba87c94a4b856c791a06d0daa06ec90cda Author: Martin KaFai Lau Date: Thu Feb 11 18:10:30 2021 -0800 libbpf: Ignore non function pointer member in struct_ops [ Upstream commit d2836dddc95d5dd82c7cb23726c97d8c9147f050 ] When libbpf initializes the kernel's struct_ops in "bpf_map__init_kern_struct_ops()", it enforces all pointer types must be a function pointer and rejects others. It turns out to be too strict. For example, when directly using "struct tcp_congestion_ops" from vmlinux.h, it has a "struct module *owner" member and it is set to NULL in a bpf_tcp_cc.o. Instead, it only needs to ensure the member is a function pointer if it has been set (relocated) to a bpf-prog. This patch moves the "btf_is_func_proto(kern_mtype)" check after the existing "if (!prog) { continue; }". The original debug message in "if (!prog) { continue; }" is also removed since it is no longer valid. Beside, there is a later debug message to tell which function pointer is set. The "btf_is_func_proto(mtype)" has already been guaranteed in "bpf_object__collect_st_ops_relos()" which has been run before "bpf_map__init_kern_struct_ops()". Thus, this check is removed. v2: - Remove outdated debug message (Andrii) Remove because there is a later debug message to tell which function pointer is set. - Following mtype->type is no longer needed. Remove: "skip_mods_and_typedefs(btf, mtype->type, &mtype_id)" - Do "if (!prog)" test before skip_mods_and_typedefs. Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210212021030.266932-1-kafai@fb.com Signed-off-by: Sasha Levin commit 70efd8b52f97b98026a47931ee2112b23e105e3e Author: Colin Ian King Date: Fri Feb 5 17:53:52 2021 +0000 mac80211: fix potential overflow when multiplying to u32 integers [ Upstream commit 6194f7e6473be78acdc5d03edd116944bdbb2c4e ] The multiplication of the u32 variables tx_time and estimated_retx is performed using a 32 bit multiplication and the result is stored in a u64 result. This has a potential u32 overflow issue, so avoid this by casting tx_time to a u64 to force a 64 bit multiply. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210205175352.208841-1-colin.king@canonical.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b825dd951397411505e96bb3882ac9599766658f Author: Moshe Shemesh Date: Tue Jan 26 16:46:11 2021 +0200 net/mlx5e: Check tunnel offload is required before setting SWP [ Upstream commit e1c3940c6003d820c787473c65711b49c2d1bc42 ] Check that tunnel offload is required before setting Software Parser offsets to get Geneve HW offload. In case of Geneve packet we check HW offload support of SWP in mlx5e_tunnel_features_check() and set features accordingly, this should be reflected in skb offload requested by the kernel and we should add the Software Parser offsets only if requested. Otherwise, in case HW doesn't support SWP for Geneve, data path will mistakenly try to offload Geneve SKBs with skb->encapsulation set, regardless of whether offload was requested or not on this specific SKB. Fixes: e3cfc7e6b7bd ("net/mlx5e: TX, Add geneve tunnel stateless offload support") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 8e4bcfd8d8b74cbfeaca4c3e12dc73d4c2d678e7 Author: Oz Shlomo Date: Tue Jan 12 12:37:37 2021 +0000 net/mlx5e: CT: manage the lifetime of the ct entry object [ Upstream commit a2173131526dc845eb1968a15bc192b3fc2ff000 ] The ct entry object is accessed by the ct add, del, stats and restore methods. In addition, it is referenced from several hash tables. The lifetime of the ct entry object was not managed which triggered race conditions as in the following kasan dump: [ 3374.973945] ================================================================== [ 3374.988552] BUG: KASAN: use-after-free in memcmp+0x4c/0x98 [ 3374.999590] Read of size 1 at addr ffff00036129ea55 by task ksoftirqd/1/15 [ 3375.016415] CPU: 1 PID: 15 Comm: ksoftirqd/1 Tainted: G O 5.4.31+ #1 [ 3375.055301] Call trace: [ 3375.060214] dump_backtrace+0x0/0x238 [ 3375.067580] show_stack+0x24/0x30 [ 3375.074244] dump_stack+0xe0/0x118 [ 3375.081085] print_address_description.isra.9+0x74/0x3d0 [ 3375.091771] __kasan_report+0x198/0x1e8 [ 3375.099486] kasan_report+0xc/0x18 [ 3375.106324] __asan_load1+0x60/0x68 [ 3375.113338] memcmp+0x4c/0x98 [ 3375.119409] mlx5e_tc_ct_restore_flow+0x3a4/0x6f8 [mlx5_core] [ 3375.131073] mlx5e_rep_tc_update_skb+0x1d4/0x2f0 [mlx5_core] [ 3375.142553] mlx5e_handle_rx_cqe_rep+0x198/0x308 [mlx5_core] [ 3375.154034] mlx5e_poll_rx_cq+0x2a0/0x1060 [mlx5_core] [ 3375.164459] mlx5e_napi_poll+0x1d4/0xa78 [mlx5_core] [ 3375.174453] net_rx_action+0x28c/0x7a8 [ 3375.182004] __do_softirq+0x1b4/0x5d0 Manage the lifetime of the ct entry object by using synchornization mechanisms for concurrent access. Fixes: ac991b48d43c ("net/mlx5e: CT: Offload established flows") Signed-off-by: Roi Dayan Signed-off-by: Oz Shlomo Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 345f581e5fa530197154d15f53156179d76dfb38 Author: Shay Drory Date: Thu Dec 31 15:04:08 2020 +0200 net/mlx5: Disable devlink reload for lag devices [ Upstream commit edac23c2b3d3ac64cfcd351087295893671adbf5 ] Devlink reload can't be allowed on lag devices since reloading one lag device will cause traffic on the bond to get stucked. Users who wish to reload a lag device, need to remove the device from the bond, and only then reload it. Fixes: 4383cfcc65e7 ("net/mlx5: Add devlink reload") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 637ffa4261cd9907117f5f6c47e868eb8fd87e24 Author: Shay Drory Date: Sun Jan 3 10:09:59 2021 +0200 net/mlx5: Disallow RoCE on lag device [ Upstream commit 7ab91f2b03367f9d25dd807ebdfb0d67295e0e41 ] In lag mode, setting roce enabled/disable of lag device have no effect. e.g.: bond device (roce/vf_lag) roce status remain unchanged. Therefore disable it and add an error message. Fixes: cc9defcbb8fa ("net/mlx5: Handle "enable_roce" devlink param") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit d0ad9b318ed68a1b5af076279e22cf637118b7eb Author: Shay Drory Date: Wed Dec 30 10:58:34 2020 +0200 net/mlx5: Disallow RoCE on multi port slave device [ Upstream commit c70f8597fcc1399ef6d5b5ce648a31d887d5dba2 ] In dual port mode, setting roce enabled/disable for the slave device have no effect. e.g.: the slave device roce status remain unchanged. Therefore disable it and add an error message. Enable or disable roce of the master device affect both master and slave devices. Fixes: cc9defcbb8fa ("net/mlx5: Handle "enable_roce" devlink param") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 9c9fb9f9254eec86031a3c88f66231c7fbd8b293 Author: Shay Drory Date: Wed Dec 30 09:58:32 2020 +0200 net/mlx5: Disable devlink reload for multi port slave device [ Upstream commit d89ddaae1766f8fe571ea6eb63ec098ff556f1dd ] Devlink reload can't be allowed on a multi port slave device, because reload of slave device doesn't take effect. The right flow is to disable devlink reload for multi port slave device. Hence, disabling it in mlx5_core probing. Fixes: 4383cfcc65e7 ("net/mlx5: Add devlink reload") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 38b83c1e6966d1644879be644c5a8a6db12e41c9 Author: Maxim Mikityanskiy Date: Fri Jan 22 18:42:29 2021 +0200 net/mlx5e: kTLS, Use refcounts to free kTLS RX priv context [ Upstream commit b850bbff965129c34f50962638c0a66c82563536 ] wait_for_resync is unreliable - if it timeouts, priv_rx will be freed anyway. However, mlx5e_ktls_handle_get_psv_completion will be called sooner or later, leading to use-after-free. For example, it can happen if a CQ error happened, and ICOSQ stopped, but later on the queues are destroyed, and ICOSQ is flushed with mlx5e_free_icosq_descs. This patch converts the lifecycle of priv_rx to fully refcount-based, so that the struct won't be freed before the refcount goes to zero. Fixes: 0419d8c9d8f8 ("net/mlx5e: kTLS, Add kTLS RX resync support") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 55562a79da0637aae7edc6605bf54d10cbe10242 Author: Maxim Mikityanskiy Date: Mon Feb 1 14:01:27 2021 +0200 net/mlx5e: Replace synchronize_rcu with synchronize_net [ Upstream commit 4d6e6b0c6d4bed8a7128500701354e2dc6098fa3 ] The commit cited below switched from using napi_synchronize to synchronize_rcu to have a guarantee that it will finish in finite time. However, on average, synchronize_rcu takes more time than napi_synchronize. Given that it's called multiple times per channel on deactivation, it accumulates to a significant amount, which causes timeouts in some applications (for example, when using bonding with NetworkManager). This commit replaces synchronize_rcu with synchronize_net, which is faster when called under rtnl_lock, allowing to speed up the described flow. Fixes: 9c25a22dfb00 ("net/mlx5e: Use synchronize_rcu to sync with NAPI") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 2e5d24b3bf091802c5456dc8f8f6a6be4493c8ca Author: Shay Drory Date: Mon Nov 23 08:39:10 2020 +0200 net/mlx5: Fix health error state handling [ Upstream commit 51d138c2610a236c1ed0059d034ee4c74f452b86 ] Currently, when we discover a fatal error, we are queueing a work that will wait for a lock in order to enter the device to error state. Meanwhile, FW commands are still being processed, and gets timeouts. This can block the driver for few minutes before the work will manage to get the lock and enter to error state. Setting the device to error state before queueing health work, in order to avoid FW commands being processed while the work is waiting for the lock. Fixes: c1d4d2e92ad6 ("net/mlx5: Avoid calling sleeping function by the health poll thread") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 9ee95cdfb4a46f04228d62ac1b4d39fcef429726 Author: Maxim Mikityanskiy Date: Wed Feb 3 18:01:03 2021 +0200 net/mlx5e: Change interrupt moderation channel params also when channels are closed [ Upstream commit 65ba8594a238c20e458b3d2d39d91067cbffd0b1 ] struct mlx5e_params contains fields ({rx,tx}_cq_moderation) that depend on two things: whether DIM is enabled and the state of a private flag (MLX5E_PFLAG_{RX,TX}_CQE_BASED_MODER). Whenever the DIM state changes, mlx5e_reset_{rx,tx}_moderation is called to update the fields, however, only if the channels are open. The flow where the channels are closed misses the required update of the fields. This commit moves the calls of mlx5e_reset_{rx,tx}_moderation, so that they run in both flows. Fixes: ebeaf084ad5c ("net/mlx5e: Properly set default values when disabling adaptive moderation") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4b8b0456132006579b64ccb0d7fa0aa61389a236 Author: Maxim Mikityanskiy Date: Wed Feb 3 17:55:58 2021 +0200 net/mlx5e: Don't change interrupt moderation params when DIM is enabled [ Upstream commit 019f93bc4ba3a0dcb77f448ee77fc4c9c1b89565 ] When mlx5e_ethtool_set_coalesce doesn't change DIM state (enabled/disabled), it calls mlx5e_set_priv_channels_coalesce unconditionally, which in turn invokes a firmware command to set interrupt moderation parameters. It shouldn't happen while DIM manages those parameters dynamically (it might even be happening at the same time). This patch fixes it by splitting mlx5e_set_priv_channels_coalesce into two functions (for RX and TX) and calling them only when DIM is disabled (for RX and TX respectively). Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 5cae37db0559fd9dc948115607da7d1ee57b7001 Author: Raed Salem Date: Mon Jan 25 09:58:22 2021 +0200 net/mlx5e: Enable XDP for Connect-X IPsec capable devices [ Upstream commit e33f9f5f2d3a5fa97728a43708f41da2d4faae65 ] This limitation was inherited by previous Innova (FPGA) IPsec implementation, it uses its private set of RQ handlers which does not support XDP, for Connect-X this is no longer true. Fix by keeping this limitation only for Innova IPsec supporting devices, as otherwise this limitation effectively wrongly blocks XDP for all future Connect-X devices for all flows even if IPsec offload is not used. Fixes: 2d64663cd559 ("net/mlx5: IPsec: Add HW crypto offload support") Signed-off-by: Raed Salem Reviewed-by: Alaa Hleihel Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b84ee271c65efbb51d359231b084a8f93fd41c30 Author: Heiner Kallweit Date: Thu Feb 11 22:32:52 2021 +0100 net: phy: consider that suspend2ram may cut off PHY power [ Upstream commit 4c0d2e96ba055bd8911bb8287def4f8ebbad15b6 ] Claudiu reported that on his system S2R cuts off power to the PHY and after resuming certain PHY settings are lost. The PM folks confirmed that cutting off power to selected components in S2R is a valid case. Therefore resuming from S2R, same as from hibernation, has to assume that the PHY has power-on defaults. As a consequence use the restore callback also as resume callback. In addition make sure that the interrupt configuration is restored. Let's do this in phy_init_hw() and ensure that after this call actual interrupt configuration is in sync with phydev->interrupts. Currently, if interrupt was enabled before hibernation, we would resume with interrupt disabled because that's the power-on default. This fix applies cleanly only after the commit marked as fixed. I don't have an affected system, therefore change is compile-tested only. [0] https://lore.kernel.org/netdev/1610120754-14331-1-git-send-email-claudiu.beznea@microchip.com/ Fixes: 611d779af7ca ("net: phy: fix MDIO bus PM PHY resuming") Reported-by: Claudiu Beznea Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c0425bd9d1bbbfa527a525372ca256ad749b378 Author: Ioana Ciornei Date: Thu Feb 11 21:51:22 2021 +0200 dpaa2-eth: fix memory leak in XDP_REDIRECT [ Upstream commit e12be9139cca26d689fe1a9257054b76752f725b ] If xdp_do_redirect() fails, the calling driver should handle recycling or freeing of the page associated with the frame. The dpaa2-eth driver didn't do either of them and just incremented a counter. Fix this by trying to DMA map back the page and recycle it or, if the mapping fails, just free it. Fixes: d678be1dc1ec ("dpaa2-eth: add XDP_REDIRECT support") Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0903d069efdbe28686d68ac27b2935b81351602d Author: Juergen Gross Date: Thu Feb 11 11:16:12 2021 +0100 xen/netback: fix spurious event detection for common event case [ Upstream commit a3daf3d39132b405781be8d9ede0c449b244b64e ] In case of a common event for rx and tx queue the event should be regarded to be spurious if no rx and no tx requests are pending. Unfortunately the condition for testing that is wrong causing to decide a event being spurious if no rx OR no tx requests are pending. Fix that plus using local variables for rx/tx pending indicators in order to split function calls and if condition. Fixes: 23025393dbeb3b ("xen/netback: use lateeoi irq binding") Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Wei Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 761c9ba3a0547ecd9561c0de69dc17f844453655 Author: Vasundhara Volam Date: Thu Feb 11 02:24:24 2021 -0500 bnxt_en: Fix devlink info's stored fw.psid version format. [ Upstream commit db28b6c77f4050f62599267a886b61fbd6504633 ] The running fw.psid version is in decimal format but the stored fw.psid is in hex format. This can mislead the user to reset the NIC to activate the stored version to become the running version. Fix it to display the stored fw.psid in decimal format. Fixes: 1388875b3916 ("bnxt_en: Add stored FW version info to devlink info_get cb.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 40e841335bd72af9987b0542aec6d22a8d0d2262 Author: Edwin Peer Date: Thu Feb 11 02:24:23 2021 -0500 bnxt_en: reverse order of TX disable and carrier off [ Upstream commit 132e0b65dc2b8bfa9721bfce834191f24fd1d7ed ] A TX queue can potentially immediately timeout after it is stopped and the last TX timestamp on that queue was more than 5 seconds ago with carrier still up. Prevent these intermittent false TX timeouts by bringing down carrier first before calling netif_tx_disable(). Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12e16893ac60ee6334c4cf50f23d37cfde724799 Author: Sukadev Bhattiprolu Date: Wed Feb 10 17:41:43 2021 -0800 ibmvnic: Set to CLOSED state even on error [ Upstream commit d4083d3c00f60a09ad82e3bf17ff57fec69c8aa6 ] If set_link_state() fails for any reason, we still cleanup the adapter state and cannot recover from a partial close anyway. So set the adapter to CLOSED state. That way if a new soft/hard reset is processed, the adapter will remain in the CLOSED state until the next ibmvnic_open(). Fixes: 01d9bd792d16 ("ibmvnic: Reorganize device close") Signed-off-by: Sukadev Bhattiprolu Reported-by: Abdul Haleem Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7cd60dd3561fc8f67a2c0c53fcda131fcdc19df4 Author: Björn Töpel Date: Thu Feb 11 09:20:29 2021 +0100 selftests/bpf: Convert test_xdp_redirect.sh to bash [ Upstream commit 732fa32330667a80ce4985ca81b6e9d6b2ad2072 ] The test_xdp_redirect.sh script uses a bash feature, '&>'. On systems, e.g. Debian, where '/bin/sh' is dash, this will not work as expected. Use bash in the shebang to get the expected behavior. Further, using 'set -e' means that the error of a command cannot be captured without the command being executed with '&&' or '||'. Let us restructure the ping-commands, and use them as an if-expression, so that we can capture the return value. v4: Added missing Fixes:, and removed local variables. (Andrii) v3: Reintroduced /bin/bash, and kept 'set -e'. (Andrii) v2: Kept /bin/sh and removed bashisms. (Randy) Fixes: 996139e801fd ("selftests: bpf: add a test for XDP redirect") Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210211082029.1687666-1-bjorn.topel@gmail.com Signed-off-by: Sasha Levin commit 65cd43086d8f385afc5a7576285f9b568ac01477 Author: Linus Lüssing Date: Wed Feb 10 09:53:44 2021 +0200 ath9k: fix data bus crash when setting nf_override via debugfs [ Upstream commit 12c8f3d1cdd84f01ee777b756db9dddc1f1c9d17 ] When trying to set the noise floor via debugfs, a "data bus error" crash like the following can happen: [ 88.433133] Data bus error, epc == 80221c28, ra == 83314e60 [ 88.438895] Oops[#1]: [ 88.441246] CPU: 0 PID: 7263 Comm: sh Not tainted 4.14.195 #0 [ 88.447174] task: 838a1c20 task.stack: 82d5e000 [ 88.451847] $ 0 : 00000000 00000030 deadc0de 83141de4 [ 88.457248] $ 4 : b810a2c4 0000a2c4 83230fd4 00000000 [ 88.462652] $ 8 : 0000000a 00000000 00000001 00000000 [ 88.468055] $12 : 7f8ef318 00000000 00000000 77f802a0 [ 88.473457] $16 : 83230080 00000002 0000001b 83230080 [ 88.478861] $20 : 83a1c3f8 00841000 77f7adb0 ffffff92 [ 88.484263] $24 : 00000fa4 77edd860 [ 88.489665] $28 : 82d5e000 82d5fda8 00000000 83314e60 [ 88.495070] Hi : 00000000 [ 88.498044] Lo : 00000000 [ 88.501040] epc : 80221c28 ioread32+0x8/0x10 [ 88.505671] ra : 83314e60 ath9k_hw_loadnf+0x88/0x520 [ath9k_hw] [ 88.512049] Status: 1000fc03 KERNEL EXL IE [ 88.516369] Cause : 5080801c (ExcCode 07) [ 88.520508] PrId : 00019374 (MIPS 24Kc) [ 88.524556] Modules linked in: ath9k ath9k_common pppoe ppp_async l2tp_ppp cdc_mbim batman_adv ath9k_hw ath sr9700 smsc95xx sierra_net rndis_host qmi_wwan pppox ppp_generic pl2303 nf_conntrack_ipv6 mcs7830 mac80211 kalmia iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm ftdi_sio dm9601 cfg80211 cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY usbserial usbnet usbhid slhc rtl8150 r8152 pegasus nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack [ 88.597894] libcrc32c kaweth iptable_mangle iptable_filter ipt_ECN ipheth ip_tables hso hid_generic crc_ccitt compat cdc_wdm cdc_acm br_netfilter hid evdev input_core nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 l2tp_netlink l2tp_core udp_tunnel ip6_udp_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 tunnel6 tunnel4 tun xfrm_user xfrm_ipcomp af_key xfrm_algo sha256_generic sha1_generic jitterentropy_rng drbg md5 hmac echainiv des_generic deflate zlib_inflate zlib_deflate cbc authenc crypto_acompress ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common crc16 mii aead crypto_null cryptomgr crc32c_generic [ 88.671671] crypto_hash [ 88.674292] Process sh (pid: 7263, threadinfo=82d5e000, task=838a1c20, tls=77f81efc) [ 88.682279] Stack : 00008060 00000008 00000200 00000000 00000000 00000000 00000000 00000002 [ 88.690916] 80500000 83230080 82d5fe22 00841000 77f7adb0 00000000 00000000 83156858 [ 88.699553] 00000000 8352fa00 83ad62b0 835302a8 00000000 300a00f8 00000003 82d5fe38 [ 88.708190] 82d5fef4 00000001 77f54dc4 77f80000 77f7adb0 c79fe901 00000000 00000000 [ 88.716828] 80510000 00000002 00841000 77f54dc4 77f80000 801ce4cc 0000000b 41824292 [ 88.725465] ... [ 88.727994] Call Trace: [ 88.730532] [<80221c28>] ioread32+0x8/0x10 [ 88.734765] Code: 00000000 8c820000 0000000f <03e00008> 00000000 08088708 00000000 aca40000 03e00008 [ 88.744846] [ 88.746464] ---[ end trace db226b2de1b69b9e ]--- [ 88.753477] Kernel panic - not syncing: Fatal exception [ 88.759981] Rebooting in 3 seconds.. The "REG_READ(ah, AR_PHY_AGC_CONTROL)" in ath9k_hw_loadnf() does not like being called when the hardware is asleep, leading to this crash. The easiest way to reproduce this is trying to set nf_override while the hardware is down: $ ip link set down dev wlan0 $ echo "-85" > /sys/kernel/debug/ieee80211/phy0/ath9k/nf_override Fixing this crash by waking the hardware up before trying to set the noise floor. Similar to what other ath9k debugfs files do. Tested on a Lima board from 8devices, which has a QCA 4531 chipset. Fixes: b90189759a7f ("ath9k: add noise floor override option") Cc: Simon Wunderlich Signed-off-by: Linus Lüssing Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210209184352.4272-1-linus.luessing@c0d3.blue Signed-off-by: Sasha Levin commit 270476930357e5b192ac409ab1e5a5376a2e268c Author: Luca Coelho Date: Wed Feb 10 17:23:52 2021 +0200 iwlwifi: pnvm: increment the pointer before checking the TLV [ Upstream commit ff11a8ee2d2d0f78514ac9b42fb50c525ca695c7 ] If the SKU_ID doesn't match, we don't increment the pointer and keep checking the same TLV over and over again. We need to increment the pointer in all situtations, namely if the TLV is not a SKU_ID, if the SKU_ID matched or if the SKU_ID didn't match. So we can increment the pointer already before checking for these conditions to solve the problem. Signed-off-by: Luca Coelho Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210172142.de94d366f3ff.I9a5a54906cf0f4ec8af981d6066bfd771152ffb9@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 3d338b18d61b05568946003ff58fa734b82eac71 Author: Luca Coelho Date: Wed Feb 10 17:23:50 2021 +0200 iwlwifi: pnvm: set the PNVM again if it was already loaded [ Upstream commit 4a81598f0f39cffbf1c29c4a184063d513661c4a ] When the interface goes up, we have already loaded the PNVM during init, so we don't load it anymore. But we still need to set the PNVM values in the context so that the FW can load it again. Call set_pnvm when the PNVM is already loaded and change the trans_pcie implementation to accept a second call to set_pnvm when we have already allocated and, in this case, only set the values without allocating again. Signed-off-by: Luca Coelho Fixes: 6972592850c0 ("iwlwifi: read and parse PNVM file") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210172142.622546a3566f.I659a8b9aa944d213c4ba446e142d74f3f6db9c64@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 2526c18de3ad98f1ddad5aa4baf4432fbc04ed50 Author: Marco Elver Date: Tue Feb 9 12:27:01 2021 +0100 bpf_lru_list: Read double-checked variable once without lock [ Upstream commit 6df8fb83301d68ea0a0c0e1cbcc790fcc333ed12 ] For double-checked locking in bpf_common_lru_push_free(), node->type is read outside the critical section and then re-checked under the lock. However, concurrent writes to node->type result in data races. For example, the following concurrent access was observed by KCSAN: write to 0xffff88801521bc22 of 1 bytes by task 10038 on cpu 1: __bpf_lru_node_move_in kernel/bpf/bpf_lru_list.c:91 __local_list_flush kernel/bpf/bpf_lru_list.c:298 ... read to 0xffff88801521bc22 of 1 bytes by task 10043 on cpu 0: bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:507 bpf_lru_push_free kernel/bpf/bpf_lru_list.c:555 ... Fix the data races where node->type is read outside the critical section (for double-checked locking) by marking the access with READ_ONCE() as well as ensuring the variable is only accessed once. Fixes: 3a08c2fd7634 ("bpf: LRU List") Reported-by: syzbot+3536db46dfa58c573458@syzkaller.appspotmail.com Reported-by: syzbot+516acdb03d3e27d91bcd@syzkaller.appspotmail.com Signed-off-by: Marco Elver Signed-off-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210209112701.3341724-1-elver@google.com Signed-off-by: Sasha Levin commit 18b83fc1d2abd92b4c18dae1e3952ce8d47a27a0 Author: Sara Sharon Date: Wed Feb 10 17:15:09 2021 +0200 iwlwifi: mvm: don't check if CSA event is running before removing [ Upstream commit b8a86164454aa745ecb534d7477d50d440ea05b6 ] We may want to remove it before it started (i.e. before the actual switch time). Signed-off-by: Sara Sharon Fixes: 58ddd9b6d194 ("iwlwifi: mvm: don't send a CSA command the firmware doesn't know") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210171218.835db8987b8a.Ic6c5d28d744302db1bc6c4314bd3138ba472f834@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 3048a74339774b57793b2e124ac7cd11a09ebe01 Author: Luca Coelho Date: Wed Feb 10 13:56:34 2021 +0200 iwlwifi: mvm: assign SAR table revision to the command later [ Upstream commit 28db1862067cb09ebfdccfbc129a52c6fdb4c4d7 ] The call to iwl_sar_geo_init() was moved to the end of the iwl_mvm_sar_geo_init() function, after the table revision is assigned to the FW command. But the revision is only known after iwl_sar_geo_init() is called, so we were always assigning zero to it. Fix that by moving the assignment code after the iwl_sar_geo_init() function is called. Signed-off-by: Luca Coelho Fixes: 45acebf8d6a6 ("iwlwifi: fix sar geo table initialization") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210135352.cef55ef3a065.If96c60f08d24c2262c287168a6f0dbd7cf0f8f5c@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit dbc1fba6658608e65db3e6aec1761cdc58b7f7a6 Author: Luca Coelho Date: Wed Feb 10 13:56:31 2021 +0200 iwlwifi: mvm: send stored PPAG command instead of local [ Upstream commit 659844d391826bfc5c8b4d9a06869ed51d859c76 ] Some change conflicts apparently cause a confusion between a local variable being used to send the PPAG command and the introduction of a union for this command. Most parts of the local command were never copied from the stored data, so the FW was getting garbage in the tables instead of getting valid values. Fix this by completely removing the local and using only the union that we have stored in fwrt. Signed-off-by: Luca Coelho Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210135352.d090e0301023.I7d57f4d7da9a3297734c51cf988199323c76916d@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit b23e27d56332ae1b25f0939334cd27e657b71403 Author: Luca Coelho Date: Wed Feb 10 13:56:30 2021 +0200 iwlwifi: mvm: store PPAG enabled/disabled flag properly [ Upstream commit 551d793f65364c904921ac168d4b4028bb51be69 ] When reading the PPAG table from ACPI, we should store everything in our fwrt structure, so it can be accessed later. But we had a local ppag_table variable in the function and were erroneously storing the enabled/disabled flag in it instead of storing it in the fwrt. Fix this by removing the local variable and storing everything directly in fwrt. Signed-off-by: Luca Coelho Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210135352.889862e6d393.I8b894c1b2b3fe0ad2fb39bf438273ea47eb5afa4@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 745d375cf4879c64f6c5a680e3f28eb3c87c4891 Author: Luca Coelho Date: Wed Feb 10 13:56:29 2021 +0200 iwlwifi: mvm: fix the type we use in the PPAG table validity checks [ Upstream commit 5a6842455c113920001df83cffa28accceeb0927 ] The value we receive from ACPI is a long long unsigned integer but the values should be treated as signed char. When comparing the received value with ACPI_PPAG_MIN_LB/HB, we were doing an unsigned comparison, so the negative value would actually be treated as a very high number. To solve this issue, assign the value to our table of s8's before making the comparison, so the value is already converted when we do so. Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210210135352.b0ec69f312bc.If77fd9c61a96aa7ef2ac96d935b7efd7df502399@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit ab2db97c7c11749d0a81182b2dfbedd82abb9eee Author: Jae Hyun Yoo Date: Tue Dec 8 17:17:47 2020 +0800 soc: aspeed: snoop: Add clock control logic [ Upstream commit 3f94cf15583be554df7aaa651b8ff8e1b68fbe51 ] If LPC SNOOP driver is registered ahead of lpc-ctrl module, LPC SNOOP block will be enabled without heart beating of LCLK until lpc-ctrl enables the LCLK. This issue causes improper handling on host interrupts when the host sends interrupt in that time frame. Then kernel eventually forcibly disables the interrupt with dumping stack and printing a 'nobody cared this irq' message out. To prevent this issue, all LPC sub-nodes should enable LCLK individually so this patch adds clock control logic into the LPC SNOOP driver. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Jae Hyun Yoo Signed-off-by: Vernon Mauery Signed-off-by: John Wang Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20201208091748.1920-1-wangzhiqiang.bj@bytedance.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 02823f0cd765c3ee723cc902fcde9793da5fb7e9 Author: Dan Carpenter Date: Tue Feb 9 09:29:43 2021 +0200 ath11k: fix a locking bug in ath11k_mac_op_start() [ Upstream commit c202e2ebe1dc454ad54fd0018c023ec553d47284 ] This error path leads to a Smatch warning: drivers/net/wireless/ath/ath11k/mac.c:4269 ath11k_mac_op_start() error: double unlocked '&ar->conf_mutex' (orig line 4251) We're not holding the lock when we do the "goto err;" so it leads to a double unlock. The fix is to hold the lock for a little longer. Fixes: c83c500b55b6 ("ath11k: enable idle power save mode") Signed-off-by: Dan Carpenter [kvalo@codeaurora.org: move also rcu_assign_pointer() call] Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YBk4GoeE+yc0wlJH@mwanda Signed-off-by: Sasha Levin commit 99520e97d93dce65c7623e0564cb306dbecc080f Author: Anand K Mistry Date: Mon Feb 8 13:32:10 2021 +0200 ath10k: Fix lockdep assertion warning in ath10k_sta_statistics [ Upstream commit 7df28718928d08034b36168200d67b558ce36f3d ] ath10k_debug_fw_stats_request just be called with conf_mutex held, otherwise the following warning is seen when lock debugging is enabled: WARNING: CPU: 0 PID: 793 at drivers/net/wireless/ath/ath10k/debug.c:357 ath10k_debug_fw_stats_request+0x12c/0x133 [ath10k_core] Modules linked in: snd_hda_codec_hdmi designware_i2s snd_hda_intel snd_intel_dspcfg snd_hda_codec i2c_piix4 snd_hwdep snd_hda_core acpi_als kfifo_buf industrialio snd_soc_max98357a snd_soc_adau7002 snd_soc_acp_da7219mx98357_mach snd_soc_da7219 acp_audio_dma ccm xt_MASQUERADE fuse ath10k_pci ath10k_core lzo_rle ath lzo_compress mac80211 zram cfg80211 r8152 mii joydev CPU: 0 PID: 793 Comm: wpa_supplicant Tainted: G W 5.10.9 #5 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.104.0 09/05/2019 RIP: 0010:ath10k_debug_fw_stats_request+0x12c/0x133 [ath10k_core] Code: 1e bb a1 ff ff ff 4c 89 ef 48 c7 c6 d3 31 2e c0 89 da 31 c0 e8 bd f8 ff ff 89 d8 eb 02 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e9 04 ff ff ff 0f 1f 44 00 00 55 48 89 e5 41 56 53 48 89 fb RSP: 0018:ffffb2478099f7d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9e432700cce0 RCX: 11c85cfd6b8e3b00 RDX: ffff9e432700cce0 RSI: ffff9e43127c5668 RDI: ffff9e4318deddf0 RBP: ffffb2478099f7f8 R08: 0000000000000002 R09: 00000003fd7068cc R10: ffffffffc01b2749 R11: ffffffffc029efaf R12: ffff9e432700c000 R13: ffff9e43127c33e0 R14: ffffb2478099f918 R15: ffff9e43127c33e0 FS: 00007f7ea48e2740(0000) GS:ffff9e432aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000059aa799ddf38 CR3: 0000000118de2000 CR4: 00000000001506f0 Call Trace: ath10k_sta_statistics+0x4d/0x270 [ath10k_core] sta_set_sinfo+0x1be/0xaec [mac80211] ieee80211_get_station+0x58/0x76 [mac80211] rdev_get_station+0xf1/0x11e [cfg80211] nl80211_get_station+0x7f/0x146 [cfg80211] genl_rcv_msg+0x32e/0x35e ? nl80211_stop_ap+0x19/0x19 [cfg80211] ? nl80211_get_station+0x146/0x146 [cfg80211] ? genl_rcv+0x19/0x36 ? genl_rcv+0x36/0x36 netlink_rcv_skb+0x89/0xfb genl_rcv+0x28/0x36 netlink_unicast+0x169/0x23b netlink_sendmsg+0x38a/0x402 sock_sendmsg+0x72/0x76 ____sys_sendmsg+0x153/0x1cc ? copy_msghdr_from_user+0x5d/0x85 ___sys_sendmsg+0x7c/0xb5 ? lock_acquire+0x181/0x23d ? syscall_trace_enter+0x15e/0x160 ? find_held_lock+0x3d/0xb2 ? syscall_trace_enter+0x15e/0x160 ? sched_clock_cpu+0x15/0xc6 __sys_sendmsg+0x62/0x9a do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 4913e675630e ("ath10k: enable rx duration report default for wmi tlv") Signed-off-by: Anand K Mistry Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210202144033.1.I9e556f9fb1110d58c31d04a8a1293995fb8bb678@changeid Signed-off-by: Sasha Levin commit e9397f46891db191a828cfba7bb6c39ebf4fa821 Author: Anand K Mistry Date: Mon Feb 8 13:32:09 2021 +0200 ath10k: Fix suspicious RCU usage warning in ath10k_wmi_tlv_parse_peer_stats_info() [ Upstream commit 2615e3cdbd9c0e864f5906279c952a309871d225 ] The ieee80211_find_sta_by_ifaddr call in ath10k_wmi_tlv_parse_peer_stats_info must be called while holding the RCU read lock. Otherwise, the following warning will be seen when RCU usage checking is enabled: ============================= WARNING: suspicious RCU usage 5.10.3 #8 Tainted: G W ----------------------------- include/linux/rhashtable.h:594 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by ksoftirqd/1/16. stack backtrace: CPU: 1 PID: 16 Comm: ksoftirqd/1 Tainted: G W 5.10.3 #8 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.104.0 09/05/2019 Call Trace: dump_stack+0xab/0x115 sta_info_hash_lookup+0x71/0x1e9 [mac80211] ? lock_is_held_type+0xe6/0x12f ? __kasan_kmalloc+0xfb/0x112 ieee80211_find_sta_by_ifaddr+0x12/0x61 [mac80211] ath10k_wmi_tlv_parse_peer_stats_info+0xbd/0x10b [ath10k_core] ath10k_wmi_tlv_iter+0x8b/0x1a1 [ath10k_core] ? ath10k_wmi_tlv_iter+0x1a1/0x1a1 [ath10k_core] ath10k_wmi_tlv_event_peer_stats_info+0x103/0x13b [ath10k_core] ath10k_wmi_tlv_op_rx+0x722/0x80d [ath10k_core] ath10k_htc_rx_completion_handler+0x16e/0x1d7 [ath10k_core] ath10k_pci_process_rx_cb+0x116/0x22c [ath10k_pci] ? ath10k_htc_process_trailer+0x332/0x332 [ath10k_core] ? _raw_spin_unlock_irqrestore+0x34/0x61 ? lockdep_hardirqs_on+0x8e/0x12e ath10k_ce_per_engine_service+0x55/0x74 [ath10k_core] ath10k_ce_per_engine_service_any+0x76/0x84 [ath10k_core] ath10k_pci_napi_poll+0x49/0x141 [ath10k_pci] net_rx_action+0x11a/0x347 __do_softirq+0x2d3/0x539 run_ksoftirqd+0x4b/0x86 smpboot_thread_fn+0x1d0/0x2ab ? cpu_report_death+0x7f/0x7f kthread+0x189/0x191 ? cpu_report_death+0x7f/0x7f ? kthread_blkcg+0x31/0x31 ret_from_fork+0x22/0x30 Fixes: 0f7cb26830a6e ("ath10k: add rx bitrate report for SDIO") Signed-off-by: Anand K Mistry Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210202134451.1.I0d2e83c42755671b7143504b62787fd06cd914ed@changeid Signed-off-by: Sasha Levin commit 55eceabb139a4c01e1d8b5fff51e3a482c949a13 Author: Arnd Bergmann Date: Thu Feb 4 17:01:20 2021 +0100 ARM: at91: use proper asm syntax in pm_suspend [ Upstream commit d30337da8677cd73cb19444436b311c13e57356f ] Compiling with the clang integrated assembler warns about a recently added instruction: :14:13: error: unknown token in expression ldr tmp1, =#0x00020010UL arch/arm/mach-at91/pm_suspend.S:542:2: note: while in macro instantiation at91_plla_enable Remove the extra '#' character that is not used for the 'ldr' instruction when doing an indirect load of a constant. Fixes: 4fd36e458392 ("ARM: at91: pm: add plla disable/enable support for sam9x60") Tested-by: Claudiu Beznea Reviewed-by: Claudiu Beznea Reviewed-by: Nathan Chancellor Acked-by: Nicolas Ferre Link: https://lore.kernel.org/r/20210204160129.2249394-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 4e5d3ff90b38efdf40cfea90cdfef2ac390b465e Author: Jérôme Pouiller Date: Mon Feb 8 14:52:54 2021 +0100 staging: wfx: fix possible panic with re-queued frames [ Upstream commit 26df933d9b83ea668304dc4ec641d52ea1fc4091 ] When the firmware rejects a frame (because station become asleep or disconnected), the frame is re-queued in mac80211. However, the re-queued frame was 8 bytes longer than the original one (the size of the ICV for the encryption). So, when mac80211 try to send this frame again, it is a little bigger than expected. If the frame is re-queued secveral time it end with a skb_over_panic because the skb buffer is not large enough. Note it only happens when device acts as an AP and encryption is enabled. This patch more or less reverts the commit 049fde130419 ("staging: wfx: drop useless field from struct wfx_tx_priv"). Fixes: 049fde130419 ("staging: wfx: drop useless field from struct wfx_tx_priv") Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20210208135254.399964-1-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a6c9669be52c6819885724f171f70eeead3f7ef2 Author: Arnd Bergmann Date: Mon Jan 25 12:37:52 2021 +0100 optee: simplify i2c access [ Upstream commit 67bc809752796acb2641ca343cad5b45eef31d7c ] Storing a bogus i2c_client structure on the stack adds overhead and causes a compile-time warning: drivers/tee/optee/rpc.c:493:6: error: stack frame size of 1056 bytes in function 'optee_handle_rpc' [-Werror,-Wframe-larger-than=] void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, Change the implementation of handle_rpc_func_cmd_i2c_transfer() to open-code the i2c_transfer() call, which makes it easier to read and avoids the warning. Fixes: c05210ab9757 ("drivers: optee: allow op-tee to access devices on the i2c bus") Tested-by: Jorge Ramirez-Ortiz Signed-off-by: Arnd Bergmann Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 78eacadea62b5014715186593f044c7b5a4a156c Author: Arnd Bergmann Date: Thu Feb 4 17:23:42 2021 +0100 ARM: s3c: fix fiq for clang IAS [ Upstream commit 7f9942c61fa60eda7cc8e42f04bd25b7d175876e ] Building with the clang integrated assembler produces a couple of errors for the s3c24xx fiq support: arch/arm/mach-s3c/irq-s3c24xx-fiq.S:52:2: error: instruction 'subne' can not set flags, but 's' suffix specified subnes pc, lr, #4 @@ return, still have work to do arch/arm/mach-s3c/irq-s3c24xx-fiq.S:64:1: error: invalid symbol redefinition s3c24xx_spi_fiq_txrx: There are apparently two problems: one with extraneous or duplicate labels, and one with old-style opcode mnemonics. Stefan Agner has previously fixed other problems like this, but missed this particular file. Fixes: bec0806cfec6 ("spi_s3c24xx: add FIQ pseudo-DMA support") Cc: Stefan Agner Signed-off-by: Arnd Bergmann Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210204162416.3030114-1-arnd@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit d7a5fa9c249e310bc50593d49d99d367143d9745 Author: Luca Coelho Date: Sun Jan 31 20:22:06 2021 +0200 iwlwifi: mvm: set enabled in the PPAG command properly [ Upstream commit efaa85cf2294d5e10a724e24356507eeb3836f72 ] When version 2 of the PER_PLATFORM_ANT_GAIN_CMD was implemented, we started copying the values from the command that we have stored into a local instance. But we accidentally forgot to copy the enabled flag, so in practice PPAG is never really enabled. Fix this by copying the flag from our stored data a we should. Signed-off-by: Luca Coelho Fixes: f2134f66f40e ("iwlwifi: acpi: support ppag table command v2") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210131201908.24d7bf754ad5.I0e8abc2b8747508b6118242533d68c856ca6dffb@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit e24333dd688a8bed2408f4db844a91d42c5b9463 Author: Artem Lapkin Date: Fri Jan 29 16:50:40 2021 +0800 arm64: dts: meson: fix broken wifi node for Khadas VIM3L [ Upstream commit 39be8f441f78908e97ff913571e10ec03387a63a ] move &sd_emmc_a ... from /* */ commented area, because cant load wifi fw without sd-uhs-sdr50 option on VIM3L [ 11.686590] brcmfmac: brcmf_chip_cores_check: CPU core not detected [ 11.696382] brcmfmac: brcmf_sdio_probe_attach: brcmf_chip_attach failed! [ 11.706240] brcmfmac: brcmf_sdio_probe: brcmf_sdio_probe_attach failed [ 11.715890] brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19... [ 13.718424] brcmfmac: brcmf_chip_recognition: chip backplane type 15 is not supported Signed-off-by: Artem Lapkin Fixes: f1bb924e8f5b ("arm64: dts: meson: fix mmc0 tuning error on Khadas VIM3") Reviewed-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20210129085041.1408540-1-art@khadas.com Signed-off-by: Sasha Levin commit 62dd5b401dc3a0a24dde6b53a6e46bbc4deace9e Author: Vincent Knecht Date: Sat Jan 23 11:44:16 2021 +0100 arm64: dts: msm8916: Fix reserved and rfsa nodes unit address [ Upstream commit d5ae2528b0b56cf054b27d48b0cb85330900082f ] Fix `reserved` and `rfsa` unit address according to their reg address Fixes: 7258e10e6a0b ("ARM: dts: msm8916: Update reserved-memory") Signed-off-by: Vincent Knecht Link: https://lore.kernel.org/r/20210123104417.518105-1-vincent.knecht@mailoo.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 057e215531a746f0009a330ca9c40525abf157f4 Author: Luca Weiss Date: Sat Jan 30 15:23:49 2021 +0100 soc: qcom: ocmem: don't return NULL in of_get_ocmem [ Upstream commit 01f937ffc4686837d6c43dea80c6ade6cbd2940a ] If ocmem probe fails for whatever reason, of_get_ocmem returned NULL. Without this, users must check for both NULL and IS_ERR on the returned pointer - which didn't happen in drivers/gpu/drm/msm/adreno/adreno_gpu.c leading to a NULL pointer dereference. Reviewed-by: Brian Masney Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20210130142349.53335-1-luca@z3ntu.xyz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e3c47f349bef85e458530d2580c2e219a76c4656 Author: Jupeng Zhong Date: Tue Feb 2 09:39:13 2021 +0800 Bluetooth: btusb: Fix memory leak in btusb_mtk_wmt_recv [ Upstream commit de71a6cb4bf24d8993b9ca90d1ddb131b60251a1 ] In btusb_mtk_wmt_recv if skb_clone fails, the alocated skb should be released. Omit the labels “err_out” and “err_free_skb” in this function implementation so that the desired exception handling code would be directly specified in the affected if branches. Fixes: a1c49c434e15 ("btusb: Add protocol support for MediaTek MT7668U USB devices") Signed-off-by: Jupeng Zhong Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit ccec2a9596db43b3e576f4c7fdba8e6871a5856b Author: Dmitry Osipenko Date: Mon Jan 18 03:55:15 2021 +0300 opp: Correct debug message in _opp_add_static_v2() [ Upstream commit d7b9d9b31a3e55dcc9b5c289abfafe31efa5b5c4 ] The debug message always prints rate=0 instead of a proper value, fix it. Fixes: 6c591eec67cb ("OPP: Add helpers for reading the binding properties") Tested-by: Peter Geis Tested-by: Nicolas Chauvet Tested-by: Matt Merhar Signed-off-by: Dmitry Osipenko [ Viresh: Added Fixes tag ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e95d4a5558988ffff877a0378660852d53bbd2df Author: Marek Behún Date: Mon Jan 11 03:12:43 2021 +0100 arm64: dts: armada-3720-turris-mox: rename u-boot mtd partition to a53-firmware [ Upstream commit a9d9bfcadfb43b856dbcf9419de75f7420d5a225 ] The partition called "u-boot" in reality contains TF-A and U-Boot, and TF-A is before U-Boot. Rename this parition to "a53-firmware" to avoid confusion for users, since they cannot simply build U-Boot from U-Boot repository and flash the resulting image there. Instead they have to build the firmware with the sources from the mox-boot-builder repository [1] and flash the a53-firmware.bin binary there. [1] https://gitlab.nic.cz/turris/mox-boot-builder Signed-off-by: Marek Behún Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Cc: Gregory CLEMENT Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 21883906bdd1030ac2f1f6d5ab37e841fac0ea5c Author: Rosen Penev Date: Wed Dec 2 18:23:21 2020 -0800 ARM: dts: armada388-helios4: assign pinctrl to each fan [ Upstream commit 46ecdfc1830eaa40a11d7f832089c82b0e67ea96 ] Split up the pins for each fan. This is needed in order to control them Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 5d061285445bf5fae359b786b0f6854244fa7c99 Author: Rosen Penev Date: Wed Dec 2 18:23:20 2020 -0800 ARM: dts: armada388-helios4: assign pinctrl to LEDs [ Upstream commit e011c9025a4691b5c734029577a920bd6c320994 ] Split up the pins to match earlier definitions. Allows LEDs to flash properly. Fixes: ced8025b569e ("ARM: dts: armada388-helios4") Signed-off-by: Rosen Penev Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 16a70042934d3fabf9ddb020a5b0fbbace501de3 Author: Marc Kleine-Budde Date: Thu Oct 15 23:06:31 2020 +0200 can: mcp251xfd: mcp251xfd_probe(): fix errata reference [ Upstream commit 28eb119c042e8d3420b577b5b3ea851a111e7b2d ] This patch fixes the reference to the errata for both the mcp2517fd and the mcp2518fd. Fixes: f5b84dedf7eb ("can: mcp25xxfd: mcp25xxfd_probe(): add SPI clk limit related errata information") Link: https://lore.kernel.org/r/20210128104644.2982125-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 7df9337e618f2938820dc006cfc0978cb8c389fa Author: Geert Uytterhoeven Date: Thu Jan 28 12:01:36 2021 +0100 arm64: dts: renesas: beacon: Fix EEPROM compatible value [ Upstream commit 74477936a828a7c91a61ba7e625b7ce2299c8c98 ] "make dtbs_check" fails with: arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dt.yaml: eeprom@50: compatible: 'oneOf' conditional failed, one must be fixed: 'microchip,at24c64' does not match '^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$' Fix this by dropping the bogus "at" prefix. Fixes: a1d8a344f1ca0709 ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210128110136.2293490-1-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 5c0b0b864d2a5550613d01f7666be295b59ba0b2 Author: Misono Tomohiro Date: Wed Jan 27 21:24:56 2021 +0900 x86/MSR: Filter MSR writes through X86_IOC_WRMSR_REGS ioctl too [ Upstream commit 02a16aa13574c8526beadfc9ae8cc9b66315fa2d ] Commit a7e1f67ed29f ("x86/msr: Filter MSR writes") introduced a module parameter to disable writing to the MSR device file and tainted the kernel upon writing. As MSR registers can be written by the X86_IOC_WRMSR_REGS ioctl too, the same filtering and tainting should be applied to the ioctl as well. [ bp: Massage commit message and space out statements. ] Fixes: a7e1f67ed29f ("x86/msr: Filter MSR writes") Signed-off-by: Misono Tomohiro Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210127122456.13939-1-misono.tomohiro@jp.fujitsu.com Signed-off-by: Sasha Levin commit 87f7bdf9c02d117706c639d5ef2b49d10ae908b4 Author: Chen-Yu Tsai Date: Fri Jan 8 22:14:01 2021 +0800 staging: rtl8723bs: wifi_regd.c: Fix incorrect number of regulatory rules [ Upstream commit 61834c967a929f6b4b7fcb91f43fa225cc29aa19 ] The custom regulatory ruleset in the rtl8723bs driver lists an incorrect number of rules: one too many. This results in an out-of-bounds access, as detected by KASAN. This was possible thanks to the newly added support for KASAN on ARMv7. Fix this by filling in the correct number of rules given. KASAN report: ================================================================== BUG: KASAN: global-out-of-bounds in cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211] Read of size 4 at addr bf20c254 by task ip/971 CPU: 2 PID: 971 Comm: ip Tainted: G C 5.11.0-rc2-00020-gf7fe528a7ebe #1 Hardware name: Allwinner sun8i Family [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x9c/0xb4) [] (dump_stack) from [] (print_address_description.constprop.2+0x1dc/0x2dc) [] (print_address_description.constprop.2) from [] (kasan_report+0x1a8/0x1c4) [] (kasan_report) from [] (cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211]) [] (cfg80211_does_bw_fit_range [cfg80211]) from [] (freq_reg_info_regd.part.6+0x108/0x124 [> [] (freq_reg_info_regd.part.6 [cfg80211]) from [] (handle_channel_custom.constprop.12+0x48/> [] (handle_channel_custom.constprop.12 [cfg80211]) from [] (wiphy_apply_custom_regulatory+0> [] (wiphy_apply_custom_regulatory [cfg80211]) from [] (rtw_regd_init+0x60/0x70 [r8723bs]) [] (rtw_regd_init [r8723bs]) from [] (rtw_cfg80211_init_wiphy+0x164/0x1e8 [r8723bs]) [] (rtw_cfg80211_init_wiphy [r8723bs]) from [] (_netdev_open+0xe4/0x28c [r8723bs]) [] (_netdev_open [r8723bs]) from [] (netdev_open+0x60/0x88 [r8723bs]) [] (netdev_open [r8723bs]) from [] (__dev_open+0x178/0x220) [] (__dev_open) from [] (__dev_change_flags+0x258/0x2c4) [] (__dev_change_flags) from [] (dev_change_flags+0x40/0x80) [] (dev_change_flags) from [] (do_setlink+0x538/0x1160) [] (do_setlink) from [] (__rtnl_newlink+0x65c/0xad8) [] (__rtnl_newlink) from [] (rtnl_newlink+0x4c/0x6c) [] (rtnl_newlink) from [] (rtnetlink_rcv_msg+0x1f8/0x454) [] (rtnetlink_rcv_msg) from [] (netlink_rcv_skb+0xc4/0x1e0) [] (netlink_rcv_skb) from [] (netlink_unicast+0x2c8/0x3c4) [] (netlink_unicast) from [] (netlink_sendmsg+0x320/0x5f0) [] (netlink_sendmsg) from [] (____sys_sendmsg+0x320/0x3e0) [] (____sys_sendmsg) from [] (___sys_sendmsg+0xe8/0x12c) [] (___sys_sendmsg) from [] (__sys_sendmsg+0xc0/0x120) [] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x58) Exception stack(0xc5693fa8 to 0xc5693ff0) 3fa0: 00000074 c7a39800 00000003 b6cee648 00000000 00000000 3fc0: 00000074 c7a39800 00000001 00000128 78d18349 00000000 b6ceeda0 004f7cb0 3fe0: 00000128 b6cee5e8 aeca151f aec1d746 The buggy address belongs to the variable: rtw_drv_halt+0xf908/0x6b4 [r8723bs] Memory state around the buggy address: bf20c100: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 bf20c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >bf20c200: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 ^ bf20c280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bf20c300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20210108141401.31741-1-wens@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a459ba7428521abadb5dca3eaf63ee15901b28f1 Author: Guenter Roeck Date: Wed Jan 13 12:20:51 2021 +0100 usb: dwc2: Make "trimming xfer length" a debug message [ Upstream commit 1a9e38cabd80356ffb98c2c88fec528ea9644fd5 ] With some USB network adapters, such as DM96xx, the following message is seen for each maximum size receive packet. dwc2 ff540000.usb: dwc2_update_urb_state(): trimming xfer length This happens because the packet size requested by the driver is 1522 bytes, wMaxPacketSize is 64, the dwc2 driver configures the chip to receive 24*64 = 1536 bytes, and the chip does indeed send more than 1522 bytes of data. Since the event does not indicate an error condition, the message is just noise. Demote it to debug level. Fixes: 7359d482eb4d3 ("staging: HCD files for the DWC2 driver") Tested-by: Nicolas Saenz Julienne Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20210113112052.17063-4-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fc04ddf806b666f9a166ce7324a4116e528e3876 Author: Guenter Roeck Date: Wed Jan 13 12:20:50 2021 +0100 usb: dwc2: Abort transaction after errors with unknown reason [ Upstream commit f74b68c61cbc4b2245022fcce038509333d63f6f ] In some situations, the following error messages are reported. dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021 This is sometimes followed by: dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length and then: WARNING: CPU: 0 PID: 0 at kernel/v4.19/drivers/usb/dwc2/hcd.c:2913 dwc2_assign_and_init_hc+0x98c/0x990 The warning suggests that an odd buffer address is to be used for DMA. After an error is observed, the receive buffer may be full (urb->actual_length >= urb->length). However, the urb is still left in the queue unless three errors were observed in a row. When it is queued again, the dwc2 hcd code translates this into a 1-block transfer. If urb->actual_length (ie the total expected receive length) is not DMA-aligned, the buffer pointer programmed into the chip will be unaligned. This results in the observed warning. To solve the problem, abort input transactions after an error with unknown cause if the entire packet was already received. This may be a bit drastic, but we don't really know why the transfer was aborted even though the entire packet was received. Aborting the transfer in this situation is less risky than accepting a potentially corrupted packet. With this patch in place, the 'ChHltd set' and 'trimming xfer length' messages are still observed, but there are no more transfer attempts with odd buffer addresses. Fixes: 151d0cbdbe860 ("usb: dwc2: make the scheduler handle excessive NAKs better") Cc: Boris ARZUR Cc: Douglas Anderson Tested-by: Nicolas Saenz Julienne Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20210113112052.17063-3-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit eae65bd616cae59da32dba2ceee296c2a12e8fee Author: Guenter Roeck Date: Wed Jan 13 12:20:49 2021 +0100 usb: dwc2: Do not update data length if it is 0 on inbound transfers [ Upstream commit 415fa1c7305dedbb345e2cc8ac91769bc1c83f1a ] The DWC2 documentation states that transfers with zero data length should set the number of packets to 1 and the transfer length to 0. This is not currently the case for inbound transfers: the transfer length is set to the maximum packet length. This can have adverse effects if the chip actually does transfer data as it is programmed to do. Follow chip documentation and keep the transfer length set to 0 in that situation. Fixes: 56f5b1cff22a1 ("staging: Core files for the DWC2 driver") Tested-by: Nicolas Saenz Julienne Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20210113112052.17063-2-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit eaf6f7bb2a777c3c93c379142971469c19ade099 Author: Tony Lindgren Date: Wed Dec 30 10:42:30 2020 +0200 ARM: dts: Configure missing thermal interrupt for 4430 [ Upstream commit 44f416879a442600b006ef7dec3a6dc98bcf59c6 ] We have gpio_86 wired internally to the bandgap thermal shutdown interrupt on 4430 like we have it on 4460 according to the TRM. This can be found easily by searching for TSHUT. For some reason the thermal shutdown interrupt was never added for 4430, let's add it. I believe this is needed for the thermal shutdown interrupt handler ti_bandgap_tshut_irq_handler() to call orderly_poweroff(). Fixes: aa9bb4bb8878 ("arm: dts: add omap4430 thermal data") Cc: Carl Philipp Klemm Cc: Daniel Lezcano Cc: Eduardo Valentin Cc: Merlijn Wajer Cc: Pavel Machek Cc: Peter Ujfalusi Cc: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit f9ce8ea4c13a3b346ce8ae5a0f45b34872e06664 Author: Pan Bian Date: Thu Jan 21 01:03:59 2021 -0800 memory: ti-aemif: Drop child node when jumping out loop [ Upstream commit 94e9dd43cf327366388c8f146bccdc6322c0d999 ] Call of_node_put() to decrement the reference count of the child node child_np when jumping out of the loop body of for_each_available_child_of_node(), which is a macro that increments and decrements the reference count of child node. If the loop is broken, the reference of the child node should be dropped manually. Fixes: 5a7c81547c1d ("memory: ti-aemif: introduce AEMIF driver") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210121090359.61763-1-bianpan2016@163.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 432539871b331a20e78bc72edce0378c00961fe6 Author: Pan Bian Date: Thu Jan 21 00:10:45 2021 -0800 Bluetooth: Put HCI device if inquiry procedure interrupts [ Upstream commit 28a758c861ff290e39d4f1ee0aa5df0f0b9a45ee ] Jump to the label done to decrement the reference count of HCI device hdev on path that the Inquiry procedure is interrupted. Fixes: 3e13fa1e1fab ("Bluetooth: Fix hci_inquiry ioctl usage") Signed-off-by: Pan Bian Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 259ce5ae8efa71d8a2b60bae5a0fe75e04ff11da Author: Pan Bian Date: Wed Jan 20 23:34:19 2021 -0800 Bluetooth: drop HCI device reference before return [ Upstream commit 5a3ef03afe7e12982dc3b978f4c5077c907f7501 ] Call hci_dev_put() to decrement reference count of HCI device hdev if fails to duplicate memory. Fixes: 0b26ab9dce74 ("Bluetooth: AMP: Handle Accept phylink command status evt") Signed-off-by: Pan Bian Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 0b95632402ef266c8b4a1f0166de03208e5e5243 Author: Borislav Petkov Date: Thu Nov 26 19:11:50 2020 +0100 staging: media: atomisp: Fix size_t format specifier in hmm_alloc() debug statemenet [ Upstream commit bfe21ef195a9f2785747e698dfd19f75554e2d91 ] Fix this build warning on 32-bit: drivers/staging/media/atomisp/pci/hmm/hmm.c: In function ‘hmm_alloc’: drivers/staging/media/atomisp/pci/hmm/hmm.c:272:3: warning: format ‘%ld’ \ expects argument of type ‘long int’, but argument 6 has type ‘size_t {aka unsigned int}’ [-Wformat=] "%s: pages: 0x%08x (%ld bytes), type: %d from highmem %d, user ptr %p, cached %d\n", ^ Fixes: 03884c93560c ("media: atomisp: add debug for hmm alloc") Cc: Mauro Carvalho Chehab Cc: Sakari Ailus Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20201126181150.10576-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 235182fd7a21a8091325561b797ab100777d94f1 Author: Christophe JAILLET Date: Sun Jan 24 20:51:36 2021 -0800 soc: ti: pm33xx: Fix some resource leak in the error handling paths of the probe function [ Upstream commit 17ad4662595ea0c4fd7496b664523ef632e63349 ] 'am33xx_pm_rtc_setup()' allocates some resources that must be freed on the error. Commit 2152fbbd47c0 ("soc: ti: pm33xx: Simplify RTC usage to prepare to drop platform data") has introduced the use of these resources but has only updated the remove function. Fix the error handling path of the probe function now. Fixes: 2152fbbd47c0 ("soc: ti: pm33xx: Simplify RTC usage to prepare to drop platform data") Signed-off-by: Christophe JAILLET Signed-off-by: Santosh Shilimkar Signed-off-by: Sasha Levin commit 6880c7b9fef96ac5ed0bfc09e680136406decc40 Author: Dan Carpenter Date: Wed Jan 20 12:57:55 2021 +0300 soc: qcom: socinfo: Fix an off by one in qcom_show_pmic_model() [ Upstream commit 5fb33d8960dc7abdabc6fe599a30c2c99b082ef6 ] These need to be < ARRAY_SIZE() instead of <= ARRAY_SIZE() to prevent accessing one element beyond the end of the array. Acked-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Reviewed-by: Stephen Boyd Fixes: e9247e2ce577 ("soc: qcom: socinfo: fix printing of pmic_model") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YAf+o85Z9lgkq3Nw@mwanda Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ecf983364a52dd81b8d08abbf5e181f1c980fd70 Author: Robert Foss Date: Mon Dec 21 11:09:55 2020 +0100 arm64: dts: qcom: sdm845-db845c: Fix reset-pin of ov8856 node [ Upstream commit d4863ef399a29cae3001b3fedfd2864e651055ba ] Switch reset pin of ov8856 node from GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW, this issue prevented the ov8856 from probing properly as it did not respon to I2C messages. Fixes: d4919a44564b ("arm64: dts: qcom: sdm845-db845c: Add ov8856 & ov7251 camera nodes") Signed-off-by: Robert Foss Link: https://lore.kernel.org/r/20201221100955.148584-1-robert.foss@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 26cb0f69f13102eeb7cae2910ee4f6682b51db46 Author: Jack Pham Date: Mon Jan 18 09:46:39 2021 +0100 usb: gadget: u_audio: Free requests only after callback [ Upstream commit 7de8681be2cde9f6953d3be1fa6ce05f9fe6e637 ] As per the kernel doc for usb_ep_dequeue(), it states that "this routine is asynchronous, that is, it may return before the completion routine runs". And indeed since v5.0 the dwc3 gadget driver updated its behavior to place dequeued requests on to a cancelled list to be given back later after the endpoint is stopped. The free_ep() was incorrectly assuming that a request was ready to be freed after calling dequeue which results in a use-after-free in dwc3 when it traverses its cancelled list. Fix this by moving the usb_ep_free_request() call to the callback itself in case the ep is disabled. Fixes: eb9fecb9e69b0 ("usb: gadget: f_uac2: split out audio core") Reported-and-tested-by: Ferry Toth Reviewed-and-tested-by: Peter Chen Acked-by: Felipe Balbi Signed-off-by: Jack Pham Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210118084642.322510-2-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f5dae85e244ccfb5f70f63ddb2ca30a98765bd98 Author: Maximilian Luz Date: Fri Jan 15 10:48:18 2021 -0800 ACPICA: Fix exception code class checks [ Upstream commit 3dfaea3811f8b6a89a347e8da9ab862cdf3e30fe ] ACPICA commit 1a3a549286ea9db07d7ec700e7a70dd8bcc4354e The macros to classify different AML exception codes are broken. For instance, ACPI_ENV_EXCEPTION(Status) will always evaluate to zero due to #define AE_CODE_ENVIRONMENTAL 0x0000 #define ACPI_ENV_EXCEPTION(Status) (Status & AE_CODE_ENVIRONMENTAL) Similarly, ACPI_AML_EXCEPTION(Status) will evaluate to a non-zero value for error codes of type AE_CODE_PROGRAMMER, AE_CODE_ACPI_TABLES, as well as AE_CODE_AML, and not just AE_CODE_AML as the name suggests. This commit fixes those checks. Fixes: d46b6537f0ce ("ACPICA: AML Parser: ignore all exceptions resulting from incorrect AML during table load") Link: https://github.com/acpica/acpica/commit/1a3a5492 Signed-off-by: Maximilian Luz Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 531cd624a8f1a840e74d8bfd41a25f7a0b354b00 Author: Chen-Yu Tsai Date: Sun Jan 17 18:07:08 2021 +0800 arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node [ Upstream commit c6433083f5930fdf52ad47c8c0459719c810dc89 ] The gmac2phy is integrated with the PHY within the SoC. Any properties related to this integration can be included in the .dtsi file, instead of having board dts files specify them separately. Add the clock_in_out property to specify the direction of the PHY clock. This is the minimum required to have gmac2phy working on Linux. Other examples include assigned-clocks, assigned-clock-rates, and assigned-clock-parents properties, but the hardware default plus the implementation requesting the appropriate clock rate also works. Fixes: 9c4cc910fe28 ("ARM64: dts: rockchip: Add gmac2phy node support for rk3328") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20210117100710.4857-2-wens@kernel.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 4c85e843f100cbfd8a063064c4955c66637069d1 Author: Christophe JAILLET Date: Sun Jan 17 15:26:44 2021 +0100 cpufreq: brcmstb-avs-cpufreq: Fix resource leaks in ->remove() [ Upstream commit 3657f729b6fb5f2c0bf693742de2dcd49c572aa1 ] If 'cpufreq_unregister_driver()' fails, just WARN and continue, so that other resources are freed. Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Signed-off-by: Christophe JAILLET [ Viresh: Updated Subject ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 569ca6983eb072d96cc5d4b5390e6de502e2dfcf Author: Christophe JAILLET Date: Sun Jan 17 15:26:35 2021 +0100 cpufreq: brcmstb-avs-cpufreq: Free resources in error path [ Upstream commit 05f456286fd489558c72a4711d22a5612c965685 ] If 'cpufreq_register_driver()' fails, we must release the resources allocated in 'brcm_avs_prepare_init()' as already done in the remove function. To do that, introduce a new function 'brcm_avs_prepare_uninit()' in order to avoid code duplication. This also makes the code more readable (IMHO). Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Signed-off-by: Christophe JAILLET [ Viresh: Updated Subject ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e24ed826712a0952b448a624957e01347f28ff95 Author: Stephan Gerhold Date: Mon Jan 11 18:53:58 2021 +0100 arm64: dts: qcom: msm8916-samsung-a2015: Fix sensors [ Upstream commit 3716a583fe0bbe3babf4ce260064a7fa13d6d989 ] When the BMC150 accelerometer/magnetometer was added to the device tree, the sensors were working without specifying any regulator supplies, likely because the regulators were on by default and then never turned off. For some reason, this is no longer the case for pm8916_l17, which prevents the sensors from working in some cases. Now that the bmc150_accel/bmc150_magn drivers can enable necessary regulators, declare the necessary regulator supplies to make the sensors work again. Fixes: 079f81acf10f ("arm64: dts: qcom: msm8916-samsung-a2015: Add accelerometer/magnetometer") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210111175358.97171-1-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f15b9f27b21462a3cff185e402cc257364e8b4e9 Author: Andre Przywara Date: Wed Jan 13 15:26:28 2021 +0000 arm64: dts: allwinner: A64: Limit MMC2 bus frequency to 150 MHz [ Upstream commit 948c657cc45e8ce48cb533d4e2106145fa765759 ] In contrast to the H6 (and later) manuals, the A64 datasheet does not specify any limitations in the maximum possible frequency for eMMC controllers. However experimentation has found that a 150 MHz limit similar to other SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist for the MMC2 controller. Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi. The Pinebook seems to be the an odd exception, since it apparently seems to work with 200 MHz as well, so overwrite this in its board .dts file. Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works. Fixes: 22be992faea7 ("arm64: allwinner: a64: Increase the MMC max frequency") Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210113152630.28810-7-andre.przywara@arm.com Signed-off-by: Sasha Levin commit be6c9635e20065678c72fa611f5908345d83ab89 Author: Andre Przywara Date: Wed Jan 13 15:26:27 2021 +0000 arm64: dts: allwinner: H6: Allow up to 150 MHz MMC bus frequency [ Upstream commit cfe6c487b9a1abc6197714ec5605716a5428cf03 ] The H6 manual explicitly lists a frequency limit of 150 MHz for the bus frequency of the MMC controllers. So far we had no explicit limits in the DT, which limited eMMC to the spec defined frequencies, or whatever the driver defines (both Linux and FreeBSD use 52 MHz here). Put those maximum frequencies in the SoC .dtsi, to allow higher speed modes (which still would need to be explicitly enabled, per board). Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed 200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably. Fixes: 8f54bd1595b3 ("arm64: allwinner: h6: add device tree nodes for MMC controllers") Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210113152630.28810-6-andre.przywara@arm.com Signed-off-by: Sasha Levin commit c38f1590ffd4a96139dc431b75fabd6b5963c8df Author: Andre Przywara Date: Wed Jan 13 15:26:26 2021 +0000 arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card [ Upstream commit 941432d007689f3774646e41a1439228b6c6ee0e ] The SD card on the SoPine SoM module is somewhat concealed, so was originally defined as "non-removable". However there is a working card-detect pin (tested on two different SoM versions), and in certain SoM base boards it might be actually accessible at runtime. Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the non-removable flag, even though the SD card slot is perfectly accessible and usable there. (It turns out that just *my* board has a broken card detect switch, so I originally thought CD wouldn't work on the LTS.) Drop the "non-removable" flag to describe the SD card slot properly. Fixes: c3904a269891 ("arm64: allwinner: a64: add DTSI file for SoPine SoM") Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210113152630.28810-5-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 676153cae6dbc9aa9c7fe6596336e372e74d020b Author: Andre Przywara Date: Wed Jan 13 15:26:24 2021 +0000 arm64: dts: allwinner: H6: properly connect USB PHY to port 0 [ Upstream commit da2fb8457f71138d455cba82edec0d34f858e506 ] In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the H6 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: eabb3d424b6d ("arm64: dts: allwinner: h6: add USB2-related device nodes") Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210113152630.28810-3-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 71c4341db0dd7b219639c5e846f22f1d7fcce8c3 Author: Andre Przywara Date: Wed Jan 13 15:26:23 2021 +0000 arm64: dts: allwinner: A64: properly connect USB PHY to port 0 [ Upstream commit cc72570747e43335f4933a24dd74d5653639176a ] In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the A64 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. Remove the part from the Pinebook DTS which already had this property. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: dc03a047df1d ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI") Signed-off-by: Andre Przywara Acked-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210113152630.28810-2-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 0291e2c47f18123be13247e4195705198926e731 Author: Cristian Marussi Date: Tue Jan 12 19:13:26 2021 +0000 firmware: arm_scmi: Fix call site of scmi_notification_exit [ Upstream commit a90b6543bf062d65292b2c76f1630507d1c9d8ec ] Call scmi_notification_exit() only when SCMI platform driver instance has been really successfully removed. Link: https://lore.kernel.org/r/20210112191326.29091-1-cristian.marussi@arm.com Fixes: 6b8a69131dc63 ("firmware: arm_scmi: Enable notification core") Signed-off-by: Cristian Marussi [sudeep.holla: Move the call outside the list mutex locking] Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit acb6481ada90c53e0bf18501cdd8f5663d9f423c Author: Andrii Nakryiko Date: Mon Jan 11 23:55:15 2021 -0800 bpf: Avoid warning when re-casting __bpf_call_base into __bpf_call_base_args [ Upstream commit 6943c2b05bf09fd5c5729f7d7d803bf3f126cb9a ] BPF interpreter uses extra input argument, so re-casts __bpf_call_base into __bpf_call_base_args. Avoid compiler warning about incompatible function prototypes by casting to void * first. Fixes: 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter") Reported-by: kernel test robot Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210112075520.4103414-3-andrii@kernel.org Signed-off-by: Sasha Levin commit 040121ebd4aa0918b4b9f2aba6378697d0a85fda Author: Andrii Nakryiko Date: Mon Jan 11 23:55:14 2021 -0800 bpf: Add bpf_patch_call_args prototype to include/linux/bpf.h [ Upstream commit a643bff752dcf72a07e1b2ab2f8587e4f51118be ] Add bpf_patch_call_args() prototype. This function is called from BPF verifier and only if CONFIG_BPF_JIT_ALWAYS_ON is not defined. This fixes compiler warning about missing prototype in some kernel configurations. Fixes: 1ea47e01ad6e ("bpf: add support for bpf_call to interpreter") Reported-by: kernel test robot Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210112075520.4103414-2-andrii@kernel.org Signed-off-by: Sasha Levin commit ba46443062533c4f06327658e40e152c93518af8 Author: Martin Blumenstingl Date: Wed Jan 6 14:42:48 2021 +0100 net: stmmac: dwmac-meson8b: fix enabling the timing-adjustment clock [ Upstream commit 025822884a4fd2d0af51dcf77ddc494e60c5ff63 ] The timing-adjustment clock only has to be enabled when a) there is a 2ns RX delay configured using device-tree and b) the phy-mode indicates that the RX delay should be enabled. Only enable the RX delay if both are true, instead of (by accident) also enabling it when there's the 2ns RX delay configured but the phy-mode incicates that the RX delay is not used. Fixes: 9308c47640d515 ("net: stmmac: dwmac-meson8b: add support for the RX delay configuration") Reported-by: Andrew Lunn Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: Martin Blumenstingl Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6c4038e221ba039aa4382aae236b50c7b55f590f Author: Stephan Gerhold Date: Wed Jan 6 11:21:34 2021 +0100 arm64: dts: qcom: msm8916-samsung-a5u: Fix iris compatible [ Upstream commit 826e6faf49ae1eb065759a30832a2e34740bd8b1 ] Unlike most MSM8916 boards, samsung-a5u uses WCN3660B instead of WCN3620 to support the 5 GHz band additionally. WCN3660B has similar requirements as WCN3620, but it needs the XO clock to run at 48 MHz instead of 19.2 MHz. So far it was possible to describe that configuration using the qcom,wcn3680 compatible. However, as of commit 8490987bdb9a ("wcn36xx: Hook and identify RF_IRIS_WCN3680"), the wcn36xx driver will now use the qcom,wcn3680 compatible to enable functionality specific to WCN3680. In particular, WCN3680 supports 802.11ac, which is not available in WCN3660B. Use the new qcom,wcn3660b compatible to describe the chip properly. Fixes: 0d7051999175 ("arm64: dts: msm8916-samsung-a5u: Override iris compatible") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210106102134.59801-4-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 02c4cff31a60f3425625ff7dc0f04b1d29245c2b Author: Phil Elwell Date: Tue Jan 5 16:20:29 2021 +0000 staging: vchiq: Fix bulk transfers on 64-bit builds [ Upstream commit 88753cc19f087abe0d39644b844e67a59cfb5a3d ] The recent change to the bulk transfer compat function missed the fact the relevant ioctl command is VCHIQ_IOC_QUEUE_BULK_TRANSMIT32, not VCHIQ_IOC_QUEUE_BULK_TRANSMIT, as any attempt to send a bulk block to the VPU would have shown. Fixes: a4367cd2b231 ("staging: vchiq: convert compat bulk transfer") Acked-by: Arnd Bergmann Acked-by: Dan Carpenter Signed-off-by: Phil Elwell Link: https://lore.kernel.org/r/20210105162030.1415213-3-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 27af7c0ce2cfcca6332cbd8145c9e8b3cbfa5b63 Author: Phil Elwell Date: Tue Jan 5 16:20:28 2021 +0000 staging: vchiq: Fix bulk userdata handling [ Upstream commit 96ae327678eceabf455b11a88ba14ad540d4b046 ] The addition of the local 'userdata' pointer to vchiq_irq_queue_bulk_tx_rx omitted the case where neither BLOCKING nor WAITING modes are used, in which case the value provided by the caller is not returned to them as expected, but instead it is replaced with a NULL. This lack of a suitable context may cause the application to crash or otherwise malfunction. Fixes: 4184da4f316a ("staging: vchiq: fix __user annotations") Tested-by: Stefan Wahren Acked-by: Dan Carpenter Signed-off-by: Phil Elwell Link: https://lore.kernel.org/r/20210105162030.1415213-2-phil@raspberrypi.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8c02ace8bb0b08e4d0e54cfefb7443f29c336d2f Author: Dinghao Liu Date: Sat Jan 2 13:47:55 2021 +0800 Bluetooth: hci_qca: Fix memleak in qca_controller_memdump [ Upstream commit 71f8e707557b9bc25dc90a59a752528d4e7c1cbf ] When __le32_to_cpu() fails, qca_memdump should be freed just like when vmalloc() fails. Fixes: d841502c79e3f ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by: Dinghao Liu Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 9518446edbf7c8fc79c1b07dda6fb106df7106dc Author: Zhang Qilong Date: Mon Nov 23 18:21:18 2020 +0800 memory: mtk-smi: Fix PM usage counter unbalance in mtk_smi ops [ Upstream commit a2d522ff0f5cc26915c4ccee9457fd4b4e1edc48 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 4f0a1a1ae3519 ("memory: mtk-smi: Invoke pm runtime_callback to enable clocks") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20201123102118.3866195-1-zhangqilong3@huawei.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit c4fd0fe67821fdb83388290539610d07dea7ed4b Author: Krzysztof Kozlowski Date: Thu Dec 10 22:29:02 2020 +0100 arm64: dts: exynos: correct PMIC interrupt trigger level on Espresso [ Upstream commit 1fea2eb2f5bbd3fbbe2513d2386b5f6e6db17fd7 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212903.216728-8-krzk@kernel.org Signed-off-by: Sasha Levin commit 30cb404b0f2d9d5930bd10149df4f15b2d4ccaa4 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:29:01 2020 +0100 arm64: dts: exynos: correct PMIC interrupt trigger level on TM2 [ Upstream commit e98e2367dfb4b6d7a80c8ce795c644124eff5f36 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-7-krzk@kernel.org Signed-off-by: Sasha Levin commit d65d2e5b9ae0fef8909490ec5678f4730955f8d6 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:29:00 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family [ Upstream commit 3e7d9a583a24f7582c6bc29a0d4d624feedbc2f9 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: aac4e0615341 ("ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-6-krzk@kernel.org Signed-off-by: Sasha Levin commit 993242508e74abca0b88d7721ff6279d1532281f Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:59 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa [ Upstream commit 1ac8893c4fa3d4a34915dc5cdab568a39db5086c ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 1fed2252713e ("ARM: dts: fix pinctrl for s2mps11-irq on exynos5420-arndale-octa") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-5-krzk@kernel.org Signed-off-by: Sasha Levin commit 84f2a2b2ad82eb87a9735a2fdb3579e085294461 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:58 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Spring [ Upstream commit 77e6a5467cb8657cf8b5e610a30a4c502085e4f9 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 53dd4138bb0a ("ARM: dts: Add exynos5250-spring device tree") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212903.216728-4-krzk@kernel.org Signed-off-by: Sasha Levin commit dedc8753b8fdfda04c01a067a5c8faee52b94291 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:57 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato [ Upstream commit 437ae60947716bb479e2f32466f49445c0509b1e ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: faaf348ef468 ("ARM: dts: Add board dts file for exynos3250-rinato") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-3-krzk@kernel.org Signed-off-by: Sasha Levin commit d834133f637f688d01382a7fef9ee298c8dee1e5 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:56 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Monk [ Upstream commit 8528cda2b7c667e9cd173aef1a677c71b7d5a096 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: e0cefb3f79d3 ("ARM: dts: add board dts file for Exynos3250-based Monk board") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212903.216728-2-krzk@kernel.org Signed-off-by: Sasha Levin commit 306fb69bdcf0480764f2fff5a883ef238a8b2ec3 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:55 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5 [ Upstream commit cb31334687db31c691901269d65074a7ffaecb18 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: b004a34bd0ff ("ARM: dts: exynos: Add exynos3250-artik5 dtsi file for ARTIK5 module") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-1-krzk@kernel.org Signed-off-by: Sasha Levin commit f4b2c1c919c781d66361d13bded20acc44bb2cc1 Author: Adam Ford Date: Sun Dec 13 12:37:45 2020 -0600 arm64: dts: renesas: beacon: Fix audio-1.8V pin enable [ Upstream commit 5a5da0b758b327b727c5392d7f11e046e113a195 ] The fact the audio worked at all was a coincidence because the wrong gpio enable was used. Use the correct GPIO pin to ensure its operation. Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit") Signed-off-by: Adam Ford Link: https://lore.kernel.org/r/20201213183759.223246-6-aford173@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 3a88bfec24f20b4ccbdc887a9ecb091cef280056 Author: Adam Ford Date: Sun Dec 13 12:37:42 2020 -0600 arm64: dts: renesas: beacon kit: Fix choppy Bluetooth Audio [ Upstream commit db030c5a9658846a42fbed4d43a8b5f28a2d7ab7 ] The Bluetooth chip is capable of operating at 4Mbps, but the max-speed setting was on the UART node instead of the Bluetooth node, so the chip didn't operate at the correct speed resulting in choppy audio. Fix this by setting the max-speed in the proper node. Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit") Signed-off-by: Adam Ford Link: https://lore.kernel.org/r/20201213183759.223246-3-aford173@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 60d3aa7d428941431b123b47cadd1d88ccf5d900 Author: Christopher William Snowhill Date: Sat Dec 26 19:12:32 2020 -0800 Bluetooth: Fix initializing response id after clearing struct [ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ] Looks like this was missed when patching the source to clear the structures throughout, causing this one instance to clear the struct after the response id is assigned. Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members") Signed-off-by: Christopher William Snowhill Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 0db3cb59cc0d63eace63755b9e903bd195a60d9f Author: Claire Chang Date: Mon Dec 14 15:29:21 2020 +0800 Bluetooth: hci_uart: Fix a race for write_work scheduling [ Upstream commit afe0b1c86458f121b085271e4f3034017a90d4a3 ] In hci_uart_write_work, there is a loop/goto checking the value of HCI_UART_TX_WAKEUP. If HCI_UART_TX_WAKEUP is set again, it keeps trying hci_uart_dequeue; otherwise, it clears HCI_UART_SENDING and returns. In hci_uart_tx_wakeup, if HCI_UART_SENDING is already set, it sets HCI_UART_TX_WAKEUP, skips schedule_work and assumes the running/pending hci_uart_write_work worker will do hci_uart_dequeue properly. However, if the HCI_UART_SENDING check in hci_uart_tx_wakeup is done after the loop breaks, but before HCI_UART_SENDING is cleared in hci_uart_write_work, the schedule_work is skipped incorrectly. Fix this race by changing the order of HCI_UART_SENDING and HCI_UART_TX_WAKEUP modification. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 82f5169bf3d3 ("Bluetooth: hci_uart: add serdev driver support library") Signed-off-by: Claire Chang Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 952f507a7336876b038589d486eb9035bb8d4986 Author: Christophe JAILLET Date: Sat Dec 12 10:46:58 2020 +0100 Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function [ Upstream commit 9a39a927be01d89e53f04304ab99a8761e08910d ] Some resource should be released in the error handling path of the probe function, as already done in the remove function. The remove function was fixed in commit 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Christophe JAILLET Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 7057811e9d332437070a812b12a95a5ffac539ba Author: Rakesh Pillai Date: Sat Dec 12 00:30:10 2020 +0530 ath10k: Fix error handling in case of CE pipe init failure [ Upstream commit 31561e8557cd1eeba5806ac9ce820f8323b2201b ] Currently if the copy engine pipe init fails for snoc based chipsets, the rri is not freed. Fix this error handling for copy engine pipe init failure. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1 Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990") Signed-off-by: Rakesh Pillai Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1607713210-18320-1-git-send-email-pillair@codeaurora.org Signed-off-by: Sasha Levin commit 52fc4fec3204f31119f31c083923bf0460dba0e3 Author: Chris Wilson Date: Tue Jan 19 11:07:57 2021 +0000 drm/i915/gt: One more flush for Baytrail clear residuals commit e627d5923cae93fa4188f4c4afba6486169a1337 upstream. CI reports that Baytail requires one more invalidate after CACHE_MODE for it to be happy. Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Akeem G Abodunrin Reviewed-by: Mika Kuoppala Reviewed-by: Akeem G Abodunrin Cc: Hans de Goede Cc: Diego Calleja Link: https://patchwork.freedesktop.org/patch/msgid/20210119110802.22228-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit 0a01909195a83856819d0dc4c13456bc704f5098 Author: Takashi Iwai Date: Sat Feb 6 21:36:55 2021 +0100 ALSA: pcm: Don't call sync_stop if it hasn't been stopped commit 700cb70730777c159a988e01daa93f20a1ae9b58 upstream. The PCM stop operation sets the stop_operating flag for indicating the sync_stop post-process. This flag is, however, set unconditionally even if the PCM trigger weren't issued. This may lead to inconsistency in the driver side. Correct the code to set stop_operating flag only after the trigger STOP is actually called. Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation") Cc: Link: https://lore.kernel.org/r/20210206203656.15959-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 312086e9f4497de1c7c23797e60aa5e9e02cbee3 Author: Takashi Iwai Date: Sat Feb 6 21:36:54 2021 +0100 ALSA: pcm: Assure sync with the pending stop operation at suspend commit 2c87c1a49c9d113a9f3e8e951d7d64be5ff50ac1 upstream. The current PCM code calls the sync_stop at the resume action due to the analogy to the PCM prepare call pattern. But, it makes little sense, as the sync should have been done rather at the suspend time, not at the resume time. This patch corrects the sync_stop call at suspend/resume to assure the sync before finishing the suspend. Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation") Cc: Link: https://lore.kernel.org/r/20210206203656.15959-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3a13ee9801be6e75a7c25e8bed4d8261e524a989 Author: Takashi Iwai Date: Sat Feb 6 21:36:53 2021 +0100 ALSA: pcm: Call sync_stop at disconnection commit 29bb274e94974669acb5186a75538f20df1508b6 upstream. The PCM core should perform the sync for the pending stop operations at disconnection. Otherwise it may lead to unexpected access. Currently the old user of sync_stop, USB-audio driver, has its own sync, so this isn't needed, but it's better to guarantee the sync in the PCM core level. This patch adds the missing sync_stop call at PCM disconnection callback. It also assures the IRQ sync if it's specified in the card. snd_pcm_sync_stop() is slightly modified to be called also for any PCM substream object now. Fixes: 1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation") Cc: Link: https://lore.kernel.org/r/20210206203656.15959-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 10109dadef44e607557eb0edf22063d8b143a5ba Author: Eric Biggers Date: Tue Jan 12 11:28:18 2021 -0800 random: fix the RNDRESEEDCRNG ioctl commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream. The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead. Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG") Cc: stable@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: Andy Lutomirski Cc: Jann Horn Cc: Theodore Ts'o Reviewed-by: Jann Horn Acked-by: Ard Biesheuvel Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20210112192818.69921-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2396480071a8d1d3e8be2a7c4c9704fb31234a9a Author: Nathan Chancellor Date: Fri Jan 29 17:46:51 2021 -0700 vmlinux.lds.h: Define SANTIZER_DISCARDS with CONFIG_GCOV_KERNEL=y commit f5b6a74d9c08b19740ca056876bf6584acdba582 upstream. clang produces .eh_frame sections when CONFIG_GCOV_KERNEL is enabled, even when -fno-asynchronous-unwind-tables is in KBUILD_CFLAGS: $ make CC=clang vmlinux ... ld: warning: orphan section `.eh_frame' from `init/main.o' being placed in section `.eh_frame' ld: warning: orphan section `.eh_frame' from `init/version.o' being placed in section `.eh_frame' ld: warning: orphan section `.eh_frame' from `init/do_mounts.o' being placed in section `.eh_frame' ld: warning: orphan section `.eh_frame' from `init/do_mounts_initrd.o' being placed in section `.eh_frame' ld: warning: orphan section `.eh_frame' from `init/initramfs.o' being placed in section `.eh_frame' ld: warning: orphan section `.eh_frame' from `init/calibrate.o' being placed in section `.eh_frame' ld: warning: orphan section `.eh_frame' from `init/init_task.o' being placed in section `.eh_frame' ... $ rg "GCOV_KERNEL|GCOV_PROFILE_ALL" .config CONFIG_GCOV_KERNEL=y CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y CONFIG_GCOV_PROFILE_ALL=y This was already handled for a couple of other options in commit d812db78288d ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections") and there is an open LLVM bug for this issue. Take advantage of that section for this config as well so that there are no more orphan warnings. Link: https://bugs.llvm.org/show_bug.cgi?id=46478 Link: https://github.com/ClangBuiltLinux/linux/issues/1069 Reported-by: kernel test robot Reviewed-by: Fangrui Song Reviewed-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Fixes: d812db78288d ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210130004650.2682422-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7c86f1c38fae230e4279c85ad164eb4434eb095d Author: Alexander Lobakin Date: Sun Jan 10 11:56:08 2021 +0000 MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section commit 8ac7c87acdcac156670f9920c8acbd84308ff4b1 upstream. MIPS uses its own declaration of rwdata, and thus it should be kept in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is missing from the linker script, which emits the following ld warnings: mips-alpine-linux-musl-ld: warning: orphan section `.data..page_aligned' from `arch/mips/kernel/vdso.o' being placed in section `.data..page_aligned' mips-alpine-linux-musl-ld: warning: orphan section `.data..page_aligned' from `arch/mips/vdso/vdso-image.o' being placed in section `.data..page_aligned' Add the necessary declaration, so the mentioned structures will be placed in vmlinux as intended: ffffffff80630580 D __end_once ffffffff80630580 D __start___dyndbg ffffffff80630580 D __start_once ffffffff80630580 D __stop___dyndbg ffffffff80634000 d mips_vdso_data ffffffff80638000 d vdso_data ffffffff80638580 D _gp ffffffff8063c000 T __init_begin ffffffff8063c000 D _edata ffffffff8063c000 T _sinittext -> ffffffff805a4000 D __end_init_task ffffffff805a4000 D __nosave_begin ffffffff805a4000 D __nosave_end ffffffff805a4000 d mips_vdso_data ffffffff805a8000 d vdso_data ffffffff805ac000 D mmlist_lock ffffffff805ac080 D tasklist_lock Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: Alexander Lobakin Reviewed-by: Kees Cook Reviewed-by: Nathan Chancellor Cc: stable@vger.kernel.org # 4.4+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit d5ef4d3ab63d4a4c11b0d60628f9a977694ce070 Author: Rokudo Yan Date: Thu Feb 25 17:18:31 2021 -0800 zsmalloc: account the number of compacted pages correctly commit 2395928158059b8f9858365fce7713ce7fef62e4 upstream. There exists multiple path may do zram compaction concurrently. 1. auto-compaction triggered during memory reclaim 2. userspace utils write zram/compaction node So, multiple threads may call zs_shrinker_scan/zs_compact concurrently. But pages_compacted is a per zsmalloc pool variable and modification of the variable is not serialized(through under class->lock). There are two issues here: 1. the pages_compacted may not equal to total number of pages freed(due to concurrently add). 2. zs_shrinker_scan may not return the correct number of pages freed(issued by current shrinker). The fix is simple: 1. account the number of pages freed in zs_compact locally. 2. use actomic variable pages_compacted to accumulate total number. Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-yan@tcl.com Fixes: 860c707dca155a56 ("zsmalloc: account the number of compacted pages") Signed-off-by: Rokudo Yan Cc: Minchan Kim Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bb53cc29a90f9bb9f280287250b59a394a85472d Author: Takashi Iwai Date: Fri Feb 5 15:45:59 2021 +0100 ALSA: usb-audio: Fix PCM buffer allocation in non-vmalloc mode commit fb3c293b82c31a9a68fbcf4e7a45fadd8a47ea2b upstream. The commit f274baa49be6 ("ALSA: usb-audio: Allow non-vmalloc buffer for PCM buffers") introduced the mode to allocate coherent pages for PCM buffers, and it used bus->controller device as its DMA device. It turned out, however, that bus->sysdev is a more appropriate device to be used for DMA mapping in HCD code. This patch corrects the device reference accordingly. Note that, on most platforms, both point to the very same device, hence this patch doesn't change anything practically. But on platforms like xhcd-plat hcd, the change becomes effective. Fixes: f274baa49be6 ("ALSA: usb-audio: Allow non-vmalloc buffer for PCM buffers") Cc: Link: https://lore.kernel.org/r/20210205144559.29555-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 44308ca9d0f7191e6285dc94cb25b23de67cf6a6 Author: Jan Kara Date: Fri Jun 5 16:16:16 2020 +0200 bfq: Avoid false bfq queue merging commit 41e76c85660c022c6bf5713bfb6c21e64a487cec upstream. bfq_setup_cooperator() uses bfqd->in_serv_last_pos so detect whether it makes sense to merge current bfq queue with the in-service queue. However if the in-service queue is freshly scheduled and didn't dispatch any requests yet, bfqd->in_serv_last_pos is stale and contains value from the previously scheduled bfq queue which can thus result in a bogus decision that the two queues should be merged. This bug can be observed for example with the following fio jobfile: [global] direct=0 ioengine=sync invalidate=1 size=1g rw=read [reader] numjobs=4 directory=/mnt where the 4 processes will end up in the one shared bfq queue although they do IO to physically very distant files (for some reason I was able to observe this only with slice_idle=1ms setting). Fix the problem by invalidating bfqd->in_serv_last_pos when switching in-service queue. Fixes: 058fdecc6de7 ("block, bfq: fix in-service-queue check for queue merging") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Acked-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 13a2b18f1c47dcb95e9f1acdebdc78edcfcb5d90 Author: Hans de Goede Date: Thu Jan 21 16:07:54 2021 +0100 virt: vbox: Do not use wait_event_interruptible when called from kernel context commit c35901b39ddc20077f4ae7b9f7bf344487f62212 upstream. Do not use wait_event_interruptible when vbg_hgcm_call() gets called from kernel-context, such as it being called by the vboxsf filesystem code. This fixes some filesystem related system calls on shared folders unexpectedly failing with -EINTR. Fixes: 0532a1b0d045 ("virt: vbox: Implement passing requestor info to the host for VirtualBox 6.0.x") Reported-by: Ludovic Pouzenc Signed-off-by: Hans de Goede Cc: stable Link: https://lore.kernel.org/r/20210121150754.147598-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit 9889d3fc52a8ef4e75705e52fec278e23def246d Author: Ard Biesheuvel Date: Sat Jan 9 10:53:53 2021 +0100 PCI: Decline to resize resources if boot config must be preserved commit 729e3a669d1b62e9876a671ac03ccba399a23b68 upstream. The _DSM #5 method in the ACPI host bridge object tells us whether the OS must preserve the resource assignments done by firmware. If this is the case, we should not permit drivers to resize BARs on the fly. Make pci_resize_resource() take this into account. Link: https://lore.kernel.org/r/20210109095353.13417-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Greg Kroah-Hartman commit b85cb142366aac3ade8709d27bc9abfed9033648 Author: Ansuel Smith Date: Mon Oct 19 18:55:55 2020 +0200 PCI: qcom: Use PHY_REFCLK_USE_PAD only for ipq8064 commit 2cfef1971aea6119ee27429181d6cb3383031ac2 upstream. The use of PHY_REFCLK_USE_PAD introduced a regression for apq8064 devices. It was tested that while apq doesn't require the padding, ipq SoC must use it or the kernel hangs on boot. Link: https://lore.kernel.org/r/20201019165555.8269-1-ansuelsmth@gmail.com Fixes: de3c4bf64897 ("PCI: qcom: Add support for tx term offset for rev 2.1.0") Reported-by: Ilia Mirkin Signed-off-by: Ilia Mirkin Signed-off-by: Ansuel Smith Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman commit 9e9de58b0f9bf2cadcf359a93741f7e9b43b454a Author: Ivan Zaentsev Date: Thu Jan 21 12:30:21 2021 +0300 w1: w1_therm: Fix conversion result for negative temperatures commit 2f6055c26f1913763eabc66c7c27d0693561e966 upstream. DS18B20 device driver returns an incorrect value for negative temperatures due to a missing sign-extension in w1_DS18B20_convert_temp(). Fix by using s16 temperature value when converting to int. Fixes: 9ace0b4dab1c (w1: w1_therm: Add support for GXCAS GX20MH01 device.) Cc: stable Reported-by: Paweł Marciniak Signed-off-by: Ivan Zaentsev Link: https://lore.kernel.org/r/20210121093021.224764-1-ivan.zaentsev@wirenboard.ru Signed-off-by: Greg Kroah-Hartman commit 859aafbd9dbc24053cb85da03644f6e01949d5b8 Author: Sumit Garg Date: Fri Jan 22 16:35:56 2021 +0530 kdb: Make memory allocations more robust commit 93f7a6d818deef69d0ba652d46bae6fbabbf365c upstream. Currently kdb uses in_interrupt() to determine whether its library code has been called from the kgdb trap handler or from a saner calling context such as driver init. This approach is broken because in_interrupt() alone isn't able to determine kgdb trap handler entry from normal task context. This can happen during normal use of basic features such as breakpoints and can also be trivially reproduced using: echo g > /proc/sysrq-trigger We can improve this by adding check for in_dbg_master() instead which explicitly determines if we are running in debugger context. Cc: stable@vger.kernel.org Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/1611313556-4004-1-git-send-email-sumit.garg@linaro.org Signed-off-by: Daniel Thompson Signed-off-by: Greg Kroah-Hartman commit a2fb4fa45ff3df61fc039b2129daf4d399259b38 Author: Quinn Tran Date: Mon Jan 11 01:31:32 2021 -0800 scsi: qla2xxx: Fix mailbox Ch erroneous error commit 044c218b04503858ca4e17f61899c8baa0ae9ba1 upstream. Mailbox Ch/dump ram extend expects mb register 10 to be set. If not set/clear, firmware can pick up garbage from previous invocation of this mailbox. Example: mctp dump can set mb10. On subsequent flash read which use mailbox cmd Ch, mb10 can retain previous value. Link: https://lore.kernel.org/r/20210111093134.1206-6-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c9f0028b73a2a95302457f502b4de4c4644e8a92 Author: Ahmed S. Darwish Date: Mon Jan 18 11:09:37 2021 +0100 scsi: libsas: docs: Remove notify_ha_event() commit 3f901c81dfad6930de5d4e6b582c4fde880cdada upstream. The ->notify_ha_event() hook has long been removed from the libsas event interface. Remove it from documentation. Link: https://lore.kernel.org/r/20210118100955.1761652-2-a.darwish@linutronix.de Fixes: 042ebd293b86 ("scsi: libsas: kill useless ha_event and do some cleanup") Cc: stable@vger.kernel.org Reviewed-by: John Garry Reviewed-by: Jack Wang Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 03836bf2eb84760bc6dff2df4ad04f0b4ccc4384 Author: Dave Jiang Date: Wed Feb 10 13:16:11 2021 -0700 driver core: auxiliary bus: Fix calling stage for auxiliary bus init commit 471b12c43f376d5203dbff0e91316eea11f6f4df upstream. When the auxiliary device code is built into the kernel, it can be executed before the auxiliary bus is registered. This causes bus->p to be not allocated and triggers a NULL pointer dereference when the auxiliary bus device gets added with bus_add_device(). Call the auxiliary_bus_init() under driver_init() so the bus is initialized before devices. Below is the kernel splat for the bug: [ 1.948215] BUG: kernel NULL pointer dereference, address: 0000000000000060 [ 1.950670] #PF: supervisor read access in kernel mode [ 1.950670] #PF: error_code(0x0000) - not-present page [ 1.950670] PGD 0 [ 1.950670] Oops: 0000 1 SMP NOPTI [ 1.950670] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-intel-nextsvmtest+ #2205 [ 1.950670] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1.950670] RIP: 0010:bus_add_device+0x64/0x140 [ 1.950670] Code: 00 49 8b 75 20 48 89 df e8 59 a1 ff ff 41 89 c4 85 c0 75 7b 48 8b 53 50 48 85 d2 75 03 48 8b 13 49 8b 85 a0 00 00 00 48 89 de <48> 8 78 60 48 83 c7 18 e8 ef d9 a9 ff 41 89 c4 85 c0 75 45 48 8b [ 1.950670] RSP: 0000:ff46032ac001baf8 EFLAGS: 00010246 [ 1.950670] RAX: 0000000000000000 RBX: ff4597f7414aa680 RCX: 0000000000000000 [ 1.950670] RDX: ff4597f74142bbc0 RSI: ff4597f7414aa680 RDI: ff4597f7414aa680 [ 1.950670] RBP: ff46032ac001bb10 R08: 0000000000000044 R09: 0000000000000228 [ 1.950670] R10: ff4597f741141b30 R11: ff4597f740182a90 R12: 0000000000000000 [ 1.950670] R13: ffffffffa5e936c0 R14: 0000000000000000 R15: 0000000000000000 [ 1.950670] FS: 0000000000000000(0000) GS:ff4597f7bba00000(0000) knlGS:0000000000000000 [ 1.950670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.950670] CR2: 0000000000000060 CR3: 000000002140c001 CR4: 0000000000f71ef0 [ 1.950670] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.950670] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1.950670] PKRU: 55555554 [ 1.950670] Call Trace: [ 1.950670] device_add+0x3ee/0x850 [ 1.950670] __auxiliary_device_add+0x47/0x60 [ 1.950670] idxd_pci_probe+0xf77/0x1180 [ 1.950670] local_pci_probe+0x4a/0x90 [ 1.950670] pci_device_probe+0xff/0x1b0 [ 1.950670] really_probe+0x1cf/0x440 [ 1.950670] ? rdinit_setup+0x31/0x31 [ 1.950670] driver_probe_device+0xe8/0x150 [ 1.950670] device_driver_attach+0x58/0x60 [ 1.950670] __driver_attach+0x8f/0x150 [ 1.950670] ? device_driver_attach+0x60/0x60 [ 1.950670] ? device_driver_attach+0x60/0x60 [ 1.950670] bus_for_each_dev+0x79/0xc0 [ 1.950670] ? kmem_cache_alloc_trace+0x323/0x430 [ 1.950670] driver_attach+0x1e/0x20 [ 1.950670] bus_add_driver+0x154/0x1f0 [ 1.950670] driver_register+0x70/0xc0 [ 1.950670] __pci_register_driver+0x54/0x60 [ 1.950670] idxd_init_module+0xe2/0xfc [ 1.950670] ? idma64_platform_driver_init+0x19/0x19 [ 1.950670] do_one_initcall+0x4a/0x1e0 [ 1.950670] kernel_init_freeable+0x1fc/0x25c [ 1.950670] ? rest_init+0xba/0xba [ 1.950670] kernel_init+0xe/0x116 [ 1.950670] ret_from_fork+0x1f/0x30 [ 1.950670] Modules linked in: [ 1.950670] CR2: 0000000000000060 [ 1.950670] --[ end trace cd7d1b226d3ca901 ]-- Fixes: 7de3697e9cbd ("Add auxiliary bus support") Reported-by: Jacob Pan Reviewed-by: Dan Williams Acked-by: Dave Ertman Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/20210210201611.1611074-1-dave.jiang@intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit d28808692e5dd0fffe271689f6ac30b63c29685a Author: Greg Kroah-Hartman Date: Thu Feb 18 11:08:18 2021 +0100 debugfs: do not attempt to create a new file before the filesystem is initalized commit 56348560d495d2501e87db559a61de717cd3ab02 upstream. Some subsystems want to add debugfs files at early boot, way before debugfs is initialized. This seems to work somehow as the vfs layer will not allow it to happen, but let's be explicit and test to ensure we are properly up and running before allowing files to be created. Cc: "Rafael J. Wysocki" Cc: stable Reported-by: Michael Walle Reported-by: Marc Zyngier Link: https://lore.kernel.org/r/20210218100818.3622317-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit b874082027b5a8ede43f96e8dc9e1bcd8e10a94c Author: Greg Kroah-Hartman Date: Thu Feb 18 11:08:17 2021 +0100 debugfs: be more robust at handling improper input in debugfs_lookup() commit bc6de804d36b3709d54fa22bd128cbac91c11526 upstream. debugfs_lookup() doesn't like it if it is passed an illegal name pointer, or if the filesystem isn't even initialized yet. If either of these happen, it will crash the system, so fix it up by properly testing for valid input and that we are up and running before trying to find a file in the filesystem. Cc: "Rafael J. Wysocki" Cc: stable Reported-by: Michael Walle Tested-by: Michael Walle Tested-by: Marc Zyngier Link: https://lore.kernel.org/r/20210218100818.3622317-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit cdb43e00d9daf1355e140bff6a844588acebb1b7 Author: Stefano Garzarella Date: Mon Feb 8 17:17:41 2021 +0100 vdpa/mlx5: fix param validation in mlx5_vdpa_get_config() commit dcfde1635e764fd69cc756c7780d144e288608e9 upstream. It's legal to have 'offset + len' equal to sizeof(struct virtio_net_config), since 'ndev->config' is a 'struct virtio_net_config', so we can safely copy its content under this condition. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Cc: stable@vger.kernel.org Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20210208161741.104939-1-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Acked-by: Eli Cohen Signed-off-by: Greg Kroah-Hartman commit 572e2b02ea91e060add65abe415e25e23d2b0f12 Author: Nick Desaulniers Date: Fri Feb 5 12:22:18 2021 -0800 vmlinux.lds.h: add DWARF v5 sections commit 3c4fa46b30c551b1df2fb1574a684f68bc22067c upstream. We expect toolchains to produce these new debug info sections as part of DWARF v5. Add explicit placements to prevent the linker warnings from --orphan-section=warn. Compilers may produce such sections with explicit -gdwarf-5, or based on the implicit default version of DWARF when -g is used via DEBUG_INFO. This implicit default changes over time, and has changed to DWARF v5 with GCC 11. .debug_sup was mentioned in review, but without compilers producing it today, let's wait to add it until it becomes necessary. Cc: stable@vger.kernel.org Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707 Reported-by: Chris Murphy Suggested-by: Fangrui Song Reviewed-by: Nathan Chancellor Reviewed-by: Mark Wielaard Tested-by: Sedat Dilek Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman