MISC:https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2
Download: text/plain
Original: cdn.kernel.org archive.org
commit d49914ee4ec93d58d90a12275a814415c189059c Author: Greg Kroah-Hartman <[email protected]> Date: Wed Aug 17 15:16:21 2022 +0200 Linux 5.19.2 Link: https://lore.kernel.org/r/[email protected] Tested-by: Shuah Khan <[email protected]> Tested-by: Ronald Warsow <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Tested-by: Ron Economos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Guenter Roeck <[email protected]> Tested-by: Jiri Slaby <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 95b05bd36fe017e30cd1405c7750768f63715cf9 Author: Paul Chaignon <[email protected]> Date: Mon Jul 25 16:31:58 2022 +0200 vxlan: Use ip_tunnel_key flow flags in route lookups commit 7e2fb8bc7ef6c7a63ca95751b90162dece0b3f4c upstream. Use the new ip_tunnel_key field with the flow flags in the IPv4 route lookups for the encapsulated packet. This will be used by the bpf_skb_set_tunnel_key helper in a subsequent commit. Signed-off-by: Paul Chaignon <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]valent.com Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3229787d4ee8cd70872c85f2297370b6eb87b63f Author: Paul Chaignon <[email protected]> Date: Mon Jul 25 16:32:15 2022 +0200 geneve: Use ip_tunnel_key flow flags in route lookups commit 861396ac0b47780210b72c4fea359540965a4970 upstream. Use the new ip_tunnel_key field with the flow flags in the IPv4 route lookups for the encapsulated packet. This will be used by the bpf_skb_set_tunnel_key helper in the subsequent commit. Signed-off-by: Paul Chaignon <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Nikolay Aleksandrov <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]valent.com Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 49a407af0c52d760b34579e50a63aa85134c90ee Author: Amadeusz Sławiński <[email protected]> Date: Fri Jul 22 13:19:59 2022 +0200 ASoC: Intel: avs: Use lookup table to create modules commit 1e744351bcb9c4cee81300de5a6097100d835386 upstream. As reported by Nathan, when building avs driver using clang with: CONFIG_COMPILE_TEST=y CONFIG_FORTIFY_SOURCE=y CONFIG_KASAN=y CONFIG_PCI=y CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y CONFIG_SND_SOC_INTEL_AVS=y there are reports of too big stack use, like: sound/soc/intel/avs/path.c:815:18: error: stack frame size (2176) exceeds limit (2048) in 'avs_path_create' [-Werror,-Wframe-larger-than] struct avs_path *avs_path_create(struct avs_dev *adev, u32 dma_id, ^ 1 error generated. This is apparently caused by inlining many calls to guid_equal which inlines fortified memcpy, using 2 size_t variables. Instead of hardcoding many calls to guid_equal, use lookup table with one call, this improves stack usage. Link: https://lore.kernel.org/alsa-devel/[email protected]/T/ Link: https://github.com/ClangBuiltLinux/linux/issues/1642 Signed-off-by: Amadeusz Sławiński <[email protected]> Reported-by: Nathan Chancellor <[email protected]> Build-tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Cezary Rojewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Cc: Naresh Kamboju <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8422e81ff42d996e397dd413634a026af3169b27 Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Aug 1 13:52:07 2022 -0700 Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression commit 332f1795ca202489c665a75e62e18ff6284de077 upstream. The patch d0be8347c623: "Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put" from Jul 21, 2022, leads to the following Smatch static checker warning: net/bluetooth/l2cap_core.c:1977 l2cap_global_chan_by_psm() error: we previously assumed 'c' could be null (see line 1996) Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2905cd48c18448ef509ef05f168202e19904ff5c Author: Pavel Begunkov <[email protected]> Date: Thu Aug 4 15:13:46 2022 +0100 io_uring: mem-account pbuf buckets commit cc18cc5e82033d406f54144ad6f8092206004684 upstream. Potentially, someone may create as many pbuf bucket as there are indexes in an xarray without any other restrictions bounding our memory usage, put memory needed for the buckets under memory accounting. Cc: <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/d34c4[email protected]gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ee57f8bba81111ef6f1ac829834b186a97674077 Author: Russell Currey <[email protected]> Date: Wed Aug 10 15:43:31 2022 +1000 powerpc/kexec: Fix build failure from uninitialised variable commit 83ee9f23763a432a4077bf20624ee35de87bce99 upstream. clang 14 won't build because ret is uninitialised and can be returned if both prop and fdtprop are NULL. Drop the ret variable and return an error in that failure case. Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window") Suggested-by: Christophe Leroy <[email protected]> Signed-off-by: Russell Currey <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2f49bfbba326b576008af83fffe8f4f039e5d87e Author: Alexander Gordeev <[email protected]> Date: Sat Aug 6 09:29:46 2022 +0200 Revert "s390/smp: enforce lowcore protection on CPU restart" commit 953503751a426413ea8aee2299ae3ee971b70d9b upstream. This reverts commit 6f5c672d17f583b081e283927f5040f726c54598. This breaks normal crash dump when CPU0 is offline. Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bd27cff9db4f32762d37cda5dd22b9b6adfcb4f5 Author: Vladimir Oltean <[email protected]> Date: Thu Aug 4 23:28:17 2022 +0300 net: dsa: felix: fix min gate len calculation for tc when its first gate is closed commit 7e4babffa6f340a74c820d44d44d16511e666424 upstream. min_gate_len[tc] is supposed to track the shortest interval of continuously open gates for a traffic class. For example, in the following case: TC 76543210 t0 00000001b 200000 ns t1 00000010b 200000 ns min_gate_len[0] and min_gate_len[1] should be 200000, while min_gate_len[2-7] should be 0. However what happens is that min_gate_len[0] is 200000, but min_gate_len[1] ends up being 0 (despite gate_len[1] being 200000 at the point where the logic detects the gate close event for TC 1). The problem is that the code considers a "gate close" event whenever it sees that there is a 0 for that TC (essentially it's level rather than edge triggered). By doing that, any time a gate is seen as closed without having been open prior, gate_len, which is 0, will be written into min_gate_len. Once min_gate_len becomes 0, it's impossible for it to track anything higher than that (the length of actually open intervals). To fix this, we make the writing to min_gate_len[tc] be edge-triggered, which avoids writes for gates that are closed in consecutive intervals. However what this does is it makes us need to special-case the permanently closed gates at the end. Fixes: 55a515b1f5a9 ("net: dsa: felix: drop oversized frames with tc-taprio instead of hanging the port") Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4ee7e7dd1f9931cbba720c0df83fcdf03bc0f75a Author: Steven Rostedt (Google) <[email protected]> Date: Tue Jul 19 18:20:04 2022 -0400 tracing: Use a copy of the va_list for __assign_vstr() commit 3a2dcbaf4d31023106975d6ae75b6df080c454cb upstream. If an instance of tracing enables the same trace event as another instance, or the top level instance, or even perf, then the va_list passed into some tracepoints can be used more than once. As va_list can only be traversed once, this can cause issues: # cat /sys/kernel/tracing/instances/qla2xxx/trace cat-56106 [012] ..... 2419873.470098: ql_dbg_log: qla2xxx [0000:05:00.0]-1054:14: Entered (null). cat-56106 [012] ..... 2419873.470101: ql_dbg_log: qla2xxx [0000:05:00.0]-1000:14: Entered ×+<96>²Ü<98>^H. cat-56106 [012] ..... 2419873.470102: ql_dbg_log: qla2xxx [0000:05:00.0]-1006:14: Prepare to issue mbox cmd=0xde589000. # cat /sys/kernel/tracing/trace cat-56106 [012] ..... 2419873.470097: ql_dbg_log: qla2xxx [0000:05:00.0]-1054:14: Entered qla2x00_get_firmware_state. cat-56106 [012] ..... 2419873.470100: ql_dbg_log: qla2xxx [0000:05:00.0]-1000:14: Entered qla2x00_mailbox_command. cat-56106 [012] ..... 2419873.470102: ql_dbg_log: qla2xxx [0000:05:00.0]-1006:14: Prepare to issue mbox cmd=0x69. The instance version is corrupted because the top level instance iterated the va_list first. Use va_copy() in the __assign_vstr() macro to make sure that each trace event for each use case gets a fresh va_list. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 0563231f93c6d ("tracing/events: Add __vstring() and __assign_vstr() helper macros") Reported-by: Arun Easi <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4c94e37453ea293ab3196bed6d2b1b0e733518f0 Author: Johannes Berg <[email protected]> Date: Mon Jun 27 12:49:03 2022 +0200 wifi: cfg80211: remove chandef check in cfg80211_cac_event() commit d6f671c8a339d5b655acfacb8be6918c744fbabf upstream. The current check only worked for AP mode, but we can do radar detection in mesh as well (for example). We could try to check this using wdev_chandef(), but we also don't really care since the chandef is passed in and we have no need to use it anymore (since we added the argument in commit d2859df5e7f0 ("cfg80211/mac80211: DFS setup chandef for cac event")). Change-Id: I856e4344d5e64ff4d2eead0b4c53b11f264be9b8 Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 07f8ea3000f302759c32496cbb81403f6db676ed Author: Johannes Berg <[email protected]> Date: Mon Jun 27 12:49:03 2022 +0200 wifi: nl80211: acquire wdev mutex earlier in start_ap commit c2653990d5729a445296d6d04395be5dea8e282e upstream. We need to hold the wdev mutex already in order to call nl80211_parse_tx_bitrate_mask(), so acquire it earlier. Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d94f6d8453330eb26375fc6ed09017bd7b60375d Author: Johannes Berg <[email protected]> Date: Mon Jun 27 12:49:03 2022 +0200 wifi: nl80211: relax wdev mutex check in wdev_chandef() commit 31177127e067eb73d5ca46ce32a410e41333d42f upstream. In many cases we might get here from driver code that's not really set up to care about the locking, and for the non-MLO cases we really don't care so much about it. So relax the checking here for now, perhaps we should even remove it completely since we might not really care if we point to an invalid link's chandef and can require the caller to check the link validity first. Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 05330210d27994a5e2f64f01f621acb0623273aa Author: Johannes Berg <[email protected]> Date: Mon Jun 27 12:43:37 2022 +0200 wifi: nl80211: hold wdev mutex for tid config commit 206bbcf76121664e95a42e1c014c3fe168d07a3d upstream. We need wdev_chandef() in this code, which now requires the wdev mutex due to the per-link nature. Hold it here to make sure we can access the link. Reported-by: [email protected] Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d658df243d3e997468bdf78cd03ebe44151973d5 Author: Johannes Berg <[email protected]> Date: Mon Jun 27 12:36:03 2022 +0200 wifi: cfg80211: handle IBSS in channel switch commit 77e7b6ba78edf817bddfa97fadb15a971992b1ee upstream. Prior to commit 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") the interface type didn't really matter here, but now we need to handle all of the possible cases. Add IBSS ("ADHOC") and handle it. Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") Reported-by: [email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit af37d2080c2a8598a54945fc6df60e266c9dc43b Author: Paolo Abeni <[email protected]> Date: Thu Jun 30 15:17:56 2022 -0700 mptcp: refine memory scheduling commit 69d93daec026cdda98e29e8edb12534bfa5b1a9b upstream. Similar to commit 7c80b038d23e ("net: fix sk_wmem_schedule() and sk_rmem_schedule() errors"), let the MPTCP receive path schedule exactly the required amount of memory. Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit d729f0ee99a3c4ef8d515bd1a78dcafb86f3b8f8 Author: Greg Kroah-Hartman <[email protected]> Date: Mon Jun 27 16:36:57 2022 +0200 Revert "devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm" commit 38a523a2946d3a0961d141d477a1ee2b1f3bdbb1 upstream. This reverts commit 77515ebaf01920e2db49e04672ef669a7c2907f2 as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users. Link: https://lore.kernel.org/r/[email protected] Cc: Duoming Zhou <[email protected]> Cc: Brian Norris <[email protected]> Cc: Johannes Berg <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 2d03f321a589bcbf84141b943dbe033acae79b0e Author: Greg Kroah-Hartman <[email protected]> Date: Mon Jun 27 16:35:59 2022 +0200 Revert "mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv" commit 5f8954e099b8ae96e7de1bb95950e00c85bedd40 upstream. This reverts commit a52ed4866d2b90dd5e4ae9dabd453f3ed8fa3cbc as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users. Link: https://lore.kernel.org/r/[email protected] Cc: Duoming Zhou <[email protected]> Cc: Brian Norris <[email protected]> Cc: Johannes Berg <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit cbfe2d7bbcb7b50f7da42cd22fef5ed5a388dc68 Author: Eric Dumazet <[email protected]> Date: Thu Jun 23 19:35:40 2022 +0000 raw: fix a typo in raw_icmp_error() commit 97a4d46b1516250d640c1ae0c9e7129d160d6a1c upstream. I accidentally broke IPv4 traceroute, by swapping iph->saddr and iph->daddr. Probably because raw_icmp_error() and raw_v4_input() use different order for iph->saddr and iph->daddr. Fixes: ba44f8182ec2 ("raw: use more conventional iterators") Reported-by: John Sperbeck <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]nel.org> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3476fa73bd0f9dc8f38f238273a43a13d3a09b15 Author: Eric Dumazet <[email protected]> Date: Wed Jun 22 03:23:03 2022 +0000 raw: remove unused variables from raw6_icmp_error() commit c4fceb46add65481ef0dfb79cad24c3c269b4cad upstream. saddr and daddr are set but not used. Fixes: ba44f8182ec2 ("raw: use more conventional iterators") Reported-by: kernel test robot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Jonathan Lemon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3a6b9f3577718c8e19374110705bb61bed3e314d Author: Jason A. Donenfeld <[email protected]> Date: Mon Jun 20 09:52:43 2022 +0200 crypto: lib/blake2s - reduce stack frame usage in self test commit d6c14da474bf260d73953fbf7992c98d9112aec7 upstream. Using 3 blocks here doesn't give us much more than using 2, and it causes a stack frame size warning on certain compiler/config/arch combinations: lib/crypto/blake2s-selftest.c: In function 'blake2s_selftest': >> lib/crypto/blake2s-selftest.c:632:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=] 632 | } | ^ So this patch just reduces the block from 3 to 2, which makes the warning go away. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/linux-crypto/[email protected] Fixes: 2d16803c562e ("crypto: blake2s - remove shash module") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 1d9f9dcd661f163487b9a7c88667ee6b9698bc21 Author: Eric Dumazet <[email protected]> Date: Tue Jun 14 10:17:33 2022 -0700 tcp: fix over estimation in sk_forced_mem_schedule() commit c4ee118561a0f74442439b7b5b486db1ac1ddfeb upstream. sk_forced_mem_schedule() has a bug similar to ones fixed in commit 7c80b038d23e ("net: fix sk_wmem_schedule() and sk_rmem_schedule() errors") While this bug has little chance to trigger in old kernels, we need to fix it before the following patch. Fixes: d83769a580f1 ("tcp: fix possible deadlock in tcp_send_fin()") Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Reviewed-by: Wei Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 62ceb22d7770e2a32ef8d4517f8393d7e2de1d87 Author: Robert Foss <[email protected]> Date: Mon May 23 18:15:19 2022 +0200 Revert "drm/bridge: anx7625: Use DPI bus type" commit 61922beba36adea8702fe8069b309c806f6608af upstream. This reverts commit a77c2af0994e24ee36c7ffb6dc852770bdf06fb1. This patch depends on the patches just aplied to the media tree, and will not build without them, which leaves drm-misc-next in a broken state. Let's revert the two latter patches until rc1 has been branched, and rc1 has been backmerged into drm-misc-next. Signed-off-by: Robert Foss <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit ee3f18d90e80e79449d575fa3e7a6b775e9fc35e Author: Thadeu Lima de Souza Cascardo <[email protected].com> Date: Tue Aug 9 14:05:18 2022 -0300 net_sched: cls_route: remove from list when handle is 0 commit 9ad36309e2719a884f946678e0296be10f0bb4c1 upstream. When a route filter is replaced and the old filter has a 0 handle, the old one won't be removed from the hashtable, while it will still be freed. The test was there since before commit 1109c00547fc ("net: sched: RCU cls_route"), when a new filter was not allocated when there was an old one. The old filter was reused and the reinserting would only be necessary if an old filter was replaced. That was still wrong for the same case where the old handle was 0. Remove the old filter from the list independently from its handle value. This fixes CVE-2022-2588, also reported as ZDI-CAN-17440. Reported-by: Zhenpeng Lin <[email protected]> Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Reviewed-by: Kamal Mostafa <[email protected]> Cc: <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0e5ca33839fc5479c9a9d28a8d7bc5cef4a3a61e Author: Naveen N. Rao <[email protected]> Date: Tue Aug 9 15:29:07 2022 +0530 powerpc64/ftrace: Fix ftrace for clang builds commit cb928ac192128c842f4c1cfc8b6780b95719d65f upstream. Clang doesn't support -mprofile-kernel ABI, so guard the checks against CONFIG_DYNAMIC_FTRACE_WITH_REGS, rather than the elf ABI version. Fixes: 23b44fc248f4 ("powerpc/ftrace: Make __ftrace_make_{nop/call}() common to PPC32 and PPC64") Cc: [email protected] # v5.19+ Reported-by: Nick Desaulniers <[email protected]> Reported-by: Ondrej Mosnacek <[email protected]> Signed-off-by: Naveen N. Rao <[email protected]> Tested-by: Ondrej Mosnacek <[email protected]> Acked-by: Nick Desaulniers <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://github.com/llvm/llvm-project/issues/57031 Link: https://github.com/ClangBuiltLinux/linux/issues/1682 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bb0be69e1da56b8bcc1205460bc8faabac37755a Author: Christophe Leroy <[email protected]> Date: Tue Aug 2 11:02:36 2022 +0200 powerpc: Fix eh field when calling lwarx on PPC32 commit 18db466a9a306406dab3b134014d9f6ed642471c upstream. Commit 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros") properly handled the eh field of lwarx in asm/bitops.h but failed to clear it for PPC32 in asm/simple_spinlock.h So, do as in arch_atomic_try_cmpxchg_lock(), set it to 1 if PPC64 but set it to 0 if PPC32. For that use IS_ENABLED(CONFIG_PPC64) which returns 1 when CONFIG_PPC64 is set and 0 otherwise. Fixes: 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros") Cc: [email protected] # v5.15+ Reported-by: Pali Rohár <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Pali Rohár <[email protected]> Reviewed-by: Segher Boessenkool <[email protected]> [mpe: Use symbolic names, use 'n' constraint per Segher] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/a1176e19e[email protected]csgroup.eu Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 8acd0e8d0360fe9ff1f70b7456a10dd83280969a Author: SeongJae Park <[email protected]> Date: Fri Jul 15 22:51:08 2022 +0000 xen-blkfront: Apply 'feature_persistent' parameter when connect commit 402c43ea6b34a1b371ffeed9adf907402569eaf5 upstream. In some use cases[1], the backend is created while the frontend doesn't support the persistent grants feature, but later the frontend can be changed to support the feature and reconnect. In the past, 'blkback' enabled the persistent grants feature since it unconditionally checked if frontend supports the persistent grants feature for every connect ('connect_ring()') and decided whether it should use persistent grans or not. However, commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") has mistakenly changed the behavior. It made the frontend feature support check to not be repeated once it shown the 'feature_persistent' as 'false', or the frontend doesn't support persistent grants. Similar behavioral change has made on 'blkfront' by commit 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants"). This commit changes the behavior of the parameter to make effect for every connect, so that the previous behavior of 'blkfront' can be restored. [1] https://lore.kernel.org/xen-devel/[email protected]om/ Fixes: 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants") Cc: <[email protected]> # 5.10.x Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit f7a9a465a90126a715d1d107bf9d9301587040a6 Author: Maximilian Heyne <[email protected]> Date: Fri Jul 15 22:51:07 2022 +0000 xen-blkback: Apply 'feature_persistent' parameter when connect commit e94c6101e151b019b8babc518ac2a6ada644a5a1 upstream. In some use cases[1], the backend is created while the frontend doesn't support the persistent grants feature, but later the frontend can be changed to support the feature and reconnect. In the past, 'blkback' enabled the persistent grants feature since it unconditionally checked if frontend supports the persistent grants feature for every connect ('connect_ring()') and decided whether it should use persistent grans or not. However, commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") has mistakenly changed the behavior. It made the frontend feature support check to not be repeated once it shown the 'feature_persistent' as 'false', or the frontend doesn't support persistent grants. This commit changes the behavior of the parameter to make effect for every connect, so that the previous workflow can work again as expected. [1] https://lore.kernel.org/xen-devel/[email protected]om/ Reported-by: Andrii Chepurnyi <[email protected]> Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <[email protected]> # 5.10.x Signed-off-by: Maximilian Heyne <[email protected]> Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 59bb16373e49c5889e8e76adb2a2f4ea9ec9c13a Author: SeongJae Park <[email protected]> Date: Fri Jul 15 22:51:06 2022 +0000 xen-blkback: fix persistent grants negotiation commit fc9be616bb8f3ed9cf560308f86904f5c06be205 upstream. Persistent grants feature can be used only when both backend and the frontend supports the feature. The feature was always supported by 'blkback', but commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") has introduced a parameter for disabling it runtime. To avoid the parameter be updated while being used by 'blkback', the commit caches the parameter into 'vbd->feature_gnt_persistent' in 'xen_vbd_create()', and then check if the guest also supports the feature and finally updates the field in 'connect_ring()'. However, 'connect_ring()' could be called before 'xen_vbd_create()', so later execution of 'xen_vbd_create()' can wrongly overwrite 'true' to 'vbd->feature_gnt_persistent'. As a result, 'blkback' could try to use 'persistent grants' feature even if the guest doesn't support the feature. This commit fixes the issue by moving the parameter value caching to 'xen_blkif_alloc()', which allocates the 'blkif'. Because the struct embeds 'vbd' object, which will be used by 'connect_ring()' later, this should be called before 'connect_ring()' and therefore this should be the right and safe place to do the caching. Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <[email protected]> # 5.10.x Signed-off-by: Maximilian Heyne <[email protected]> Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9a0af34f6e492769d1e2f9da037f011ab8456d05 Author: Mårten Lindahl <[email protected]> Date: Mon Aug 1 15:57:03 2022 +0200 tpm: Add check for Failure mode for TPM2 modules [ Upstream commit 863ed94c589fcd1984f4e3080f069d30508044bb ] In commit 0aa698787aa2 ("tpm: Add Upgrade/Reduced mode support for TPM2 modules") it was said that: "If the TPM is in Failure mode, it will successfully respond to both tpm2_do_selftest() and tpm2_startup() calls. Although, will fail to answer to tpm2_get_cc_attrs_tbl(). Use this fact to conclude that TPM is in Failure mode." But a check was never added in the commit when calling tpm2_get_cc_attrs_tbl() to conclude that the TPM is in Failure mode. This commit corrects this by adding a check. Fixes: 0aa698787aa2 ("tpm: Add Upgrade/Reduced mode support for TPM2 modules") Cc: [email protected] # v5.17+ Signed-off-by: Mårten Lindahl <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b75337943f4213d7eb853f1d2570c4f8a4b0ce9e Author: Huacai Chen <[email protected]> Date: Mon Jul 11 09:17:38 2022 +0800 tpm: eventlog: Fix section mismatch for DEBUG_SECTION_MISMATCH [ Upstream commit bed4593645366ad7362a3aa7bc0d100d8d8236a8 ] If DEBUG_SECTION_MISMATCH enabled, __calc_tpm2_event_size() will not be inlined, this cause section mismatch like this: WARNING: modpost: vmlinux.o(.text.unlikely+0xe30c): Section mismatch in reference from the variable L0 to the function .init.text:early_ioremap() The function L0() references the function __init early_memremap(). This is often because L0 lacks a __init annotation or the annotation of early_ioremap is wrong. Fix it by using __always_inline instead of inline for the called-once function __calc_tpm2_event_size(). Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations") Cc: [email protected] # v5.3 Reported-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 26ad6b0aef0c807cfc738e23339f4ce2aab7be95 Author: Tianjia Zhang <[email protected]> Date: Tue Jun 28 11:37:20 2022 +0800 KEYS: asymmetric: enforce SM2 signature use pkey algo [ Upstream commit 0815291a8fd66cdcf7db1445d4d99b0d16065829 ] The signature verification of SM2 needs to add the Za value and recalculate sig->digest, which requires the detection of the pkey_algo in public_key_verify_signature(). As Eric Biggers said, the pkey_algo field in sig is attacker-controlled and should be use pkey->pkey_algo instead of sig->pkey_algo, and secondly, if sig->pkey_algo is NULL, it will also cause signature verification failure. The software_key_determine_akcipher() already forces the algorithms are matched, so the SM3 algorithm is enforced in the SM2 signature, although this has been checked, we still avoid using any algorithm information in the signature as input. Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Reported-by: Eric Biggers <[email protected]> Cc: [email protected] # v5.10+ Signed-off-by: Tianjia Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 96fa141fa295ae9428da73c56c9852053b575c04 Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:24 2022 +0200 ext4: fix race when reusing xattr blocks [ Upstream commit 65f8b80053a1b2fd602daa6814e62d6fa90e5e9b ] When ext4_xattr_block_set() decides to remove xattr block the following race can happen: CPU1 CPU2 ext4_xattr_block_set() ext4_xattr_release_block() new_bh = ext4_xattr_block_cache_find() lock_buffer(bh); ref = le32_to_cpu(BHDR(bh)->h_refcount); if (ref == 1) { ... mb_cache_entry_delete(); unlock_buffer(bh); ext4_free_blocks(); ... ext4_forget(..., bh, ...); jbd2_journal_revoke(..., bh); ext4_journal_get_write_access(..., new_bh, ...) do_get_write_access() jbd2_journal_cancel_revoke(..., new_bh); Later the code in ext4_xattr_block_set() finds out the block got freed and cancels reusal of the block but the revoke stays canceled and so in case of block reuse and journal replay the filesystem can get corrupted. If the race works out slightly differently, we can also hit assertions in the jbd2 code. Fix the problem by making sure that once matching mbcache entry is found, code dropping the last xattr block reference (or trying to modify xattr block in place) waits until the mbcache entry reference is dropped. This way code trying to reuse xattr block is protected from someone trying to drop the last reference to xattr block. Reported-and-tested-by: Ritesh Harjani <[email protected]> CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/20220712105436.32204-5-ja[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0e7e91701e4e443bdfb9775b0924c69bbb318860 Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:23 2022 +0200 ext4: unindent codeblock in ext4_xattr_block_set() [ Upstream commit fd48e9acdf26d0cbd80051de07d4a735d05d29b2 ] Remove unnecessary else (and thus indentation level) from a code block in ext4_xattr_block_set(). It will also make following code changes easier. No functional changes. CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 458aee4a6e5be7ad862ee27dfaf07ce552d84f32 Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:22 2022 +0200 ext4: remove EA inode entry from mbcache on inode eviction [ Upstream commit 6bc0d63dad7f9f54d381925ee855b402f652fa39 ] Currently we remove EA inode from mbcache as soon as its xattr refcount drops to zero. However there can be pending attempts to reuse the inode and thus refcount handling code has to handle the situation when refcount increases from zero anyway. So save some work and just keep EA inode in mbcache until it is getting evicted. At that moment we are sure following iget() of EA inode will fail anyway (or wait for eviction to finish and load things from the disk again) and so removing mbcache entry at that moment is fine and simplifies the code a bit. CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9d96996de0d2bc53f617086864b3b990089d9d8b Author: Lukas Czerner <[email protected]> Date: Mon Jul 4 16:27:21 2022 +0200 ext4: make sure ext4_append() always allocates new block [ Upstream commit b8a04fe77ef1360fbf73c80fddbdfeaa9407ed1b ] ext4_append() must always allocate a new block, otherwise we run the risk of overwriting existing directory block corrupting the directory tree in the process resulting in all manner of problems later on. Add a sanity check to see if the logical block is already allocated and error out if it is. Cc: [email protected] Signed-off-by: Lukas Czerner <[email protected]> Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 193fc6f0de44a884fd4db82a9a368dafcd2c9bed Author: Lukas Czerner <[email protected]> Date: Mon Jul 4 16:27:20 2022 +0200 ext4: check if directory block is within i_size [ Upstream commit 65f8ea4cd57dbd46ea13b41dc8bac03176b04233 ] Currently ext4 directory handling code implicitly assumes that the directory blocks are always within the i_size. In fact ext4_append() will attempt to allocate next directory block based solely on i_size and the i_size is then appropriately increased after a successful allocation. However, for this to work it requires i_size to be correct. If, for any reason, the directory inode i_size is corrupted in a way that the directory tree refers to a valid directory block past i_size, we could end up corrupting parts of the directory tree structure by overwriting already used directory blocks when modifying the directory. Fix it by catching the corruption early in __ext4_read_dirblock(). Addresses Red-Hat-Bugzilla: #2070205 CVE: CVE-2022-1184 Signed-off-by: Lukas Czerner <[email protected]> Cc: [email protected] Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ac5aca9a8085639210c045afe046c13e34b71a28 Author: Bagas Sanjaya <[email protected]> Date: Sun Jun 19 14:29:39 2022 +0700 Documentation: ext4: fix cell spacing of table heading on blockmap table [ Upstream commit 442ec1e5bb7c46c72c41898e13a5744c84cadf51 ] Commit 3103084afcf234 ("ext4, doc: remove unnecessary escaping") removes redundant underscore escaping, however the cell spacing in heading row of blockmap table became not aligned anymore, hence triggers malformed table warning: Documentation/filesystems/ext4/blockmap.rst:3: WARNING: Malformed table. +---------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | i.i_block Offset | Where It Points | <snipped>... The warning caused the table not being loaded. Realign the heading row cell by adding missing space at the first cell to fix the warning. Fixes: 3103084afcf234 ("ext4, doc: remove unnecessary escaping") Cc: [email protected] Cc: Andreas Dilger <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Wang Jianjian <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Bagas Sanjaya <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fa6482f374fda29a71ad44d76d35b4842d43cda4 Author: Ye Bin <[email protected]> Date: Fri Jun 17 09:39:35 2022 +0800 ext4: fix warning in ext4_iomap_begin as race between bmap and write [ Upstream commit 51ae846cff568c8c29921b1b28eb2dfbcd4ac12d ] We got issue as follows: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp. Signed-off-by: Ye Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]> commit a5e274ec0a0c13638c64694a340bcd4cb7b348fa Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:58 2022 +0800 ext4: correct the misjudgment in ext4_iget_extra_inode [ Upstream commit fd7e672ea98b95b9d4c9dae316639f03c16a749d ] Use the EXT4_INODE_HAS_XATTR_SPACE macro to more accurately determine whether the inode have xattr space. Cc: [email protected] Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a926d0b0fa3acd848042c2f83fbc75e2bb65f654 Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:57 2022 +0800 ext4: correct max_inline_xattr_value_size computing [ Upstream commit c9fd167d57133c5b748d16913c4eabc55e531c73 ] If the ext4 inode does not have xattr space, 0 is returned in the get_max_inline_xattr_value_size function. Otherwise, the function returns a negative value when the inode does not contain EXT4_STATE_XATTR. Cc: [email protected] Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 52e6feee51b859c52af61f8a75cfdad70238c100 Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:56 2022 +0800 ext4: fix use-after-free in ext4_xattr_set_entry [ Upstream commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3 ] Hulk Robot reported a issue: ================================================================== BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x18ab/0x3500 Write of size 4105 at addr ffff8881675ef5f4 by task syz-executor.0/7092 CPU: 1 PID: 7092 Comm: syz-executor.0 Not tainted 4.19.90-dirty #17 Call Trace: [...] memcpy+0x34/0x50 mm/kasan/kasan.c:303 ext4_xattr_set_entry+0x18ab/0x3500 fs/ext4/xattr.c:1747 ext4_xattr_ibody_inline_set+0x86/0x2a0 fs/ext4/xattr.c:2205 ext4_xattr_set_handle+0x940/0x1300 fs/ext4/xattr.c:2386 ext4_xattr_set+0x1da/0x300 fs/ext4/xattr.c:2498 __vfs_setxattr+0x112/0x170 fs/xattr.c:149 __vfs_setxattr_noperm+0x11b/0x2a0 fs/xattr.c:180 __vfs_setxattr_locked+0x17b/0x250 fs/xattr.c:238 vfs_setxattr+0xed/0x270 fs/xattr.c:255 setxattr+0x235/0x330 fs/xattr.c:520 path_setxattr+0x176/0x190 fs/xattr.c:539 __do_sys_lsetxattr fs/xattr.c:561 [inline] __se_sys_lsetxattr fs/xattr.c:557 [inline] __x64_sys_lsetxattr+0xc2/0x160 fs/xattr.c:557 do_syscall_64+0xdf/0x530 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x459fe9 RSP: 002b:00007fa5e54b4c08 EFLAGS: 00000246 ORIG_RAX: 00000000000000bd RAX: ffffffffffffffda RBX: 000000000051bf60 RCX: 0000000000459fe9 RDX: 00000000200003c0 RSI: 0000000020000180 RDI: 0000000020000140 RBP: 000000000051bf60 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000001009 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc73c93fc0 R14: 000000000051bf60 R15: 00007fa5e54b4d80 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_xattr_set ext4_xattr_set_handle ext4_xattr_ibody_find >> s->end < s->base >> no EXT4_STATE_XATTR >> xattr_check_inode is not executed ext4_xattr_ibody_set ext4_xattr_set_entry >> size_t min_offs = s->end - s->base >> UAF in memcpy we can easily reproduce this problem with the following commands: mkfs.ext4 -F /dev/sda mount -o debug_want_extra_isize=128 /dev/sda /mnt touch /mnt/file setfattr -n user.cat -v `seq -s z 4096|tr -d '[:digit:]'` /mnt/file In ext4_xattr_ibody_find, we have the following assignment logic: header = IHDR(inode, raw_inode) = raw_inode + EXT4_GOOD_OLD_INODE_SIZE + i_extra_isize is->s.base = IFIRST(header) = header + sizeof(struct ext4_xattr_ibody_header) is->s.end = raw_inode + s_inode_size In ext4_xattr_set_entry min_offs = s->end - s->base = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize - sizeof(struct ext4_xattr_ibody_header) last = s->first free = min_offs - ((void *)last - s->base) - sizeof(__u32) = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize - sizeof(struct ext4_xattr_ibody_header) - sizeof(__u32) In the calculation formula, all values except s_inode_size and i_extra_size are fixed values. When i_extra_size is the maximum value s_inode_size - EXT4_GOOD_OLD_INODE_SIZE, min_offs is -4 and free is -8. The value overflows. As a result, the preceding issue is triggered when memcpy is executed. Therefore, when finding xattr or setting xattr, check whether there is space for storing xattr in the inode to resolve this issue. Cc: [email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4cdc284ffadd6a989f24107ee7f09be43b748fbb Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:55 2022 +0800 ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h [ Upstream commit 179b14152dcb6a24c3415200603aebca70ff13af ] When adding an xattr to an inode, we must ensure that the inode_size is not less than EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. Otherwise, the end position may be greater than the start position, resulting in UAF. Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1d637e9b6374bf101d2ff7f28ec3d32dd2f49670 Author: Eric Whitney <[email protected]> Date: Wed Jun 15 12:05:30 2022 -0400 ext4: fix extent status tree race in writeback error recovery path [ Upstream commit 7f0d8e1d607c1a4fa9a27362a108921d82230874 ] A race can occur in the unlikely event ext4 is unable to allocate a physical cluster for a delayed allocation in a bigalloc file system during writeback. Failure to allocate a cluster forces error recovery that includes a call to mpage_release_unused_pages(). That function removes any corresponding delayed allocated blocks from the extent status tree. If a new delayed write is in progress on the same cluster simultaneously, resulting in the addition of an new extent containing one or more blocks in that cluster to the extent status tree, delayed block accounting can be thrown off if that delayed write then encounters a similar cluster allocation failure during future writeback. Write lock the i_data_sem in mpage_release_unused_pages() to fix this problem. Ext4's block/cluster accounting code for bigalloc relies on i_data_sem for mutual exclusion, as is found in the delayed write path, and the locking in mpage_release_unused_pages() is missing. Cc: [email protected] Reported-by: Ye Bin <[email protected]> Signed-off-by: Eric Whitney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 86f73cfa98b20e864e11f4a6c82a045f6952d6d5 Author: Theodore Ts'o <[email protected]> Date: Wed Jun 29 00:00:25 2022 -0400 ext4: update s_overhead_clusters in the superblock during an on-line resize [ Upstream commit de394a86658ffe4e89e5328fd4993abfe41b7435 ] When doing an online resize, the on-disk superblock on-disk wasn't updated. This means that when the file system is unmounted and remounted, and the on-disk overhead value is non-zero, this would result in the results of statfs(2) to be incorrect. This was partially fixed by Commits 10b01ee92df5 ("ext4: fix overhead calculation to account for the reserved gdt blocks"), 85d825dbf489 ("ext4: force overhead calculation if the s_overhead_cluster makes no sense"), and eb7054212eac ("ext4: update the cached overhead value in the superblock"). However, since it was too expensive to forcibly recalculate the overhead for bigalloc file systems at every mount, this didn't fix the problem for bigalloc file systems. This commit should address the problem when resizing file systems with the bigalloc feature enabled. Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c0afc0d79d5e31942c3b8da3022d1f035a2b2cad Author: Zhang Yi <[email protected]> Date: Thu Jun 30 17:01:00 2022 +0800 ext4: fix reading leftover inlined symlinks [ Upstream commit 5a57bca9050d740ca37184302e23d0e7633e3ebc ] Since commit 6493792d3299 ("ext4: convert symlink external data block mapping to bdev"), create new symlink with inline_data is not supported, but it missing to handle the leftover inlined symlinks, which could cause below error message and fail to read symlink. ls: cannot read symbolic link 'foo': Structure needs cleaning EXT4-fs error (device sda): ext4_map_blocks:605: inode #12: block 2021161080: comm ls: lblock 0 mapped to illegal pblock 2021161080 (length 1) Fix this regression by adding ext4_read_inline_link(), which read the inline data directly and convert it through a kmalloced buffer. Fixes: 6493792d3299 ("ext4: convert symlink external data block mapping to bdev") Cc: [email protected] Reported-by: Torge Matthies <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Tested-by: Torge Matthies <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]g> commit 0ab3e0d31a4e3ea8dd123399c648c2c3ed844c2d Author: Steven Rostedt (Google) <[email protected]> Date: Sun Jul 31 01:59:28 2022 -0400 tracing: Use a struct alignof to determine trace event field alignment [ Upstream commit 4c3d2f9388d36eb28640a220a6f908328442d873 ] alignof() gives an alignment of types as they would be as standalone variables. But alignment in structures might be different, and when building the fields of events, the alignment must be the actual alignment otherwise the field offsets may not match what they actually are. This caused trace-cmd to crash, as libtraceevent did not check if the field offset was bigger than the event. The write_msr and read_msr events on 32 bit had their fields incorrect, because it had a u64 field between two ints. alignof(u64) would give 8, but the u64 field was at a 4 byte alignment. Define a macro as: ALIGN_STRUCTFIELD(type) ((int)(offsetof(struct {char a; type b;}, b))) which gives the actual alignment of types in a structure. Link: https://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: [email protected] Fixes: 04ae87a52074e ("ftrace: Rework event_create_dir()") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b6679e3c90dd76a52de0ce99984809e5ed0023e5 Author: Steven Rostedt (Google) <[email protected]> Date: Sun Jul 24 19:16:50 2022 -0400 batman-adv: tracing: Use the new __vstring() helper [ Upstream commit 9abc291812d784bd4a26c01af4ebdbf9f2dbf0bb ] Instead of open coding a __dynamic_array() with a fixed length (which defeats the purpose of the dynamic array in the first place). Use the new __vstring() helper that will use a va_list and only write enough of the string into the ring buffer that is needed. Link: https://lkml.kernel.org/r/[email protected] Cc: Marek Lindner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Simon Wunderlich <[email protected]> Cc: Antonio Quartulli <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Sven Eckelmann <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cec22fc5292253aae2c3804ed5e80ff82660c61d Author: Miaohe Lin <[email protected]> Date: Sat Jul 23 15:38:04 2022 +0800 hugetlb_cgroup: fix wrong hugetlb cgroup numa stat [ Upstream commit 2727cfe4072a35ce813e3708f74c135de7da8897 ] We forget to set cft->private for numa stat file. As a result, numa stat of hstates[0] is always showed for all hstates. Encode the hstates index into cft->private to fix this issue. Link: https://lkml.kernel.org/r/[email protected] Fixes: f47761999052 ("hugetlb: add hugetlb.*.numa_stat file") Signed-off-by: Miaohe Lin <[email protected]> Acked-by: Muchun Song <[email protected]> Cc: Kees Cook <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Mina Almasry <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]ation.org> Signed-off-by: Sasha Levin <[email protected]> commit 700aa4e11a3c4d2a44d06758db431a013d9e1b61 Author: Jianglei Nie <[email protected]> Date: Thu Jul 14 14:37:46 2022 +0800 mm/damon/reclaim: fix potential memory leak in damon_reclaim_init() [ Upstream commit 188043c7f4f2bd662f2a55957d684fffa543e600 ] damon_reclaim_init() allocates a memory chunk for ctx with damon_new_ctx(). When damon_select_ops() fails, ctx is not released, which will lead to a memory leak. We should release the ctx with damon_destroy_ctx() when damon_select_ops() fails to fix the memory leak. Link: https://lkml.kernel.org/r/[email protected] Fixes: 4d69c3457821 ("mm/damon/reclaim: use damon_select_ops() instead of damon_{v,p}a_set_operations()") Signed-off-by: Jianglei Nie <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3990e5b2be3d57325bcaf83da889e5ae212c97eb Author: Mike Snitzer <[email protected]> Date: Wed Jul 20 13:58:04 2022 -0400 dm: fix dm-raid crash if md_handle_request() splits bio [ Upstream commit 9dd1cd3220eca534f2d47afad7ce85f4c40118d8 ] Commit ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") introduced the optimization to _not_ perform bio_associate_blkg()'s relatively costly work when DM core clones its bio. But in doing so it exposed the possibility for DM's cloned bio to alter DM target behavior (e.g. crash) if a target were to issue IO without first calling bio_set_dev(). The DM raid target can trigger an MD crash due to its need to split the DM bio that is passed to md_handle_request(). The split will recurse to submit_bio_noacct() using a bio with an uninitialized ->bi_blkg. This NULL bio->bi_blkg causes blk_throtl_bio() to dereference a NULL blkg_to_tg(bio->bi_blkg). Fix this in DM core by adding a new 'needs_bio_set_dev' target flag that will make alloc_tio() call bio_set_dev() on behalf of the target. dm-raid is the only target that requires this flag. bio_set_dev() initializes the DM cloned bio's ->bi_blkg, using bio_associate_blkg, before passing the bio to md_handle_request(). Long-term fix would be to audit and refactor MD code to rely on DM to split its bio, using dm_accept_partial_bio(), but there are MD raid personalities (e.g. raid1 and raid10) whose implementation are tightly coupled to handling the bio splitting inline. Fixes: ca522482e3eaf ("dm: pass NULL bdev to bio_alloc_clone") Cc: [email protected] Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2a9faa704d83ff0b04387e385efd8ae21cd95af6 Author: Mikulas Patocka <[email protected]> Date: Sun Jul 24 14:33:52 2022 -0400 dm raid: fix address sanitizer warning in raid_resume [ Upstream commit 7dad24db59d2d2803576f2e3645728866a056dab ] There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length. Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b4c6c07c92b6cba2bf3cb2dfa722debeaf8a8abe Author: Mikulas Patocka <[email protected]> Date: Sun Jul 24 14:31:35 2022 -0400 dm raid: fix address sanitizer warning in raid_status [ Upstream commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 ] There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f91b4038b636d9c85ab3de5cfd8d5688aef5c0a6 Author: Sean Christopherson <[email protected]> Date: Fri Jul 22 22:44:08 2022 +0000 KVM: nVMX: Attempt to load PERF_GLOBAL_CTRL on nVMX xfer iff it exists [ Upstream commit 4496a6f9b45e8cd83343ad86a3984d614e22cf54 ] Attempt to load PERF_GLOBAL_CTRL during nested VM-Enter/VM-Exit if and only if the MSR exists (according to the guest vCPU model). KVM has very misguided handling of VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL and attempts to force the nVMX MSR settings to match the vPMU model, i.e. to hide/expose the control based on whether or not the MSR exists from the guest's perspective. KVM's modifications fail to handle the scenario where the vPMU is hidden from the guest _after_ being exposed to the guest, e.g. by userspace doing multiple KVM_SET_CPUID2 calls, which is allowed if done before any KVM_RUN. nested_vmx_pmu_refresh() is called if and only if there's a recognized vPMU, i.e. KVM will leave the bits in the allow state and then ultimately reject the MSR load and WARN. KVM should not force the VMX MSRs in the first place. KVM taking control of the MSRs was a misguided attempt at mimicking what commit 5f76f6f5ff96 ("KVM: nVMX: Do not expose MPX VMX controls when guest MPX disabled", 2018-10-01) did for MPX. However, the MPX commit was a workaround for another KVM bug and not something that should be imitated (and it should never been done in the first place). In other words, KVM's ABI _should_ be that userspace has full control over the MSRs, at which point triggering the WARN that loading the MSR must not fail is trivial. The intent of the WARN is still valid; KVM has consistency checks to ensure that vmcs12->{guest,host}_ia32_perf_global_ctrl is valid. The problem is that '0' must be considered a valid value at all times, and so the simple/obvious solution is to just not actually load the MSR when it does not exist. It is userspace's responsibility to provide a sane vCPU model, i.e. KVM is well within its ABI and Intel's VMX architecture to skip the loads if the MSR does not exist. Fixes: 03a8871add95 ("KVM: nVMX: Expose load IA32_PERF_GLOBAL_CTRL VM-{Entry,Exit} control") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9863e9fc8ac2c13c786a26d49a69ae22201cffaf Author: Sean Christopherson <[email protected]> Date: Fri Jul 22 22:44:07 2022 +0000 KVM: VMX: Add helper to check if the guest PMU has PERF_GLOBAL_CTRL [ Upstream commit b663f0b5f3d665c261256d1f76e98f077c6e56af ] Add a helper to check of the guest PMU has PERF_GLOBAL_CTRL, which is unintuitive _and_ diverges from Intel's architecturally defined behavior. Even worse, KVM currently implements the check using two different (but equivalent) checks, _and_ there has been at least one attempt to add a _third_ flavor. Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c08044267e7976a921294ade05cf986efb0c4f99 Author: Sean Christopherson <[email protected]> Date: Sat Jun 11 00:57:51 2022 +0000 Revert "KVM: x86/pmu: Accept 0 for absent PMU MSRs when host-initiated if !enable_pmu" [ Upstream commit 5d4283df5a0fc8299fba9443c33d219939eccc2d ] Eating reads and writes to all "PMU" MSRs when there is no PMU is wildly broken as it results in allowing accesses to _any_ MSR on Intel CPUs as intel_is_valid_msr() returns true for all host_initiated accesses. A revert of commit d1c88a402056 ("KVM: x86: always allow host-initiated writes to PMU MSRs") will soon follow. This reverts commit 8e6a58e28b34e8d247e772159b8fa8f6bae39192. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6a74a619d5ec9d5ea1a529d532a389889aabe61e Author: Like Xu <[email protected]> Date: Wed Jun 1 11:19:23 2022 +0800 KVM: x86/pmu: Accept 0 for absent PMU MSRs when host-initiated if !enable_pmu [ Upstream commit 8e6a58e28b34e8d247e772159b8fa8f6bae39192 ] Whenever an MSR is part of KVM_GET_MSR_INDEX_LIST, as is the case for MSR_K7_EVNTSEL0 or MSR_F15H_PERF_CTL0, it has to be always retrievable and settable with KVM_GET_MSR and KVM_SET_MSR. Accept a zero value for these MSRs to obey the contract. Signed-off-by: Like Xu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d577d6f536108d8d1e7203b968675480a03b140f Author: Like Xu <[email protected]> Date: Mon May 9 18:22:02 2022 +0800 KVM: x86/pmu: Ignore pmu->global_ctrl check if vPMU doesn't support global_ctrl [ Upstream commit 98defd2e17803263f49548fea930cfc974d505aa ] MSR_CORE_PERF_GLOBAL_CTRL is introduced as part of Architecture PMU V2, as indicated by Intel SDM 19.2.2 and the intel_is_valid_msr() function. So in the absence of global_ctrl support, all PMCs are enabled as AMD does. Signed-off-by: Like Xu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 979ec20a64d9d2687dfaf844d4df93fcbb6fcc2b Author: Sean Christopherson <[email protected]> Date: Fri Jul 22 22:44:06 2022 +0000 KVM: VMX: Mark all PERF_GLOBAL_(OVF)_CTRL bits reserved if there's no vPMU [ Upstream commit 93255bf92939d948bc86d81c6bb70bb0fecc5db1 ] Mark all MSR_CORE_PERF_GLOBAL_CTRL and MSR_CORE_PERF_GLOBAL_OVF_CTRL bits as reserved if there is no guest vPMU. The nVMX VM-Entry consistency checks do not check for a valid vPMU prior to consuming the masks via kvm_valid_perf_global_ctrl(), i.e. may incorrectly allow a non-zero mask to be loaded via VM-Enter or VM-Exit (well, attempted to be loaded, the actual MSR load will be rejected by intel_is_valid_msr()). Fixes: f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit eb8f7dee28ccae389380694013487a55cff4bcc9 Author: Like Xu <[email protected]> Date: Mon Apr 11 18:19:34 2022 +0800 KVM: x86/pmu: Introduce the ctrl_mask value for fixed counter [ Upstream commit 2c985527dd8d283e786ad7a67e532ef7f6f00fac ] The mask value of fixed counter control register should be dynamic adjusted with the number of fixed counters. This patch introduces a variable that includes the reserved bits of fixed counter control registers. This is a generic code refactoring. Co-developed-by: Luwei Kang <[email protected]> Signed-off-by: Luwei Kang <[email protected]> Signed-off-by: Like Xu <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fc1f79039743738432c913078f3fd38046c0d072 Author: Sumanth Korikkar <[email protected]> Date: Tue Jul 26 18:57:59 2022 +0200 s390/unwind: fix fgraph return address recovery [ Upstream commit ded466e1806686794b403ebf031133bbaca76bb2 ] When HAVE_FUNCTION_GRAPH_RET_ADDR_PTR is defined, the return address to the fgraph caller is recovered by tagging it along with the stack pointer of ftrace stack. This makes the stack unwinding more reliable. When the fgraph return address is modified to return_to_handler, ftrace_graph_ret_addr tries to restore it to the original value using tagged stack pointer. Fix this by passing tagged sp to ftrace_graph_ret_addr. Fixes: d81675b60d09 ("s390/unwind: recover kretprobe modified return address in stacktrace") Cc: <[email protected]> # 5.18 Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Sumanth Korikkar <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0a4dbde507541e6d14659fdcd257b51d908d4a98 Author: Jason A. Donenfeld <[email protected]> Date: Thu Jul 28 00:32:18 2022 +1000 powerpc/powernv/kvm: Use darn for H_RANDOM on Power9 [ Upstream commit 7ef3d06f1bc4a5e62273726f3dc2bd258ae1c71f ] The existing logic in KVM to support guests calling H_RANDOM only works on Power8, because it looks for an RNG in the device tree, but on Power9 we just use darn. In addition the existing code needs to work in real mode, so we have the special cased powernv_get_random_real_mode() to deal with that. Instead just have KVM call ppc_md.get_random_seed(), and do the real mode check inside of there, that way we use whatever RNG is available, including darn on Power9. Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.") Cc: [email protected] # v4.1+ Signed-off-by: Jason A. Donenfeld <[email protected]> Tested-by: Sachin Sant <[email protected]> [mpe: Rebase on previous commit, update change log appropriately] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 71fe2aff460ef33b12ddb6fd9a8b924257bb5682 Author: Rafael J. Wysocki <[email protected]> Date: Thu Jul 21 19:41:10 2022 +0200 ACPI: CPPC: Do not prevent CPPC from working in the future [ Upstream commit 4f4179fcf420873002035cf1941d844c9e0e7cb3 ] There is a problem with the current revision checks in is_cppc_supported() that they essentially prevent the CPPC support from working if a new _CPC package format revision being a proper superset of the v3 and only causing _CPC to return a package with more entries (while retaining the types and meaning of the entries defined by the v3) is introduced in the future and used by the platform firmware. In that case, as long as the number of entries in the _CPC return package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to use the v3 support code and disregard the additional package entries added by the new package format revision. For this reason, drop is_cppc_supported() altogether, put the revision checks directly into acpi_cppc_processor_probe() so they are easier to follow and rework them to take the case mentioned above into account. Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3") Cc: 4.18+ <[email protected]> # 4.18+ Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 725cbee29674e895d54ecf80e126b39ef3aa4147 Author: Artem Bityutskiy <[email protected]> Date: Sat Jul 16 09:26:55 2022 +0300 intel_idle: make SPR C1 and C1E be independent [ Upstream commit 1548fac47a114b42063def551eb152a536ed9697 ] This patch partially reverts the changes made by the following commit: da0e58c038e6 intel_idle: add 'preferred_cstates' module argument As that commit describes, on early Sapphire Rapids Xeon platforms the C1 and C1E states were mutually exclusive, so that users could only have either C1 and C6, or C1E and C6. However, Intel firmware engineers managed to remove this limitation and make C1 and C1E to be completely independent, just like on previous Xeon platforms. Therefore, this patch: * Removes commentary describing the old, and now non-existing SPR C1E limitation. * Marks SPR C1E as available by default. * Removes the 'preferred_cstates' parameter handling for SPR. Both C1 and C1E will be available regardless of 'preferred_cstates' value. We expect that all SPR systems are shipping with new firmware, which includes the C1/C1E improvement. Cc: v5.18+ <[email protected]> # v5.18+ Signed-off-by: Artem Bityutskiy <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 746118c58dff0346b7d2087fffa91e07e22601c9 Author: Filipe Manana <[email protected]> Date: Sun Jul 17 22:05:05 2022 +0100 btrfs: join running log transaction when logging new name [ Upstream commit 723df2bcc9e166ac7fb82b3932a53e09415dfcde ] When logging a new name, in case of a rename, we pin the log before changing it. We then either delete a directory entry from the log or insert a key range item to mark the old name for deletion on log replay. However when doing one of those log changes we may have another task that started writing out the log (at btrfs_sync_log()) and it started before we pinned the log root. So we may end up changing a log tree while its writeback is being started by another task syncing the log. This can lead to inconsistencies in a log tree and other unexpected results during log replay, because we can get some committed node pointing to a node/leaf that ends up not getting written to disk before the next log commit. The problem, conceptually, started to happen in commit 88d2beec7e53fc ("btrfs: avoid logging all directory changes during renames"), because there we started to update the log without joining its current transaction first. However the problem only became visible with commit 259c4b96d78dda ("btrfs: stop doing unnecessary log updates during a rename"), and that is because we used to pin the log at btrfs_rename() and then before entering btrfs_log_new_name(), when unlinking the old dentry, we ended up at btrfs_del_inode_ref_in_log() and btrfs_del_dir_entries_in_log(). Both of them join the current log transaction, effectively waiting for any log transaction writeout (due to acquiring the root's log_mutex). This made it safe even after leaving the current log transaction, because we remained with the log pinned when we called btrfs_log_new_name(). Then in commit 259c4b96d78dda ("btrfs: stop doing unnecessary log updates during a rename"), we removed the log pinning from btrfs_rename() and stopped calling btrfs_del_inode_ref_in_log() and btrfs_del_dir_entries_in_log() during the rename, and started to do all the needed work at btrfs_log_new_name(), but without joining the current log transaction, only pinning the log, which is racy because another task may have started writeout of the log tree right before we pinned the log. Both commits landed in kernel 5.18, so it doesn't make any practical difference which should be blamed, but I'm blaming the second commit only because with the first one, by chance, the problem did not happen due to the fact we joined the log transaction after pinning the log and unpinned it only after calling btrfs_log_new_name(). So make btrfs_log_new_name() join the current log transaction instead of pinning it, so that we never do log updates if it's writeout is starting. Fixes: 259c4b96d78dda ("btrfs: stop doing unnecessary log updates during a rename") CC: [email protected] # 5.18+ Reported-by: Zygo Blaxell <[email protected]> Tested-by: Zygo Blaxell <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5022f4039a4d05a0b1f09c4fb14c957d608f7f0b Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:50 2022 +0900 btrfs: zoned: wait until zone is finished when allocation didn't progress [ Upstream commit 2ce543f478433a0eec0f72090d7e814f1d53d456 ] When the allocated position doesn't progress, we cannot submit IOs to finish a block group, but there should be ongoing IOs that will finish a block group. So, in that case, we wait for a zone to be finished and retry the allocation after that. Introduce a new flag BTRFS_FS_NEED_ZONE_FINISH for fs_info->flags to indicate we need a zone finish to have proceeded. The flag is set when the allocator detected it cannot activate a new block group. And, it is cleared once a zone is finished. CC: [email protected] # 5.16+ Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking") Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b6735eff2a6feaaf4eee4ab7b1614c994fcbba21 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:49 2022 +0900 btrfs: zoned: write out partially allocated region [ Upstream commit 898793d992c23dac6126a6a94ad893eae1a2c9df ] cow_file_range() works in an all-or-nothing way: if it fails to allocate an extent for a part of the given region, it gives up all the region including the successfully allocated parts. On cow_file_range(), run_delalloc_zoned() writes data for the region only when it successfully allocate all the region. This all-or-nothing allocation and write-out are problematic when available space in all the block groups are get tight with the active zone restriction. btrfs_reserve_extent() try hard to utilize the left space in the active block groups and gives up finally and fails with -ENOSPC. However, if we send IOs for the successfully allocated region, we can finish a zone and can continue on the rest of the allocation on a newly allocated block group. This patch implements the partial write-out for run_delalloc_zoned(). With this patch applied, cow_file_range() returns -EAGAIN to tell the caller to do something to progress the further allocation, and tells the successfully allocated region with done_offset. Furthermore, the zoned extent allocator returns -EAGAIN to tell cow_file_range() going back to the caller side. Actually, we still need to wait for an IO to complete to continue the allocation. The next patch implements that part. CC: [email protected] # 5.16+ Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking") Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 25934c5214abb6636f67380fe3628d77d53f4725 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:48 2022 +0900 btrfs: zoned: activate necessary block group [ Upstream commit b6a98021e4019c562a23ad151a7e40adfa9f91e5 ] There are two places where allocating a chunk is not enough. These two places are trying to ensure the space by allocating a chunk. To meet the condition for active_total_bytes, we also need to activate a block group there. CC: [email protected] # 5.16+ Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking") Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 407b66b662bb2c05dd033c9a2db808f01fb0244a Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:47 2022 +0900 btrfs: zoned: activate metadata block group on flush_space [ Upstream commit b0931513913633044ed6e3800334c28433c007b0 ] For metadata space on zoned filesystem, reaching ALLOC_CHUNK{,_FORCE} means we don't have enough space left in the active_total_bytes. Before allocating a new chunk, we can try to activate an existing block group in this case. Also, allocating a chunk is not enough to grant a ticket for metadata space on zoned filesystem we need to activate the block group to increase the active_total_bytes. btrfs_zoned_activate_one_bg() implements the activation feature. It will activate a block group by (maybe) finishing a block group. It will give up activating a block group if it cannot finish any block group. CC: [email protected] # 5.16+ Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking") Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 33ed56fe558b5a5b0ec1d08016f800741ec26e36 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:45 2022 +0900 btrfs: zoned: introduce space_info->active_total_bytes [ Upstream commit 6a921de589926a350634e6e279f43fa5b9dbf5ba ] The active_total_bytes, like the total_bytes, accounts for the total bytes of active block groups in the space_info. With an introduction of active_total_bytes, we can check if the reserved bytes can be written to the block groups without activating a new block group. The check is necessary for metadata allocation on zoned filesystem. We cannot finish a block group, which may require waiting for the current transaction, from the metadata allocation context. Instead, we need to ensure the ongoing allocation (reserved bytes) fits in active block groups. Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 17aa1f2aa331f28a7e81f1b7f8445d3fb124eb89 Author: Stefan Roesch <[email protected]> Date: Tue Feb 8 11:31:20 2022 -0800 btrfs: store chunk size in space-info struct [ Upstream commit f6fca3917b4d99d8c13901738afec35f570a3c2f ] The chunk size is stored in the btrfs_space_info structure. It is initialized at the start and is then used. A new API is added to update the current chunk size. This API is used to be able to expose the chunk_size as a sysfs setting. Signed-off-by: Stefan Roesch <[email protected]> Reviewed-by: David Sterba <[email protected]> [ rename and merge helpers, switch atomic type to u64, style fixes ] Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0f43e4fc06e0cd2aee2922726732e917e459efc4 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:46 2022 +0900 btrfs: zoned: disable metadata overcommit for zoned [ Upstream commit 79417d040f4f77b19c701bccc23013b9cdac358d ] The metadata overcommit makes the space reservation flexible but it is also harmful to active zone tracking. Since we cannot finish a block group from the metadata allocation context, we might not activate a new block group and might not be able to actually write out the overcommit reservations. So, disable metadata overcommit for zoned filesystems. We will ensure the reservations are under active_total_bytes in the following patches. CC: [email protected] # 5.16+ Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking") Signed-off-by: Naohiro Aota <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f6ad412c647ac32e3ed2750b99c87c119daea9bb Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:44 2022 +0900 btrfs: zoned: finish least available block group on data bg allocation [ Upstream commit 393f646e34c18b85d0f41272bfcbd475ae3a0d34 ] When we run out of active zones and no sufficient space is left in any block groups, we need to finish one block group to make room to activate a new block group. However, we cannot do this for metadata block groups because we can cause a deadlock by waiting for a running transaction commit. So, do that only for a data block group. Furthermore, the block group to be finished has two requirements. First, the block group must not have reserved bytes left. Having reserved bytes means we have an allocated region but did not yet send bios for it. If that region is allocated by the thread calling btrfs_zone_finish(), it results in a deadlock. Second, the block group to be finished must not be a SYSTEM block group. Finishing a SYSTEM block group easily breaks further chunk allocation by nullifying the SYSTEM free space. In a certain case, we cannot find any zone finish candidate or btrfs_zone_finish() may fail. In that case, we fall back to split the allocation bytes and fill the last spaces left in the block groups. CC: [email protected] # 5.16+ Fixes: afba2bc036b0 ("btrfs: zoned: implement active zone tracking") Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 615535d5315392dc0ce316664a5d8226d22066bb Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:43 2022 +0900 btrfs: let can_allocate_chunk return error [ Upstream commit bb9950d3df7169a673c594d38fb74e241ed4fb2a ] For the later patch, convert the return type from bool to int and return errors. No functional changes. Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d798edf59909acfbd89576198396dc7fb2e98e65 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:41 2022 +0900 btrfs: convert count_max_extents() to use fs_info->max_extent_size [ Upstream commit 7d7672bc5d1038c745716c397d892d21e29de71c ] If count_max_extents() uses BTRFS_MAX_EXTENT_SIZE to calculate the number of extents needed, btrfs release the metadata reservation too much on its way to write out the data. Now that BTRFS_MAX_EXTENT_SIZE is replaced with fs_info->max_extent_size, convert count_max_extents() to use it instead, and fix the calculation of the metadata reservation. CC: [email protected] # 5.12+ Fixes: d8e3fb106f39 ("btrfs: zoned: use ZONE_APPEND write for zoned mode") Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 096e8eb9639b342bc35f9b741cf05e26d0106e92 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:40 2022 +0900 btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size [ Upstream commit f7b12a62f008a3041f42f2426983e59a6a0a3c59 ] On zoned filesystem, data write out is limited by max_zone_append_size, and a large ordered extent is split according the size of a bio. OTOH, the number of extents to be written is calculated using BTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve the metadata bytes to update and/or create the metadata items. The metadata reservation is done at e.g, btrfs_buffered_write() and then released according to the estimation changes. Thus, if the number of extent increases massively, the reserved metadata can run out. The increase of the number of extents easily occurs on zoned filesystem if BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes the following warning on a small RAM environment with disabling metadata over-commit (in the following patch). [75721.498492] ------------[ cut here ]------------ [75721.505624] BTRFS: block rsv 1 returned -28 [75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109 [75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 [75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] [75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286 [75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000 [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e [75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7 [75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28 [75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a [75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000 [75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0 [75721.730499] Call Trace: [75721.735166] <TASK> [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs] [75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs] [75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.769520] ? push_leaf_left+0x420/0x620 [btrfs] [75721.776431] ? memcpy+0x4e/0x60 [75721.781931] split_leaf+0x433/0x12d0 [btrfs] [75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs] [75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs] [75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs] [75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs] [75721.818300] ? lock_downgrade+0x7c0/0x7c0 [75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs] [75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs] [75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs] [75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs] [75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs] [75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs] [75721.869313] ? rcu_read_lock_sched_held+0x16/0x80 [75721.876085] ? lock_release+0x552/0xf80 [75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs] [75721.888886] ? __kasan_check_write+0x14/0x20 [75721.895152] ? do_raw_read_unlock+0x44/0x80 [75721.901323] ? _raw_write_lock_irq+0x60/0x80 [75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs] [75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs] [75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs] [75721.929166] ? _raw_write_unlock+0x23/0x40 [75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs] [75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs] [75721.949906] ? try_to_wake_up+0x30/0x14a0 [75721.955700] ? btrfs_unlink_subvol+0xda0/0xda0 [btrfs] [75721.962661] ? rcu_read_lock_sched_held+0x16/0x80 [75721.969111] ? lock_acquire+0x41b/0x4c0 [75721.974982] finish_ordered_fn+0x15/0x20 [btrfs] [75721.981639] btrfs_work_helper+0x1af/0xa80 [btrfs] [75721.988184] ? _raw_spin_unlock_irq+0x28/0x50 [75721.994643] process_one_work+0x815/0x1460 [75722.000444] ? pwq_dec_nr_in_flight+0x250/0x250 [75722.006643] ? do_raw_spin_trylock+0xbb/0x190 [75722.013086] worker_thread+0x59a/0xeb0 [75722.018511] kthread+0x2ac/0x360 [75722.023428] ? process_one_work+0x1460/0x1460 [75722.029431] ? kthread_complete_and_exit+0x30/0x30 [75722.036044] ret_from_fork+0x22/0x30 [75722.041255] </TASK> [75722.045047] irq event stamp: 0 [75722.049703] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [75722.057610] hardirqs last disabled at (0): [<ffffffff8118a94a>] copy_process+0x1c1a/0x66b0 [75722.067533] softirqs last enabled at (0): [<ffffffff8118a989>] copy_process+0x1c59/0x66b0 [75722.077423] softirqs last disabled at (0): [<0000000000000000>] 0x0 [75722.085335] ---[ end trace 0000000000000000 ]--- To fix the estimation, we need to introduce fs_info->max_extent_size to replace BTRFS_MAX_EXTENT_SIZE, which allow setting the different size for regular vs zoned filesystem. Set fs_info->max_extent_size to BTRFS_MAX_EXTENT_SIZE by default. On zoned filesystem, it is set to fs_info->max_zone_append_size. CC: [email protected] # 5.12+ Fixes: d8e3fb106f39 ("btrfs: zoned: use ZONE_APPEND write for zoned mode") Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 506e8ae2193622da433c1eca4b0878a36c00ef47 Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:39 2022 +0900 btrfs: zoned: revive max_zone_append_bytes [ Upstream commit c2ae7b772ef4e86c5ddf3fd47bf59045ae96a414 ] This patch is basically a revert of commit 5a80d1c6a270 ("btrfs: zoned: remove max_zone_append_size logic"), but without unnecessary ASSERT and check. The max_zone_append_size will be used as a hint to estimate the number of extents to cover delalloc/writeback region in the later commits. The size of a ZONE APPEND bio is also limited by queue_max_segments(), so this commit considers it to calculate max_zone_append_size. Technically, a bio can be larger than queue_max_segments() * PAGE_SIZE if the pages are contiguous. But, it is safe to consider "queue_max_segments() * PAGE_SIZE" as an upper limit of an extent size to calculate the number of extents needed to write data. Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bf764bdc37283d84a3558bc43ee4e84a73bc04fa Author: Naohiro Aota <[email protected]> Date: Sat Jul 9 08:18:38 2022 +0900 block: add bdev_max_segments() helper [ Upstream commit 65ea1b66482f415d51cd46515b02477257330339 ] Add bdev_max_segments() like other queue parameters. Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Jens Axboe <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3e36602adace358397ea38c0dfae11336321b9f8 Author: Nikolay Borisov <[email protected]> Date: Thu Jun 23 10:55:47 2022 +0300 btrfs: properly flag filesystem with BTRFS_FEATURE_INCOMPAT_BIG_METADATA [ Upstream commit e26b04c4c91925dba57324db177a24e18e2d0013 ] Commit 6f93e834fa7c seemingly inadvertently moved the code responsible for flagging the filesystem as having BIG_METADATA to a place where setting the flag was essentially lost. This means that filesystems created with kernels containing this bug (starting with 5.15) can potentially be mounted by older (pre-3.4) kernels. In reality chances for this happening are low because there are other incompat flags introduced in the mean time. Still the correct behavior is to set INCOMPAT_BIG_METADATA flag and persist this in the superblock. Fixes: 6f93e834fa7c ("btrfs: fix upper limit for max_inline for page size 64K") CC: [email protected] # 5.4+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Nikolay Borisov <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ff04ffd79cba85fee7bc2271e9020abdd836678d Author: Josef Bacik <[email protected]> Date: Mon Jun 13 18:31:17 2022 -0400 btrfs: reset block group chunk force if we have to wait [ Upstream commit 1314ca78b2c35d3e7d0f097268a2ee6dc0d369ef ] If you try to force a chunk allocation, but you race with another chunk allocation, you will end up waiting on the chunk allocation that just occurred and then allocate another chunk. If you have many threads all doing this at once you can way over-allocate chunks. Fix this by resetting force to NO_FORCE, that way if we think we need to allocate we can, otherwise we don't force another chunk allocation if one is already happening. Reviewed-by: Filipe Manana <[email protected]> CC: [email protected] # 5.4+ Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9fff2b774e93b1b76f3e103d3ca11b6c24d5eeeb Author: Naohiro Aota <[email protected]> Date: Tue Jun 21 15:41:01 2022 +0900 btrfs: fix error handling of fallback uncompress write [ Upstream commit 71aa147b4d9d81fa65afa6016f50d7818b64a54f ] When cow_file_range() fails in the middle of the allocation loop, it unlocks the pages but leaves the ordered extents intact. Thus, we need to call btrfs_cleanup_ordered_extents() to finish the created ordered extents. Also, we need to call end_extent_writepage() if locked_page is available because btrfs_cleanup_ordered_extents() never processes the region on the locked_page. Furthermore, we need to set the mapping as error if locked_page is unavailable before unlocking the pages, so that the errno is properly propagated to the user space. CC: [email protected] # 5.18+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e160aa87c87a9c4e0c8d1430235f715a3a91e2cd Author: Naohiro Aota <[email protected]> Date: Tue Jun 21 15:40:59 2022 +0900 btrfs: ensure pages are unlocked on cow_file_range() failure [ Upstream commit 9ce7466f372d83054c7494f6b3e4b9abaf3f0355 ] There is a hung_task report on zoned btrfs like below. https://github.com/naota/linux/issues/59 [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] <TASK> [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] </TASK> While we debug the issue, we found running fstests generic/551 on 5GB non-zoned null_blk device in the emulated zoned mode also had a similar hung issue. Also, we can reproduce the same symptom with an error injected cow_file_range() setup. The hang occurs when cow_file_range() fails in the middle of allocation. cow_file_range() called from do_allocation_zoned() can split the give region ([start, end]) for allocation depending on current block group usages. When btrfs can allocate bytes for one part of the split regions but fails for the other region (e.g. because of -ENOSPC), we return the error leaving the pages in the succeeded regions locked. Technically, this occurs only when @unlock == 0. Otherwise, we unlock the pages in an allocated region after creating an ordered extent. Considering the callers of cow_file_range(unlock=0) won't write out the pages, we can unlock the pages on error exit from cow_file_range(). So, we can ensure all the pages except @locked_page are unlocked on error case. In summary, cow_file_range now behaves like this: - page_started == 1 (return value) - All the pages are unlocked. IO is started. - unlock == 1 - All the pages except @locked_page are unlocked in any case - unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @locked_page are unlocked Fixes: 42c011000963 ("btrfs: zoned: introduce dedicated data write path for zoned filesystems") CC: [email protected] # 5.12+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 77cf0352146ae283f878403fd59d2438f7c017c4 Author: Josef Bacik <[email protected]> Date: Mon Jun 13 15:09:48 2022 -0400 btrfs: tree-log: make the return value for log syncing consistent [ Upstream commit f31f09f6be1c6c1a673e0566e258281a7bbaaa51 ] Currently we will return 1 or -EAGAIN if we decide we need to commit the transaction rather than sync the log. In practice this doesn't really matter, we interpret any !0 and !BTRFS_NO_LOG_SYNC as needing to commit the transaction. However this makes it hard to figure out what the correct thing to do is. Fix this up by defining BTRFS_LOG_FORCE_COMMIT and using this in all the places where we want to force the transaction to be committed. CC: [email protected] # 5.15+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0c9bb1acd1d103a3070b2126870eb52761d606ce Author: Jinke Han <[email protected]> Date: Wed Jul 20 17:36:16 2022 +0800 block: don't allow the same type rq_qos add more than once [ Upstream commit 14a6e2eb7df5c7897c15b109cba29ab0c4a791b6 ] In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn. The reason can be described as follows: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list. And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above. Signed-off-by: Jinke Han <[email protected]> Reviewed-by: Muchun Song <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b480d1e9a8c11ecc1c99dc01814b28e3103bd0a0 Author: Chen Zhongjin <[email protected]> Date: Tue May 10 17:46:39 2022 +0800 locking/csd_lock: Change csdlock_debug from early_param to __setup [ Upstream commit 9c9b26b0df270d4f9246e483a44686fca951a29c ] The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init(). This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()". Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these. Fixes: 8d0968cc6b8f ("locking/csd_lock: Add boot parameter for controlling CSD lock debugging") Cc: [email protected] Reported-by: Chen jingwen <[email protected]> Signed-off-by: Chen Zhongjin <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 141c2785d940c88998d5b704bbf2e2c72b4f9cf0 Author: Jason A. Donenfeld <[email protected]> Date: Sun Jul 17 23:53:34 2022 +0200 timekeeping: contribute wall clock to rng on time change [ Upstream commit b8ac29b40183a6038919768b5d189c9bd91ce9b4 ] The rng's random_init() function contributes the real time to the rng at boot time, so that events can at least start in relation to something particular in the real world. But this clock might not yet be set that point in boot, so nothing is contributed. In addition, the relation between minor clock changes from, say, NTP, and the cycle counter is potentially useful entropic data. This commit addresses this by mixing in a time stamp on calls to settimeofday and adjtimex. No entropy is credited in doing so, so it doesn't make initialization faster, but it is still useful input to have. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Reviewed-by: Thomas Gleixner <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e2632767927ee651298b52498ca373ab6dd9be9d Author: Pali Rohár <[email protected]> Date: Tue Nov 2 18:12:58 2021 +0100 ARM: Marvell: Update PCIe fixup [ Upstream commit fdaa3725831972284ef2779ddba00491d9dbbfca ] - The code relies on rc_pci_fixup being called, which only happens when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting this causes a booting failure with a non-obvious cause. - Update rc_pci_fixup to set the class properly, copying the more modern style from other places - Correct the rc_pci_fixup comment This patch just re-applies commit 1dc831bf53fd ("ARM: Kirkwood: Update PCI-E fixup") for all other Marvell ARM platforms which have same buggy PCIe controller and do not use pci-mvebu.c controller driver yet. Long-term goal for these Marvell ARM platforms should be conversion to pci-mvebu.c controller driver and removal of these fixups in arch code. Signed-off-by: Pali Rohár <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: [email protected] Signed-off-by: Gregory CLEMENT <greg[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 783bc69cc2e0023d30301eeeba2f53a9abaa5dcc Author: Tyler Hicks <[email protected]> Date: Sun Jul 10 09:14:02 2022 -0500 net/9p: Initialize the iounit field during fid creation [ Upstream commit aa7aeee169480e98cf41d83c01290a37e569be6d ] Ensure that the fid's iounit field is set to zero when a new fid is created. Certain 9P operations, such as OPEN and CREATE, allow the server to reply with an iounit size which the client code assigns to the p9_fid struct shortly after the fid is created by p9_fid_create(). On the other hand, an XATTRWALK operation doesn't allow for the server to specify an iounit value. The iounit field of the newly allocated p9_fid struct remained uninitialized in that case. Depending on allocation patterns, the iounit value could have been something reasonable that was carried over from previously freed fids or, in the worst case, could have been arbitrary values from non-fid related usages of the memory location. The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel after the uninitialized iounit field resulted in the typical sequence of two getxattr(2) syscalls, one to get the size of an xattr and another after allocating a sufficiently sized buffer to fit the xattr value, to hit an unexpected ERANGE error in the second call to getxattr(2). An uninitialized iounit field would sometimes force rsize to be smaller than the xattr value size in p9_client_read_once() and the 9P server in WSL refused to chunk up the READ on the attr_fid and, instead, returned ERANGE to the client. The virtfs server in QEMU seems happy to chunk up the READ and this problem goes undetected there. Link: https://lkml.kernel.org/r/[email protected] Fixes: ebf46264a004 ("fs/9p: Add support user. xattr") Cc: [email protected] Signed-off-by: Tyler Hicks <[email protected]> Reviewed-by: Christian Schoenebeck <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e4dbe24f4bfd8377e7ba79fdcdb7c4d6eb1c6790 Author: Luo Meng <[email protected]> Date: Thu Jul 14 19:28:25 2022 +0800 dm thin: fix use-after-free crash in dm_sm_register_threshold_callback [ Upstream commit 3534e5a5ed2997ca1b00f44a0378a075bd05e8a3 ] Fault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the metadata space maps will be destroyed. If a DM table reload then happens for this failed thin-pool, a use-after-free will occur in dm_sm_register_threshold_callback (called from dm_pool_register_metadata_threshold). Fix this by in dm_pool_register_metadata_threshold() by returning the -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr() with a new error message: "Error registering metadata threshold". Fixes: ac8c3f3df65e4 ("dm thin: generate event when metadata threshold passed") Cc: [email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Luo Meng <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 351db9a0357428384ba15fc1968f39d5e7693f6b Author: Steven Rostedt (Google) <[email protected]> Date: Tue Jul 5 18:44:54 2022 -0400 tracing/events: Add __vstring() and __assign_vstr() helper macros [ Upstream commit 0563231f93c6d1f582b168a47753b345c1e20d81 ] There's several places that open code the following logic: TP_STRUCT__entry(__dynamic_array(char, msg, MSG_MAX)), TP_fast_assign(vsnprintf(__get_str(msg), MSG_MAX, vaf->fmt, *vaf->va);) To load a string created by variable array va_list. The main issue with this approach is that "MSG_MAX" usage in the __dynamic_array() portion. That actually just reserves the MSG_MAX in the event, and even wastes space because there's dynamic meta data also saved in the event to denote the offset and size of the dynamic array. It would have been better to just use a static __array() field. Instead, create __vstring() and __assign_vstr() that work like __string and __assign_str() but instead of taking a destination string to copy, take a format string and a va_list pointer and fill in the values. It uses the helper: #define __trace_event_vstr_len(fmt, va) \ ({ \ va_list __ap; \ int __ret; \ \ va_copy(__ap, *(va)); \ __ret = vsnprintf(NULL, 0, fmt, __ap) + 1; \ va_end(__ap); \ \ min(__ret, TRACE_EVENT_STR_MAX); \ }) To figure out the length to store the string. It may be slightly slower as it needs to run the vsnprintf() twice, but it now saves space on the ring buffer. Link: https://lkml.kernel.org/r/[email protected] Cc: Dennis Dalessandro <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Leon Romanovsky <[email protected]> Cc: Kalle Valo <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Arend van Spriel <[email protected]> Cc: Franky Lin <[email protected]> Cc: Hante Meuleman <[email protected]> Cc: Gregory Greenman <[email protected]> Cc: Peter Chen <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Mathias Nyman <[email protected]> Cc: Chunfeng Yun <[email protected]> Cc: Bin Liu <[email protected]> Cc: Marek Lindner <[email protected]> Cc: Simon Wunderlich <[email protected]> Cc: Antonio Quartulli <[email protected]> Cc: Sven Eckelmann <[email protected]> Cc: Johannes Berg <[email protected]> Cc: Jim Cromie <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 90bafcad8c28d7a0a024e684551e7b4368ff6943 Author: Michal Suchanek <[email protected]> Date: Thu Jul 14 21:40:27 2022 +0800 kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification [ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ] commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype") adds support for KEXEC_SIG verification with keys from platform keyring but the built-in keys and secondary keyring are not used. Add support for the built-in keys and secondary keyring as x86 does. Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype") Cc: [email protected] Cc: Philipp Rudo <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Michal Suchanek <[email protected]> Reviewed-by: "Lee, Chun-Yi" <[email protected]> Acked-by: Baoquan He <[email protected]> Signed-off-by: Coiby Xu <[email protected]> Acked-by: Heiko Carstens <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b302cdef14ccc823888e6853ef3809f01f321017 Author: Coiby Xu <[email protected]> Date: Thu Jul 14 21:40:24 2022 +0800 kexec: clean up arch_kexec_kernel_verify_sig [ Upstream commit 689a71493bd2f31c024f8c0395f85a1fd4b2138e ] Before commit 105e10e2cf1c ("kexec_file: drop weak attribute from functions"), there was already no arch-specific implementation of arch_kexec_kernel_verify_sig. With weak attribute dropped by that commit, arch_kexec_kernel_verify_sig is completely useless. So clean it up. Note later patches are dependent on this patch so it should be backported to the stable tree as well. Cc: [email protected] Suggested-by: Eric W. Biederman <[email protected]> Reviewed-by: Michal Suchanek <[email protected]> Acked-by: Baoquan He <[email protected]> Signed-off-by: Coiby Xu <[email protected]> [[email protected]: reworded patch description "Note"] Link: https://lore.kernel.org/linux-integrity/[email protected]/ Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 08f7483635ae536ec12682234a7efea7f5d052d8 Author: Naveen N. Rao <[email protected]> Date: Fri Jul 1 13:04:04 2022 +0530 kexec_file: drop weak attribute from functions [ Upstream commit 65d9a9a60fd71be964effb2e94747a6acb6e7015 ] As requested (http://lkml.kernel.org/r/[email protected]), this series converts weak functions in kexec to use the #ifdef approach. Quoting the 3e35142ef99fe ("kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add]") changelog: : Since commit d1bcae833b32f1 ("ELF: Don't generate unused section symbols") : [1], binutils (v2.36+) started dropping section symbols that it thought : were unused. This isn't an issue in general, but with kexec_file.c, gcc : is placing kexec_arch_apply_relocations[_add] into a separate : .text.unlikely section and the section symbol ".text.unlikely" is being : dropped. Due to this, recordmcount is unable to find a non-weak symbol in : .text.unlikely to generate a relocation record against. This patch (of 2); Drop __weak attribute from functions in kexec_file.c: - arch_kexec_kernel_image_probe() - arch_kimage_file_post_load_cleanup() - arch_kexec_kernel_image_load() - arch_kexec_locate_mem_hole() - arch_kexec_kernel_verify_sig() arch_kexec_kernel_image_load() calls into kexec_image_load_default(), so drop the static attribute for the latter. arch_kexec_kernel_verify_sig() is not overridden by any architecture, so drop the __weak attribute. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/2cd7c[email protected]linux.vnet.ibm.com Signed-off-by: Naveen N. Rao <[email protected]> Suggested-by: Eric Biederman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7c5917256d7984926e21a80f6b957c69d6e674fd Author: Mikulas Patocka <[email protected]> Date: Wed Jul 13 07:09:04 2022 -0400 dm writecache: set a default MAX_WRITEBACK_JOBS [ Upstream commit ca7dc242e358e46d963b32f9d9dd829785a9e957 ] dm-writecache has the capability to limit the number of writeback jobs in progress. However, this feature was off by default. As such there were some out-of-memory crashes observed when lowering the low watermark while the cache is full. This commit enables writeback limit by default. It is set to 256MiB or 1/16 of total system memory, whichever is smaller. Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 374eece193d05937345be6af1ef28dfb2473049b Author: Robert Marko <[email protected]> Date: Thu Jun 23 17:50:03 2022 +0200 PCI: qcom: Power on PHY before IPQ8074 DBI register accesses [ Upstream commit a0e43bb9973b06ce5c666f0901e104e2037c1b34 ] Currently the Gen2 port in IPQ8074 will cause the system to hang as it accesses DBI registers in qcom_pcie_init_2_3_3(), and those are only accesible after phy_power_on(). Move the DBI read/writes to a new qcom_pcie_post_init_2_3_3(), which is executed after phy_power_on(). Link: https://lore.kernel.org/r/[email protected] Fixes: a0fd361db8e5 ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Cc: [email protected] # v5.11+ Signed-off-by: Sasha Levin <[email protected]> commit 54bc741a876ccca0f58b826d2dfa578cce8174ea Author: Mohamed Khalfella <[email protected]> Date: Mon May 9 18:14:41 2022 +0000 PCI/AER: Iterate over error counters instead of error strings [ Upstream commit 5e6ae050955b566484f3cc6a66e3925eae87a0ed ] Previously we iterated over AER stat *names*, e.g., aer_correctable_error_string[32], but the actual stat *counters* may not be that large, e.g., pdev->aer_stats->dev_cor_errs[16], which means that we printed junk in the sysfs stats files. Iterate over the stat counter arrays instead of the names to avoid this junk. Also, added a build time check to make sure all counters have entries in strings array. Fixes: 0678e3109a3c ("PCI/AER: Simplify __aer_print_error()") Link: https://lore.kernel.org/r/[email protected] Reported-by: Meeta Saggi <[email protected]> Signed-off-by: Mohamed Khalfella <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Meeta Saggi <[email protected]> Reviewed-by: Eric Badger <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]> commit c2304c50f4d94f56c2e326f25c9dc8cf2ba6f5fa Author: Alexander Lobakin <[email protected]> Date: Tue Jul 12 17:38:36 2022 +0200 iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) [ Upstream commit b0b0b77ea611e3088e9523e60860f4f41b62b235 ] KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] <TASK> [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to an insane array index when calculating bit position in memory. For now, add an explicit check for @node being not %NUMA_NO_NODE before calling test_bit(). The actual logics didn't change here at all. [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d Fixes: ee34b32d8c29 ("dmar: support for parsing Remapping Hardware Static Affinity structure") Cc: [email protected] # 2.6.33+ Reported-by: kernel test robot <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 010fc77570b5858a054b2d9baad1feec1cbf6d6d Author: Sean Christopherson <[email protected]> Date: Thu May 12 22:27:14 2022 +0000 KVM: x86: Signal #GP, not -EPERM, on bad WRMSR(MCi_CTL/STATUS) [ Upstream commit 2368048bf5c2ec4b604ac3431564071e89a0bc71 ] Return '1', not '-1', when handling an illegal WRMSR to a MCi_CTL or MCi_STATUS MSR. The behavior of "all zeros' or "all ones" for CTL MSRs is architectural, as is the "only zeros" behavior for STATUS MSRs. I.e. the intent is to inject a #GP, not exit to userspace due to an unhandled emulation case. Returning '-1' gets interpreted as -EPERM up the stack and effecitvely kills the guest. Fixes: 890ca9aefa78 ("KVM: Add MCE support") Fixes: 9ffd986c6e4e ("KVM: X86: #GP when guest attempts to write MCi_STATUS register w/o 0") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Reviewed-by: Jim Mattson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4b9637cd89d9f87364e35657a2489002320de71f Author: Lev Kujawski <[email protected]> Date: Sat May 21 08:15:11 2022 +0000 KVM: set_msr_mce: Permit guests to ignore single-bit ECC errors [ Upstream commit 0471a7bd1bca2a47a5f378f2222c5cf39ce94152 ] Certain guest operating systems (e.g., UNIXWARE) clear bit 0 of MC1_CTL to ignore single-bit ECC data errors. Single-bit ECC data errors are always correctable and thus are safe to ignore because they are informational in nature rather than signaling a loss of data integrity. Prior to this patch, these guests would crash upon writing MC1_CTL, with resultant error messages like the following: error: kvm run failed Operation not permitted EAX=fffffffe EBX=fffffffe ECX=00000404 EDX=ffffffff ESI=ffffffff EDI=00000001 EBP=fffdaba4 ESP=fffdab20 EIP=c01333a5 EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0108 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0100 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0108 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0108 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0000 00000000 ffffffff 00c00000 GS =0000 00000000 ffffffff 00c00000 LDT=0118 c1026390 00000047 00008200 DPL=0 LDT TR =0110 ffff5af0 00000067 00008b00 DPL=0 TSS32-busy GDT= ffff5020 000002cf IDT= ffff52f0 000007ff CR0=8001003b CR2=00000000 CR3=0100a000 CR4=00000230 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 Code=08 89 01 89 51 04 c3 8b 4c 24 08 8b 01 8b 51 04 8b 4c 24 04 <0f> 30 c3 f7 05 a4 6d ff ff 10 00 00 00 74 03 0f 31 c3 33 c0 33 d2 c3 8d 74 26 00 0f 31 c3 Signed-off-by: Lev Kujawski <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cb604d1c53e6993ea766f44b7e830699fe6ae796 Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:37 2022 +0300 intel_th: pci: Add Raptor Lake-S CPU support [ Upstream commit ff46a601afc5a66a81c3945b83d0a2caeb88e8bc ] Add support for the Trace Hub in Raptor Lake-S CPU. Reviewed-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c0fd76f69b720b9038752bf180e0bb0825587238 Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:36 2022 +0300 intel_th: pci: Add Raptor Lake-S PCH support [ Upstream commit 23e2de5826e2fc4dd43e08bab3a2ea1a5338b063 ] Add support for the Trace Hub in Raptor Lake-S PCH. Reviewed-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 03c14650165d1a96da117485efb8c255570f078d Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:35 2022 +0300 intel_th: pci: Add Meteor Lake-P support [ Upstream commit 802a9a0b1d91274ef10d9fe429b4cc1e8c200aef ] Add support for the Trace Hub in Meteor Lake-P. Reviewed-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4f2d7b46d6b53c07f44a4f8f8f4438888f0e9e87 Author: Sudeep Holla <[email protected]> Date: Fri Jul 1 17:03:10 2022 +0100 firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails [ Upstream commit 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 ] When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] # 4.19+ Reported-by: huhai <[email protected]> Reviewed-by: Jackie Liu <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 071b21aac7896306d293f83667afac774ec2cacb Author: Jason A. Donenfeld <[email protected]> Date: Sat May 28 21:44:07 2022 +0200 crypto: blake2s - remove shash module [ Upstream commit 2d16803c562ecc644803d42ba98a8e0aef9c014e ] BLAKE2s has no currently known use as an shash. Just remove all of this unnecessary plumbing. Removing this shash was something we talked about back when we were making BLAKE2s a built-in, but I simply never got around to doing it. So this completes that project. Importantly, this fixs a bug in which the lib code depends on crypto_simd_disabled_for_test, causing linker errors. Also add more alignment tests to the selftests and compare SIMD and non-SIMD compression functions, to make up for what we lose from testmgr.c. Reported-by: gaochao <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: [email protected] Fixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6013ce2472f33d4ae184418de110fd1c263a060d Author: Jitao Shi <[email protected]> Date: Fri May 20 10:00:06 2022 +0800 drm/mediatek: Keep dsi as LP00 before dcs cmds transfer [ Upstream commit 39e8d062b03c3dc257d880d82bd55cdd9e185a3b ] To comply with the panel sequence, hold the mipi signal to LP00 before the dcs cmds transmission, and pull the mipi signal high from LP00 to LP11 until the start of the dcs cmds transmission. The normal panel timing is : (1) pp1800 DC pull up (2) avdd & avee AC pull high (3) lcm_reset pull high -> pull low -> pull high (4) Pull MIPI signal high (LP11) -> initial code -> send video data (HS mode) The power-off sequence is reversed. If dsi is not in cmd mode, then dsi will pull the mipi signal high in the mtk_output_dsi_enable function. The delay in lane_ready func is the reaction time of dsi_rx after pulling up the mipi signal. Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Cc: <[email protected]> # 5.10.x: 7f6335c6a258: drm/mediatek: Modify dsi funcs to atomic operations Cc: <[email protected]> # 5.10.x: cde7e2e35c28: drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs Cc: <[email protected]> # 5.10.x Signed-off-by: Jitao Shi <[email protected]> Signed-off-by: Xinlei Lee <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 03c8facf9dcbee13e169b8b6d82af55ab4119173 Author: Phil Auld <[email protected]> Date: Fri Jul 15 09:49:24 2022 -0400 drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist commit 7ee951acd31a88f941fd6535fbdee3a1567f1d63 upstream. Using bin_attributes with a 0 size causes fstat and friends to return that 0 size. This breaks userspace code that retrieves the size before reading the file. Rather than reverting 75bd50fa841 ("drivers/base/node.c: use bin_attribute to break the size limitation of cpumap ABI") let's put in a size value at compile time. For cpulist the maximum size is on the order of NR_CPUS * (ceil(log10(NR_CPUS)) + 1)/2 which for 8192 is 20480 (8192 * 5)/2. In order to get near that you'd need a system with every other CPU on one node. For example: (0,2,4,8, ... ). To simplify the math and support larger NR_CPUS in the future we are using (NR_CPUS * 7)/2. We also set it to a min of PAGE_SIZE to retain the older behavior for smaller NR_CPUS. The cpumap file the size works out to be NR_CPUS/4 + NR_CPUS/32 - 1 (or NR_CPUS * 9/32 - 1) including the ","s. Add a set of macros for these values to cpumask.h so they can be used in multiple places. Apply these to the handful of such files in drivers/base/topology.c as well as node.c. As an example, on an 80 cpu 4-node system (NR_CPUS == 8192): before: -r--r--r--. 1 root root 0 Jul 12 14:08 system/node/node0/cpulist -r--r--r--. 1 root root 0 Jul 11 17:25 system/node/node0/cpumap after: -r--r--r--. 1 root root 28672 Jul 13 11:32 system/node/node0/cpulist -r--r--r--. 1 root root 4096 Jul 13 11:31 system/node/node0/cpumap CONFIG_NR_CPUS = 16384 -r--r--r--. 1 root root 57344 Jul 13 14:03 system/node/node0/cpulist -r--r--r--. 1 root root 4607 Jul 13 14:02 system/node/node0/cpumap The actual number of cpus doesn't matter for the reported size since they are based on NR_CPUS. Fixes: 75bd50fa841d ("drivers/base/node.c: use bin_attribute to break the size limitation of cpumap ABI") Fixes: bb9ec13d156e ("topology: use bin_attribute to break the size limitation of cpumap ABI") Cc: Greg Kroah-Hartman <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Yury Norov <[email protected]> Cc: [email protected] Acked-by: Yury Norov <[email protected]> (for include/linux/cpumask.h) Signed-off-by: Phil Auld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e622f144b624655aeb59667854552f717aa26c3e Author: Guo Ren <[email protected]> Date: Sun Jul 31 22:34:24 2022 -0400 csky: abiv1: Fixup compile error commit 45fef4c4b9c94e86d9c13f0b2e7e71bb32254509 upstream. LD vmlinux.o arch/csky/lib/string.o: In function `memmove': string.c:(.text+0x108): multiple definition of `memmove' lib/string.o:string.c:(.text+0x7e8): first defined here arch/csky/lib/string.o: In function `memset': string.c:(.text+0x148): multiple definition of `memset' lib/string.o:string.c:(.text+0x2ac): first defined here scripts/Makefile.vmlinux_o:68: recipe for target 'vmlinux.o' failed make[4]: *** [vmlinux.o] Error 1 Fixes: e4df2d5e852a ("csky: Add C based string functions") Signed-off-by: Guo Ren <[email protected]> Signed-off-by: Guo Ren <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 504090815c1ad3fd3fa34618b54d706727f8911c Author: David Collins <[email protected]> Date: Mon Jun 27 16:55:12 2022 -0700 spmi: trace: fix stack-out-of-bound access in SPMI tracing functions commit 2af28b241eea816e6f7668d1954f15894b45d7e3 upstream. trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of "len + 1". This leads to one extra byte being read beyond the end of the specified buffer. Fix this out-of-bound memory access by using a length of "len" instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task [email protected]/1314 ... Call trace: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... addr ffffffc0265b7540 is located in stack of task [email protected]/1314 at offset 32 in frame: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object: [32, 33) 'status' Memory state around the buggy address: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ================================================================== Fixes: a9fce374815d ("spmi: add command tracepoints for SPMI") Cc: [email protected] Reviewed-by: Stephen Boyd <[email protected]> Acked-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: David Collins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 6fc0b164bbc3c772152b67038464a6324fb688ce Author: Al Viro <[email protected]> Date: Mon Jul 4 17:26:29 2022 -0400 __follow_mount_rcu(): verify that mount_lock remains unchanged commit 20aac6c60981f5bfacd66661d090d907bf1482f0 upstream. Validate mount_lock seqcount as soon as we cross into mount in RCU mode. Sure, ->mnt_root is pinned and will remain so until we do rcu_read_unlock() anyway, and we will eventually fail to unlazy if the mount_lock had been touched, but we might run into a hard error (e.g. -ENOENT) before trying to unlazy. And it's possible to end up with RCU pathwalk racing with rename() and umount() in a way that would fail with -ENOENT while non-RCU pathwalk would've succeeded with any timings. Once upon a time we hadn't needed that, but analysis had been subtle, brittle and went out of window as soon as RENAME_EXCHANGE had been added. It's narrow, hard to hit and won't get you anything other than stray -ENOENT that could be arranged in much easier way with the same priveleges, but it's a bug all the same. Cc: [email protected] X-sky-is-falling: unlikely Fixes: da1ce0670c14 "vfs: add cross-rename" Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 950ce0155696e0219d441e87fdba8224d725eddb Author: Xie Shaowen <[email protected]> Date: Tue Aug 2 15:20:33 2022 +0800 Input: gscps2 - check return value of ioremap() in gscps2_probe() commit e61b3125a4f036b3c6b87ffd656fc1ab00440ae9 upstream. The function ioremap() in gscps2_probe() can fail, so its return value should be checked. Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache") Cc: <[email protected]> # v5.6+ Reported-by: Hacash Robot <[email protected]> Signed-off-by: Xie Shaowen <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b2fc1723eb65abb83e00d5f011de670296af0b28 Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Aug 9 14:07:51 2022 -0300 posix-cpu-timers: Cleanup CPU timers before freeing them during exec commit e362359ace6f87c201531872486ff295df306d13 upstream. Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") started looking up tasks by PID when deleting a CPU timer. When a non-leader thread calls execve, it will switch PIDs with the leader process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find the task because the timer still points out to the old PID. That means that armed timers won't be disarmed, that is, they won't be removed from the timerqueue_list. exit_itimers will still release their memory, and when that list is later processed, it leads to a use-after-free. Clean up the timers from the de-threaded task before freeing them. This prevents a reported use-after-free. Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 508b99039bc4338cfe336ab1c7e2371e2e41824f Author: Bharath SM <[email protected]> Date: Thu Aug 11 19:46:11 2022 +0000 SMB3: fix lease break timeout when multiple deferred close handles for the same file. commit 9e31678fb403eae0f4fe37c6374be098835c73cd upstream. Solution is to send lease break ack immediately even in case of deferred close handles to avoid lease break request timing out and let deferred closed handle gets closed as scheduled. Later patches could optimize cases where we then close some of these handles sooner for the cases where lease break is to 'none' Cc: [email protected] Signed-off-by: Bharath SM <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 799e4f9aab8044eece95d58dadf3242527bedccc Author: Alexander Lobakin <[email protected]> Date: Fri Jul 15 17:15:36 2022 +0200 x86/olpc: fix 'logical not is only applied to the left hand side' commit 3a2ba42cbd0b669ce3837ba400905f93dd06c79f upstream. The bitops compile-time optimization series revealed one more problem in olpc-xo1-sci.c:send_ebook_state(), resulted in GCC warnings: arch/x86/platform/olpc/olpc-xo1-sci.c: In function 'send_ebook_state': arch/x86/platform/olpc/olpc-xo1-sci.c:83:63: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 83 | if (!!test_bit(SW_TABLET_MODE, ebook_switch_idev->sw) == state) | ^~ arch/x86/platform/olpc/olpc-xo1-sci.c:83:13: note: add parentheses around left hand side expression to silence this warning Despite this code working as intended, this redundant double negation of boolean value, together with comparing to `char` with no explicit conversion to bool, makes compilers think the author made some unintentional logical mistakes here. Make it the other way around and negate the char instead to silence the warnings. Fixes: d2aa37411b8e ("x86/olpc/xo1/sci: Produce wakeup events for buttons and switches") Cc: [email protected] # 3.5+ Reported-by: Guenter Roeck <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-and-tested-by: Guenter Roeck <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 663cdda2716b70751df9c7e60b81bd0850fdfe3c Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Aug 2 15:04:16 2022 +0900 x86/kprobes: Update kcb status flag after singlestepping commit dec8784c9088b131a1523f582c2194cfc8107dc0 upstream. Fix kprobes to update kcb (kprobes control block) status flag to KPROBE_HIT_SSDONE even if the kp->post_handler is not set. This bug may cause a kernel panic if another INT3 user runs right after kprobes because kprobe_int3_handler() misunderstands the INT3 is kprobe's single stepping INT3. Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Reported-by: Daniel Müller <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Daniel Müller <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7353c797f79443395dd56f1ac9e2ef58eca02abb Author: Steven Rostedt (Google) <[email protected]> Date: Tue Jul 26 10:18:51 2022 -0400 ftrace/x86: Add back ftrace_expected assignment commit ac6c1b2ca77e722a1e5d651f12f437f2f237e658 upstream. When a ftrace_bug happens (where ftrace fails to modify a location) it is helpful to have what was at that location as well as what was expected to be there. But with the conversion to text_poke() the variable that assigns the expected for debugging was dropped. Unfortunately, I noticed this when I needed it. Add it back. Link: https://lkml.kernel.org/r/[email protected] Cc: "[email protected]" <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4a1d77bafcbe5fa4be87df459a88c9468673a5b4 Author: Kim Phillips <[email protected]> Date: Mon Aug 8 09:32:33 2022 -0500 x86/bugs: Enable STIBP for IBPB mitigated RETBleed commit e6cfcdda8cbe81eaf821c897369a65fec987b404 upstream. AMD's "Technical Guidance for Mitigating Branch Type Confusion, Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On Privileged Mode Entry / SMT Safety" says: Similar to the Jmp2Ret mitigation, if the code on the sibling thread cannot be trusted, software should set STIBP to 1 or disable SMT to ensure SMT safety when using this mitigation. So, like already being done for retbleed=unret, and now also for retbleed=ibpb, force STIBP on machines that have it, and report its SMT vulnerability status accordingly. [ bp: Remove the "we" and remove "[AMD]" applicability parameter which doesn't work here. ] Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb") Signed-off-by: Kim Phillips <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] # 5.10, 5.15, 5.19 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b662279708751baea3f55c5c158614c3f5dee2ee Author: Paulo Alcantara <[email protected]> Date: Mon Aug 8 13:41:18 2022 -0300 cifs: fix lock length calculation commit 773891ffd4d628d05c4e22f34541e4779ee7a076 upstream. The lock length was wrongly set to 0 when fl_end == OFFSET_MAX, thus failing to lock the whole file when l_start=0 and l_len=0. This fixes test 2 from cthon04. Before patch: $ ./cthon04/lock/tlocklfs -t 2 /mnt Creating parent/child synchronization pipes. Test #1 - Test regions of an unlocked file. Parent: 1.1 - F_TEST [ 0, 1] PASSED. Parent: 1.2 - F_TEST [ 0, ENDING] PASSED. Parent: 1.3 - F_TEST [ 0,7fffffffffffffff] PASSED. Parent: 1.4 - F_TEST [ 1, 1] PASSED. Parent: 1.5 - F_TEST [ 1, ENDING] PASSED. Parent: 1.6 - F_TEST [ 1,7fffffffffffffff] PASSED. Parent: 1.7 - F_TEST [7fffffffffffffff, 1] PASSED. Parent: 1.8 - F_TEST [7fffffffffffffff, ENDING] PASSED. Parent: 1.9 - F_TEST [7fffffffffffffff,7fffffffffffffff] PASSED. Test #2 - Try to lock the whole file. Parent: 2.0 - F_TLOCK [ 0, ENDING] PASSED. Child: 2.1 - F_TEST [ 0, 1] FAILED! Child: **** Expected EACCES, returned success... Child: **** Probably implementation error. ** CHILD pass 1 results: 0/0 pass, 0/0 warn, 1/1 fail (pass/total). Parent: Child died ** PARENT pass 1 results: 10/10 pass, 0/0 warn, 0/0 fail (pass/total). After patch: $ ./cthon04/lock/tlocklfs -t 2 /mnt Creating parent/child synchronization pipes. Test #2 - Try to lock the whole file. Parent: 2.0 - F_TLOCK [ 0, ENDING] PASSED. Child: 2.1 - F_TEST [ 0, 1] PASSED. Child: 2.2 - F_TEST [ 0, ENDING] PASSED. Child: 2.3 - F_TEST [ 0,7fffffffffffffff] PASSED. Child: 2.4 - F_TEST [ 1, 1] PASSED. Child: 2.5 - F_TEST [ 1, ENDING] PASSED. Child: 2.6 - F_TEST [ 1,7fffffffffffffff] PASSED. Child: 2.7 - F_TEST [7fffffffffffffff, 1] PASSED. Child: 2.8 - F_TEST [7fffffffffffffff, ENDING] PASSED. Child: 2.9 - F_TEST [7fffffffffffffff,7fffffffffffffff] PASSED. Parent: 2.10 - F_ULOCK [ 0, ENDING] PASSED. ** PARENT pass 1 results: 2/2 pass, 0/0 warn, 0/0 fail (pass/total). ** CHILD pass 1 results: 9/9 pass, 0/0 warn, 0/0 fail (pass/total). Fixes: d80c69846ddf ("cifs: fix signed integer overflow when fl_end is OFFSET_MAX") Reported-by: Xiaoli Feng <[email protected]> Cc: <[email protected]> Signed-off-by: Paulo Alcantara (SUSE) <[email protected]> Reviewed-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b76d3c729ce07a14822fbe6c64081d10b78e7bf2 Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:03 2022 -0700 scsi: qla2xxx: Fix losing FCP-2 targets during port perturbation tests commit 58d1c124cd79ea686b512043c5bd515590b2ed95 upstream. When a mix of FCP-2 (tape) and non-FCP-2 targets are present, FCP-2 target state was incorrectly transitioned when both of the targets were gone. Fix this by ignoring state transition for FCP-2 targets. Link: https://lore.kernel.org/r/[email protected] Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 326777057854f7e09a7ec191dc8fafc11e10d240 Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:04 2022 -0700 scsi: qla2xxx: Fix losing target when it reappears during delete commit 118b0c863c8f5629cc5271fc24d72d926e0715d9 upstream. FC target disappeared during port perturbation tests due to a race that tramples target state. Fix the issue by adding state checks before proceeding. Link: https://lore.kernel.org/r/[email protected] Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 11e9db717bf1c84f8a16095d43c3c38c3901be17 Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:06 2022 -0700 scsi: qla2xxx: Fix losing FCP-2 targets on long port disable with I/Os commit 2416ccd3815ba1613e10a6da0a24ef21acfe5633 upstream. FCP-2 devices were not coming back online once they were lost, login retries exhausted, and then came back up. Fix this by accepting RSCN when the device is not online. Link: https://lore.kernel.org/r/[email protected] Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit dc07af0e7c65654de12ce4881e508873a95c5c5b Author: Quinn Tran <[email protected]> Date: Wed Jun 15 22:35:00 2022 -0700 scsi: qla2xxx: Wind down adapter after PCIe error commit d3117c83ba316b3200d9f2fe900f2b9a5525a25c upstream. Put adapter into a wind down state if OS does not make any attempt to recover the adapter after PCIe error. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit c3a824d061aa45872260f4f88f64448e24cfee6c Author: Quinn Tran <[email protected]> Date: Wed Jun 15 22:35:07 2022 -0700 scsi: qla2xxx: Fix erroneous mailbox timeout after PCI error injection commit f260694e6463b63ae550aad25ddefe94cb1904da upstream. Clear wait for mailbox interrupt flag to prevent stale mailbox: Feb 22 05:22:56 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-500a:4: LOOP UP detected (16 Gbps). Feb 22 05:22:59 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-d04c:4: MBX Command timeout for cmd 69, ... To fix the issue, driver needs to clear the MBX_INTR_WAIT flag on purging the mailbox. When the stale mailbox completion does arrive, it will be dropped. Link: https://lore.kernel.org/r/[email protected] Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request") Cc: Naresh Bannoth <[email protected]> Cc: Kyle Mahlkuch <[email protected]> Cc: [email protected] Reported-by: Naresh Bannoth <[email protected]> Tested-by: Naresh Bannoth <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 79b2ac420c3a551d04ffda51a4222dca800bd0d9 Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:34:58 2022 -0700 scsi: qla2xxx: Fix excessive I/O error messages by default commit bff4873c709085e09d0ffae0c25b8e65256e3205 upstream. Disable printing I/O error messages by default. The messages will be printed only when logging was enabled. Link: https://lore.kernel.org/r/[email protected] Fixes: 8e2d81c6b5be ("scsi: qla2xxx: Fix excessive messages during device logout") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7dcd49c42b14717dd668fd73b503d241fdf82439 Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:02 2022 -0700 scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts commit c39587bc0abaf16593f7abcdf8aeec3c038c7d52 upstream. Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path. Following crash stack was seen: BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390 Link: https://lore.kernel.org/r/[email protected] Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit b16f0327fff2b76e49218665abf9b02983fbc7fa Author: Quinn Tran <[email protected]> Date: Wed Jun 15 22:35:01 2022 -0700 scsi: qla2xxx: Turn off multi-queue for 8G adapters commit 5304673bdb1635e27555bd636fd5d6956f1cd552 upstream. For 8G adapters, multi-queue was enabled accidentally. Make sure multi-queue is not enabled. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 182726ce801f498dc638134a24f5f3074016396c Author: Arun Easi <[email protected]> Date: Tue Jul 12 22:20:42 2022 -0700 scsi: qla2xxx: Fix discovery issues in FC-AL topology commit 47ccb113cead905bdc236571bf8ac6fed90321b3 upstream. A direct attach tape device, when gets swapped with another, was not discovered. Fix this by looking at loop map and reinitialize link if there are devices present. Link: https://lore.kernel.org/linux-scsi/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Reported-by: Tony Battersby <[email protected]> Tested-by: Tony Battersby <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit bff616494e42a73ecfaf2a86b3ad51f1ea06aaea Author: Quinn Tran <[email protected]> Date: Tue Jul 12 22:20:41 2022 -0700 scsi: qla2xxx: Fix imbalance vha->vref_count commit 63fa7f2644b4b48e1913af33092c044bf48e9321 upstream. vref_count took an extra decrement in the task management path. Add an extra ref count to compensate the imbalance. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 484ca52c1ca249493899c77fac4eb2552b20bc6e Author: Steffen Maier <[email protected]> Date: Fri Jul 29 18:25:29 2022 +0200 scsi: zfcp: Fix missing auto port scan and thus missing target ports commit 4da8c5f76825269f28d6a89fa752934a4bcb6dfa upstream. Case (1): The only waiter on wka_port->completion_wq is zfcp_fc_wka_port_get() trying to open a WKA port. As such it should only be woken up by WKA port *open* responses, not by WKA port close responses. Case (2): A close WKA port response coming in just after having sent a new open WKA port request and before blocking for the open response with wait_event() in zfcp_fc_wka_port_get() erroneously renders the wait_event a NOP because the close handler overwrites wka_port->status. Hence the wait_event condition is erroneously true and it does not enter blocking state. With non-negligible probability, the following time space sequence happens depending on timing without this fix: user process ERP thread zfcp work queue tasklet system work queue ============ ========== =============== ======= ================= $ echo 1 > online zfcp_ccw_set_online zfcp_ccw_activate zfcp_erp_adapter_reopen msleep scan backoff zfcp_erp_strategy | ... | zfcp_erp_action_cleanup | ... | queue delayed scan_work | queue ns_up_work | ns_up_work: | zfcp_fc_wka_port_get | open wka request | open response | GSPN FC-GS | RSPN FC-GS [NPIV-only] | zfcp_fc_wka_port_put | (--wka->refcount==0) | sched delayed wka->work | ~~~Case (1)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ zfcp_erp_wait flush scan_work | wka->work: | wka->status=CLOSING | close wka request | scan_work: | zfcp_fc_wka_port_get | (wka->status==CLOSING) | wka->status=OPENING | open wka request | wait_event | | close response | | wka->status=OFFLINE | | wake_up /*WRONG*/ ~~~Case (2)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | wka->work: | wka->status=CLOSING | close wka request zfcp_erp_wait flush scan_work | scan_work: | zfcp_fc_wka_port_get | (wka->status==CLOSING) | wka->status=OPENING | open wka request | close response | wka->status=OFFLINE | wake_up /*WRONG&NOP*/ | wait_event /*NOP*/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | (wka->status!=ONLINE) | return -EIO | return early open response wka->status=ONLINE wake_up /*NOP*/ So we erroneously end up with no automatic port scan. This is a big problem when it happens during boot. The timing is influenced by v3.19 commit 18f87a67e6d6 ("zfcp: auto port scan resiliency"). Fix it by fully mutually excluding zfcp_fc_wka_port_get() and zfcp_fc_wka_port_offline(). For that to work, we make the latter block until we got the response for a close WKA port. In order not to penalize the system workqueue, we move wka_port->work to our own adapter workqueue. Note that before v2.6.30 commit 828bc1212a68 ("[SCSI] zfcp: Set WKA-port to offline on adapter deactivation"), zfcp did block in zfcp_fc_wka_port_offline() as well, but with a different condition. While at it, make non-functional cleanups to improve code reading in zfcp_fc_wka_port_get(). If we cannot send the WKA port open request, don't rely on the subsequent wait_event condition to immediately let this case pass without blocking. Also don't want to rely on the additional condition handling the refcount to be skipped just to finally return with -EIO. Link: https://lore.kernel.org/r/[email protected] Fixes: 5ab944f97e09 ("[SCSI] zfcp: attach and release SAN nameserver port on demand") Cc: <[email protected]> #v2.6.28+ Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 9e786e19303d3f2f1440d117c8649c38e6253b29 Author: Peter Wang <[email protected]> Date: Wed Jul 27 11:05:26 2022 +0800 scsi: ufs: core: Correct ufshcd_shutdown() flow commit 00511d2abf5708ad05dd5d1c36adb2468d274698 upstream. After ufshcd_wl_shutdown() set device power off and link off, ufshcd_shutdown() could turn off clock/power. Also remove pm_runtime_get_sync. The reason why it is safe to remove pm_runtime_get_sync() is because: - ufshcd_wl_shutdown() -> pm_runtime_get_sync() will resume hba->dev too. - device resume(turn on clk/power) is not required, even if device is in RPM_SUSPENDED. Link: https://lore.kernel.org/r/[email protected] Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun") Cc: <[email protected]> # 5.15.x Reviewed-by: Stanley Chu <[email protected]> Signed-off-by: Peter Wang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit e2d7cacc6a2a1d77e7e20a492daf458a12cf19e0 Author: Zheyu Ma <[email protected]> Date: Thu Aug 4 20:41:25 2022 +0800 video: fbdev: s3fb: Check the size of screen before memset_io() [ Upstream commit 6ba592fa014f21f35a8ee8da4ca7b95a018f13e8 ] In the function s3fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000 [ 54.083742] #PF: supervisor write access in kernel mode [ 54.083744] #PF: error_code(0x0002) - not-present page [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Call Trace: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Fix the this by checking the value of 'screen_size' before memset_io(). Fixes: a268422de8bf ("fbdev driver for S3 Trio/Virge") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2ce61c39c2a0b8ec82f48e0f7136f0dac105ae75 Author: Zheyu Ma <[email protected]> Date: Thu Aug 4 20:41:24 2022 +0800 video: fbdev: arkfb: Check the size of screen before memset_io() [ Upstream commit 96b550971c65d54d64728d8ba973487878a06454 ] In the function arkfb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000 [ 659.399077] #PF: supervisor write access in kernel mode [ 659.399079] #PF: error_code(0x0002) - not-present page [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Call Trace: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io(). Fixes: 681e14730c73 ("arkfb: new framebuffer driver for ARK Logic cards") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c7a3f41e4b133d4dd25bc996b69039b19a34d69d Author: Zheyu Ma <[email protected]> Date: Thu Aug 4 20:41:23 2022 +0800 video: fbdev: vt8623fb: Check the size of screen before memset_io() [ Upstream commit ec0754c60217248fa77cc9005d66b2b55200ac06 ] In the function vt8623fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000 [ 583.339049] #PF: supervisor write access in kernel mode [ 583.339052] #PF: error_code(0x0002) - not-present page [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Call Trace: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io(). Fixes: 558b7bd86c32 ("vt8623fb: new framebuffer driver for VIA VT8623") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6dab0119adcc3beb833555a478e710fb6a709a85 Author: Jaewook Kim <[email protected]> Date: Wed Aug 3 17:53:58 2022 +0900 f2fs: do not allow to decompress files have FI_COMPRESS_RELEASED [ Upstream commit 90be48bd9d29ece3965e5e8b21499b6db166e57b ] If a file has FI_COMPRESS_RELEASED, all writes for it should not be allowed. However, as of now, in case of compress_mode=user, writes triggered by IOCTLs like F2FS_IOC_DE/COMPRESS_FILE are allowed unexpectly, which could crash that file. To fix it, let's do not allow F2FS_IOC_DE/COMPRESS_IOCTL if a file already has FI_COMPRESS_RELEASED flag. This is the reproduction process: 1. $ touch ./file 2. $ chattr +c ./file 3. $ dd if=/dev/random of=./file bs=4096 count=30 conv=notrunc 4. $ dd if=/dev/zero of=./file bs=4096 count=34 seek=30 conv=notrunc 5. $ sync 6. $ do_compress ./file ; call F2FS_IOC_COMPRESS_FILE 7. $ get_compr_blocks ./file ; call F2FS_IOC_GET_COMPRESS_BLOCKS 8. $ release ./file ; call F2FS_IOC_RELEASE_COMPRESS_BLOCKS 9. $ do_compress ./file ; call F2FS_IOC_COMPRESS_FILE again 10. $ get_compr_blocks ./file ; call F2FS_IOC_GET_COMPRESS_BLOCKS again This reproduction process is tested in 128kb cluster size. You can find compr_blocks has a negative value. Fixes: 5fdb322ff2c2b ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE") Signed-off-by: Junbeom Yeom <[email protected]> Signed-off-by: Sungjong Seo <[email protected]> Signed-off-by: Youngjin Gil <[email protected]> Signed-off-by: Jaewook Kim <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 68d27da7659d432142d9d82ab166d868717b8a2c Author: Andrea Righi <[email protected]> Date: Thu Jul 14 09:49:15 2022 +0200 x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y [ Upstream commit de979c83574abf6e78f3fa65b716515c91b2613d ] With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_$(BITS).o becomes an empty object file. With some old versions of binutils (i.e., 2.35.90.20210113-1ubuntu1) the GNU assembler doesn't generate a symbol table for empty object files and objtool fails with the following error when a valid symbol table cannot be found: arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table To prevent this from happening, build thunk_$(BITS).o only if CONFIG_PREEMPTION is enabled. BugLink: https://bugs.launchpad.net/bugs/1911359 Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft") Signed-off-by: Andrea Righi <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/Ys/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 302f7b0fc337746f41c69eb08522907f6a90c643 Author: Mel Gorman <[email protected]> Date: Thu Aug 4 10:21:19 2022 +0100 sched/core: Do not requeue task on CPU excluded from cpus_mask [ Upstream commit 751d4cbc43879229dbc124afefe240b70fd29a85 ] The following warning was triggered on a large machine early in boot on a distribution kernel but the same problem should also affect mainline. WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440 Call Trace: <TASK> rescuer_thread+0x1f6/0x360 kthread+0x156/0x180 ret_from_fork+0x22/0x30 </TASK> Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") optimises ttwu by queueing a task that is descheduling on the wakelist, but does not check if the task descheduling is still allowed to run on that CPU. In this warning, the problematic task is a workqueue rescue thread which checks if the rescue is for a per-cpu workqueue and running on the wrong CPU. While this is early in boot and it should be possible to create workers, the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue thread is being used frequently. Tracing confirmed that the task should have migrated properly using the stopper thread to handle the migration. However, a parallel wakeup from udev running on another CPU that does not share CPU cache observes p->on_cpu and uses task_cpu(p), queues the task on the old CPU and triggers the warning. Check that the wakee task that is descheduling is still allowed to run on its current CPU and if not, wait for the descheduling to complete and select an allowed CPU. Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Signed-off-by: Mel Gorman <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 72f5b286d2b756a7e86212ad572a922568a4d62c Author: Tianchen Ding <[email protected]> Date: Thu Jun 9 07:34:12 2022 +0800 sched: Remove the limitation of WF_ON_CPU on wakelist if wakee cpu is idle [ Upstream commit f3dd3f674555bd9455c5ae7fafce0696bd9931b3 ] Wakelist can help avoid cache bouncing and offload the overhead of waker cpu. So far, using wakelist within the same llc only happens on WF_ON_CPU, and this limitation could be removed to further improve wakeup performance. The commit 518cd6234178 ("sched: Only queue remote wakeups when crossing cache boundaries") disabled queuing tasks on wakelist when the cpus share llc. This is because, at that time, the scheduler must send IPIs to do ttwu_queue_wakelist. Nowadays, ttwu_queue_wakelist also supports TIF_POLLING, so this is not a problem now when the wakee cpu is in idle polling. Benefits: Queuing the task on idle cpu can help improving performance on waker cpu and utilization on wakee cpu, and further improve locality because the wakee cpu can handle its own rq. This patch helps improving rt on our real java workloads where wakeup happens frequently. Consider the normal condition (CPU0 and CPU1 share same llc) Before this patch: CPU0 CPU1 select_task_rq() idle rq_lock(CPU1->rq) enqueue_task(CPU1->rq) notify CPU1 (by sending IPI or CPU1 polling) resched() After this patch: CPU0 CPU1 select_task_rq() idle add to wakelist of CPU1 notify CPU1 (by sending IPI or CPU1 polling) rq_lock(CPU1->rq) enqueue_task(CPU1->rq) resched() We see CPU0 can finish its work earlier. It only needs to put task to wakelist and return. While CPU1 is idle, so let itself handle its own runqueue data. This patch brings no difference about IPI. This patch only takes effect when the wakee cpu is: 1) idle polling 2) idle not polling For 1), there will be no IPI with or without this patch. For 2), there will always be an IPI before or after this patch. Before this patch: waker cpu will enqueue task and check preempt. Since "idle" will be sure to be preempted, waker cpu must send a resched IPI. After this patch: waker cpu will put the task to the wakelist of wakee cpu, and send an IPI. Benchmark: We've tested schbench, unixbench, and hachbench on both x86 and arm64. On x86 (Intel Xeon Platinum 8269CY): schbench -m 2 -t 8 Latency percentiles (usec) before after 50.0000th: 8 6 75.0000th: 10 7 90.0000th: 11 8 95.0000th: 12 8 *99.0000th: 13 10 99.5000th: 15 11 99.9000th: 18 14 Unixbench with full threads (104) before after Dhrystone 2 using register variables 3011862938 3009935994 -0.06% Double-Precision Whetstone 617119.3 617298.5 0.03% Execl Throughput 27667.3 27627.3 -0.14% File Copy 1024 bufsize 2000 maxblocks 785871.4 784906.2 -0.12% File Copy 256 bufsize 500 maxblocks 210113.6 212635.4 1.20% File Copy 4096 bufsize 8000 maxblocks 2328862.2 2320529.1 -0.36% Pipe Throughput 145535622.8 145323033.2 -0.15% Pipe-based Context Switching 3221686.4 3583975.4 11.25% Process Creation 101347.1 103345.4 1.97% Shell Scripts (1 concurrent) 120193.5 123977.8 3.15% Shell Scripts (8 concurrent) 17233.4 17138.4 -0.55% System Call Overhead 5300604.8 5312213.6 0.22% hackbench -g 1 -l 100000 before after Time 3.246 2.251 On arm64 (Ampere Altra): schbench -m 2 -t 8 Latency percentiles (usec) before after 50.0000th: 14 10 75.0000th: 19 14 90.0000th: 22 16 95.0000th: 23 16 *99.0000th: 24 17 99.5000th: 24 17 99.9000th: 28 25 Unixbench with full threads (80) before after Dhrystone 2 using register variables 3536194249 3537019613 0.02% Double-Precision Whetstone 629383.6 629431.6 0.01% Execl Throughput 65920.5 65846.2 -0.11% File Copy 1024 bufsize 2000 maxblocks 1063722.8 1064026.8 0.03% File Copy 256 bufsize 500 maxblocks 322684.5 318724.5 -1.23% File Copy 4096 bufsize 8000 maxblocks 2348285.3 2328804.8 -0.83% Pipe Throughput 133542875.3 131619389.8 -1.44% Pipe-based Context Switching 3215356.1 3576945.1 11.25% Process Creation 108520.5 120184.6 10.75% Shell Scripts (1 concurrent) 122636.3 121888 -0.61% Shell Scripts (8 concurrent) 17462.1 17381.4 -0.46% System Call Overhead 4429998.9 4435006.7 0.11% hackbench -g 1 -l 100000 before after Time 4.217 2.916 Our patch has improvement on schbench, hackbench and Pipe-based Context Switching of unixbench when there exists idle cpus, and no obvious regression on other tests of unixbench. This can help improve rt in scenes where wakeup happens frequently. Signed-off-by: Tianchen Ding <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 31ef9288a5938ebbf577b10b40087d5745be544f Author: Tianchen Ding <[email protected]> Date: Thu Jun 9 07:34:11 2022 +0800 sched: Fix the check of nr_running at queue wakelist [ Upstream commit 28156108fecb1f808b21d216e8ea8f0d205a530c ] The commit 2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling") checked rq->nr_running <= 1 to avoid task stacking when WF_ON_CPU. Per the ordering of writes to p->on_rq and p->on_cpu, observing p->on_cpu (WF_ON_CPU) in ttwu_queue_cond() implies !p->on_rq, IOW p has gone through the deactivate_task() in __schedule(), thus p has been accounted out of rq->nr_running. As such, the task being the only runnable task on the rq implies reading rq->nr_running == 0 at that point. The benchmark result is in [1]. [1] https://lore.kernel.org/all/[email protected]/ Suggested-by: Valentin Schneider <[email protected]> Signed-off-by: Tianchen Ding <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 035f2184fed3cc825d8083a5e62d45a5e99b21d0 Author: Florian Fainelli <[email protected]> Date: Mon Jul 25 10:37:54 2022 -0700 tools/thermal: Fix possible path truncations [ Upstream commit 6c58cf40e3a1d2f47c09d3489857e9476316788a ] A build with -D_FORTIFY_SOURCE=2 enabled will produce the following warnings: sysfs.c:63:30: warning: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 255 [-Wformat-truncation=] snprintf(filepath, 256, "%s/%s", path, filename); ^~ Bump up the buffer to PATH_MAX which is the limit and account for all of the possible NUL and separators that could lead to exceeding the allocated buffer sizes. Fixes: 94f69966faf8 ("tools/thermal: Introduce tmon, a tool for thermal subsystem") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 15661642511b2b192077684a89f42a8d95d54286 Author: Zheyu Ma <[email protected]> Date: Wed Aug 3 17:23:12 2022 +0800 video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock() [ Upstream commit 2f1c4523f7a3aaabe7e53d3ebd378292947e95c8 ] Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug in: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0. and then in: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); we'll get a division-by-zero. The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of ark_set_pixclock() first. Fixes: 681e14730c73 ("arkfb: new framebuffer driver for ARK Logic cards") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ee9463233a366725878d8c333519fd6cd2a8a65e Author: Siddh Raman Pant <[email protected]> Date: Sun Jul 31 21:39:13 2022 +0530 x86/numa: Use cpumask_available instead of hardcoded NULL check [ Upstream commit 625395c4a0f4775e0fe00f616888d2e6c1ba49db ] GCC-12 started triggering a new warning: arch/x86/mm/numa.c: In function ‘cpumask_of_node’: arch/x86/mm/numa.c:916:39: warning: the comparison will always evaluate as ‘false’ for the address of ‘node_to_cpumask_map’ will never be NULL [-Waddress] 916 | if (node_to_cpumask_map[node] == NULL) { | ^~ node_to_cpumask_map is of type cpumask_var_t[]. When CONFIG_CPUMASK_OFFSTACK is set, cpumask_var_t is typedef'd to a pointer for dynamic allocation, else to an array of one element. The "wicked game" can be checked on line 700 of include/linux/cpumask.h. The original code in debug_cpumask_set_cpu() and cpumask_of_node() were probably written by the original authors with CONFIG_CPUMASK_OFFSTACK=y (i.e. dynamic allocation) in mind, checking if the cpumask was available via a direct NULL check. When CONFIG_CPUMASK_OFFSTACK is not set, GCC gives the above warning while compiling the kernel. Fix that by using cpumask_available(), which does the NULL check when CONFIG_CPUMASK_OFFSTACK is set, otherwise returns true. Use it wherever such checks are made. Conditional definitions of cpumask_available() can be found along with the definition of cpumask_var_t. Check the cpumask.h reference mentioned above. Fixes: c032ef60d1aa ("cpumask: convert node_to_cpumask_map[] to cpumask_var_t") Fixes: de2d9445f162 ("x86: Unify node_to_cpumask_map handling between 32 and 64bit") Signed-off-by: Siddh Raman Pant <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f56607b44c9896e51678a7e8cdd3a5479f4b4548 Author: Waiman Long <[email protected]> Date: Tue Aug 2 21:54:51 2022 -0400 sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed [ Upstream commit b6e8d40d43ae4dec00c8fea2593eeea3114b8f44 ] With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpuset_can_attach() can call task_can_attach() with an empty mask. This can lead to cpumask_any_and() returns nr_cpu_ids causing the call to dl_bw_of() to crash due to percpu value access of an out of bound CPU value. For example: [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] cgroup_subtree_control_write+0x322/0x400 [80468.212854] kernfs_fop_write_iter+0x11c/0x1b0 [80468.213777] new_sync_write+0x11f/0x1b0 [80468.214689] vfs_write+0x1eb/0x280 [80468.215592] ksys_write+0x5f/0xe0 [80468.216463] do_syscall_64+0x5c/0x80 [80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix that by using effective_cpus instead. For cgroup v1, effective_cpus is the same as cpus_allowed. For v2, effective_cpus is the real cpumask to be used by tasks within the cpuset anyway. Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to reflect the change. In addition, a check is added to task_can_attach() to guard against the possibility that cpumask_any_and() may return a value >= nr_cpu_ids. Fixes: 7f51412a415d ("sched/deadline: Fix bandwidth check/update when migrating tasks between exclusive cpusets") Signed-off-by: Waiman Long <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Juri Lelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 32d8d832e31bf9312f7e91811d42eed6a2e1bcb9 Author: Michael Ellerman <[email protected]> Date: Wed Aug 3 16:29:41 2022 +1000 powerpc/64e: Fix kexec build error [ Upstream commit 4cfa6ff24a9744ba484521c38bea613134fbfcb3 ] When building ppc64_book3e_allmodconfig the build fails with: arch/powerpc/kexec/file_load_64.c:1063:14: error: implicit declaration of function ‘firmware_has_feature’ 1063 | if (!firmware_has_feature(FW_FEATURE_LPAR)) | ^~~~~~~~~~~~~~~~~~~~ Add a direct include of asm/firmware.h to fix the error. Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window") Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4971147c532464896e02631cc29082725499cfe0 Author: Douglas Anderson <[email protected]> Date: Tue Aug 2 13:23:09 2022 -0700 tty: serial: qcom-geni-serial: Fix %lu -> %u in print statements [ Upstream commit 0fec518018cc5ceffa706370b6e3acbbb1e3c798 ] When we multiply an unsigned int by a u32 we still end up with an unsigned int. That means we should specify "%u" not "%lu" in the format code. NOTE: this fix was chosen instead of somehow promoting the value to "unsigned long" since the max baud rate from the earlier call to uart_get_baud_rate() is 4000000 and the max sampling rate is 32. 4000000 * 32 = 0x07a12000, not even close to overflowing 32-bits. Fixes: c474c775716e ("tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate.") Reported-by: Mark Brown <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected]eid Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 33d3905b22dee22983ca3751ae2effe1d47e7d7e Author: Josh Poimboeuf <[email protected]> Date: Thu Jul 21 11:01:23 2022 -0700 scripts/faddr2line: Fix vmlinux detection on arm64 [ Upstream commit b6a5068854cfe372da7dee3224dcf023ed5b00cb ] Since commit dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel"), faddr2line is completely broken on arm64. For some reason, on arm64, the vmlinux ELF object file type is ET_DYN rather than ET_EXEC. Check for both when determining whether the object is vmlinux. Modules and vmlinux.o have type ET_REL on all arches. Fixes: dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel") Reported-by: John Garry <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/d[email protected]kernel.org Signed-off-by: Sasha Levin <[email protected]> commit cca32a4d21ee6340df258780690d1975cb01f614 Author: Arnaldo Carvalho de Melo <[email protected]> Date: Tue Aug 2 15:13:22 2022 -0300 genelf: Use HAVE_LIBCRYPTO_SUPPORT, not the never defined HAVE_LIBCRYPTO [ Upstream commit 91cea6be90e436c55cde8770a15e4dac9d3032d0 ] When genelf was introduced it tested for HAVE_LIBCRYPTO not HAVE_LIBCRYPTO_SUPPORT, which is the define the feature test for openssl defines, fix it. This also adds disables the deprecation warning, someone has to fix this to build with openssl 3.0 before the warning becomes a hard error. Fixes: 9b07e27f88b9cd78 ("perf inject: Add jitdump mmap injection support") Reported-by: 谭梓煊 <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Fastabend <[email protected]> Cc: KP Singh <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: Nick Terrell <[email protected]> Cc: Song Liu <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3d7b948081a9603670b1389f6a51a2180e366d11 Author: Michael Ellerman <[email protected]> Date: Tue Aug 2 20:38:32 2022 +1000 powerpc/pci: Fix PHB numbering when using opal-phbid [ Upstream commit f4b39e88b42d13366b831270306326b5c20971ca ] The recent change to the PHB numbering logic has a logic error in the handling of "ibm,opal-phbid". When an "ibm,opal-phbid" property is present, &prop is written to and ret is set to zero. The following call to of_alias_get_id() is skipped because ret == 0. But then the if (ret >= 0) is true, and the body of that if statement sets prop = ret which throws away the value that was just read from "ibm,opal-phbid". Fix the logic by only doing the ret >= 0 check in the of_alias_get_id() case. Fixes: 0fe1e96fef0a ("powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias") Reviewed-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 866a978c75350f24b2d1df80d953f1e050a9dec0 Author: Chenyi Qiang <[email protected]> Date: Tue Aug 2 11:32:06 2022 +0800 x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero [ Upstream commit ffa6482e461ff550325356ae705b79e256702ea9 ] It's possible that this kernel has been kexec'd from a kernel that enabled bus lock detection, or (hypothetically) BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT. Disable bus lock detection explicitly if not wanted. Fixes: ebb1064e7c2e ("x86/traps: Handle #DB for bus lock") Signed-off-by: Chenyi Qiang <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 16a544f1e013ba0660612f3fe35393b143b19a84 Author: Chen Zhongjin <[email protected]> Date: Mon Aug 1 11:37:19 2022 +0800 kprobes: Forbid probing on trampoline and BPF code areas [ Upstream commit 28f6c37a2910f565b4f5960df52b2eccae28c891 ] kernel_text_address() treats ftrace_trampoline, kprobe_insn_slot and bpf_text_address as valid kprobe addresses - which is not ideal. These text areas are removable and changeable without any notification to kprobes, and probing on them can trigger unexpected behavior: https://lkml.org/lkml/2022/7/26/1148 Considering that jump_label and static_call text are already forbiden to probe, kernel_text_address() should be replaced with core_kernel_text() and is_module_text_address() to check other text areas which are unsafe to kprobe. [ mingo: Rewrote the changelog. ] Fixes: 5b485629ba0d ("kprobes, extable: Identify kprobes trampolines as kernel text area") Fixes: 74451e66d516 ("bpf: make jited programs visible in traces") Signed-off-by: Chen Zhongjin <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 32adf0c85fa9d8a0f85dde5a614c372c49e97e84 Author: Ian Rogers <[email protected]> Date: Sun Jul 31 09:49:23 2022 -0700 perf symbol: Fail to read phdr workaround [ Upstream commit 6d518ac7be6223811ab947897273b1bbef846180 ] The perf jvmti agent doesn't create program headers, in this case fallback on section headers as happened previously. Committer notes: To test this, from a public post by Ian: 1) download a Java workload dacapo-9.12-MR1-bach.jar from https://sourceforge.net/projects/dacapobench/ 2) build perf such as "make -C tools/perf O=/tmp/perf NO_LIBBFD=1" it should detect Java and create /tmp/perf/libperf-jvmti.so 3) run perf with the jvmti agent: perf record -k 1 java -agentpath:/tmp/perf/libperf-jvmti.so -jar dacapo-9.12-MR1-bach.jar -n 10 fop 4) run perf inject: perf inject -i perf.data -o perf-injected.data -j 5) run perf report perf report -i perf-injected.data | grep org.apache.fop With this patch reverted I see lots of symbols like: 0.00% java jitted-388040-4656.so [.] org.apache.fop.fo.FObj.bind(org.apache.fop.fo.PropertyList) With the patch (2d86612aacb7805f ("perf symbol: Correct address for bss symbols")) I see lots of: dso__load_sym_internal: failed to find program header for symbol: Lorg/apache/fop/fo/FObj;bind(Lorg/apache/fop/fo/PropertyList;)V st_value: 0x40 Fixes: 2d86612aacb7805f ("perf symbol: Correct address for bss symbols") Reviewed-by: Leo Yan <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Tested-by: Leo Yan <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Leo Yan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit af41cff4ada533b1cf40de6c468ba164fd32c22d Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 10:51:29 2022 +0400 powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address [ Upstream commit df5d4b616ee76abc97e5bd348e22659c2b095b1c ] of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() in the error path to avoid refcount leak. Fixes: ce21b3c9648a ("[CELL] add support for MSI on Axon-based Cell systems") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 79b8eae24b7ee157bda07695d802be8576983fa8 Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 09:32:23 2022 +0400 powerpc/xive: Fix refcount leak in xive_get_max_prio [ Upstream commit 255b650cbec6849443ce2e0cdd187fd5e61c218c ] of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4288eb035ba4ddb53245e9365c919bb51ac00c2c Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 16:15:42 2022 +0400 powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader [ Upstream commit 6ac059dacffa8ab2f7798f20e4bd3333890c541c ] of_find_node_by_path() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 0afacde3df4c ("[POWERPC] spufs: allow isolated mode apps by starting the SPE loader") Signed-off-by: Miaoqian Lin <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit ae497726cd090673a4d20ac725ccc2de8067a7a5 Author: Matthew Wilcox (Oracle) <[email protected]> Date: Mon Jul 18 20:06:24 2022 +0100 cifs: Fix memory leak when using fscache [ Upstream commit c6f62f81b488d00afaa86bae26c6ce9ab12c709e ] If we hit the 'index == next_cached' case, we leak a refcount on the struct page. Fix this by using readahead_folio() which takes care of the refcount for you. Fixes: 0174ee9947bd ("cifs: Implement cache I/O by accessing the cache directly") Cc: David Howells <[email protected]> Cc: Jeff Layton <[email protected]> Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e0a6bb00d11088f4ce5cc374d57042cee538a91d Author: Chao Liu <[email protected]> Date: Mon Jul 25 18:16:33 2022 +0800 f2fs: fix to remove F2FS_COMPR_FL and tag F2FS_NOCOMP_FL at the same time [ Upstream commit 8ee236dcaa690d09ca612622e8bc8d09c302021d ] If the inode has the compress flag, it will fail to use 'chattr -c +m' to remove its compress flag and tag no compress flag. However, the same command will be successful when executed again, as shown below: $ touch foo.txt $ chattr +c foo.txt $ chattr -c +m foo.txt chattr: Invalid argument while setting flags on foo.txt $ chattr -c +m foo.txt $ f2fs_io getflags foo.txt get a flag on foo.txt ret=0, flags=nocompression,inline_data Fix this by removing some checks in f2fs_setflags_common() that do not affect the original logic. I go through all the possible scenarios, and the results are as follows. Bold is the only thing that has changed. +---------------+-----------+-----------+----------+ | | file flags | + command +-----------+-----------+----------+ | | no flag | compr | nocompr | +---------------+-----------+-----------+----------+ | chattr +c | compr | compr | -EINVAL | | chattr -c | no flag | no flag | nocompr | | chattr +m | nocompr | -EINVAL | nocompr | | chattr -m | no flag | compr | no flag | | chattr +c +m | -EINVAL | -EINVAL | -EINVAL | | chattr +c -m | compr | compr | compr | | chattr -c +m | nocompr | *nocompr* | nocompr | | chattr -c -m | no flag | no flag | no flag | +---------------+-----------+-----------+----------+ Link: https://lore.kernel.org/linux-f2fs-devel/[email protected]/ Fixes: 4c8ff7095bef ("f2fs: support data compression") Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Chao Liu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fdafb1b1f1c1cdeec2e7b5733b439202363ada32 Author: Chao Yu <[email protected]> Date: Tue Jul 12 11:17:15 2022 +0800 f2fs: fix to check inline_data during compressed inode conversion [ Upstream commit 7165841d578e0592848e09dc9d131aa30be44e1b ] When converting inode to compressed one via ioctl, it needs to check inline_data, since inline_data flag and compressed flag are incompatible. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cf544749b65e5d358af4b148a6f4167daa9a12af Author: Chao Yu <[email protected]> Date: Wed Jul 6 14:30:15 2022 +0800 f2fs: fix to invalidate META_MAPPING before DIO write [ Upstream commit 67ca06872eb02944b4c6f92cffa9242e92c63109 ] Quoted from commit e3b49ea36802 ("f2fs: invalidate META_MAPPING before IPU/DIO write") " Encrypted pages during GC are read and cached in META_MAPPING. However, due to cached pages in META_MAPPING, there is an issue where newly written pages are lost by IPU or DIO writes. Thread A - f2fs_gc() Thread B /* phase 3 */ down_write(i_gc_rwsem) ra_data_block() ---- (a) up_write(i_gc_rwsem) f2fs_direct_IO() : - down_read(i_gc_rwsem) - __blockdev_direct_io() - get_data_block_dio_write() - f2fs_dio_submit_bio() ---- (b) - up_read(i_gc_rwsem) /* phase 4 */ down_write(i_gc_rwsem) move_data_block() ---- (c) up_write(i_gc_rwsem) (a) In phase 3 of f2fs_gc(), up-to-date page is read from storage and cached in META_MAPPING. (b) In thread B, writing new data by IPU or DIO write on same blkaddr as read in (a). cached page in META_MAPPING become out-dated. (c) In phase 4 of f2fs_gc(), out-dated page in META_MAPPING is copied to new blkaddr. In conclusion, the newly written data in (b) is lost. To address this issue, invalidating pages in META_MAPPING before IPU or DIO write. " In previous commit, we missed to cover extent cache hit case, and passed wrong value for parameter @end of invalidate_mapping_pages(), fix both issues. Fixes: 6aa58d8ad20a ("f2fs: readahead encrypted block during GC") Fixes: e3b49ea36802 ("f2fs: invalidate META_MAPPING before IPU/DIO write") Cc: Hyeong-Jun Kim <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e330968494736db78108da5e416851e7fee4ab73 Author: Kan Liang <[email protected]> Date: Thu Jul 21 14:57:02 2022 +0800 perf stat: Revert "perf stat: Add default hybrid events" [ Upstream commit ace3e31e653e79cae9b047e85f567e6b44c98532 ] This reverts commit Fixes: ac2dc29edd21f9ec ("perf stat: Add default hybrid events") Between this patch and the reverted patch, the commit 6c1912898ed21bef ("perf parse-events: Rename parse_events_error functions") and the commit 07eafd4e053a41d7 ("perf parse-event: Add init and exit to parse_event_error") clean up the parse_events_error_*() codes. The related change is also reverted. The reverted patch is hard to be extended to support new default events, e.g., Topdown events, and the existing "--detailed" option on a hybrid platform. A new solution will be proposed in the following patch to enable the perf stat default on a hybrid platform. Signed-off-by: Kan Liang <[email protected]> Acked-by: Ian Rogers <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xing Zhengjun <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2afd4b24668d75ccf12051cb47e563a90944e653 Author: Alexander Gordeev <[email protected]> Date: Wed Jul 20 07:24:03 2022 +0200 s390/smp: enforce lowcore protection on CPU restart [ Upstream commit 6f5c672d17f583b081e283927f5040f726c54598 ] As result of commit 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called") the low-address protection bit gets mistakenly unset in control register 0 save area of the absolute zero memory. That area is used when manual PSW restart happened to hit an offline CPU. In this case the low-address protection for that CPU will be dropped. Reviewed-by: Heiko Carstens <[email protected]> Fixes: 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called") Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7a7dc82fa4413bdf418f53bf46445c9608fd48f7 Author: Sherry Sun <[email protected]> Date: Mon Jul 25 13:01:15 2022 +0800 tty: serial: fsl_lpuart: correct the count of break characters [ Upstream commit 707f816f25590c20e056b3bd4a17ce69b03fe856 ] The LPUART can't distinguish between a break signal and a framing error, so need to count the break characters if there is a framing error and received data is zero instead of the parity error. Fixes: 5541a9bacfe5 ("serial: fsl_lpuart: handle break and make sysrq work") Reviewed-by: Michael Walle <[email protected]> Signed-off-by: Sherry Sun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b820594fba897f4d4ad424819b2c24cc6202454a Author: Vijaya Krishna Nivarthi <[email protected]> Date: Sat Jul 16 00:25:43 2022 +0530 tty: serial: qcom-geni-serial: Fix get_clk_div_rate() which otherwise could return a sub-optimal clock rate. [ Upstream commit c474c775716edd46a51bf8161142bbd1545f8733 ] In the logic around call to clk_round_rate(), for some corner conditions, get_clk_div_rate() could return an sub-optimal clock rate. Also, if an exact clock rate was not found lowest clock was being returned. Search for suitable clock rate in 2 steps a) exact match or within 2% tolerance b) within 5% tolerance This also takes care of corner conditions. Fixes: c2194bc999d4 ("tty: serial: qcom-geni-serial: Remove uart frequency table. Instead, find suitable frequency with call to clk_round_rate") Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Vijaya Krishna Nivarthi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b720d76cd36ea54f3ab216733884b8db50b20abf Author: Guo Mengqi <[email protected]> Date: Fri Jul 15 10:33:12 2022 +0800 serial: 8250_bcm2835aux: Add missing clk_disable_unprepare() [ Upstream commit b9f1736e475dba0d6da48fdcb831248ab1597886 ] The error path when get clock frequency fails in bcm2835aux_serial driver does not correctly disable the clock. This flaw was found using a static analysis tool "Hulk Robot", which reported the following warning when analyzing linux-next/master: drivers/tty/serial/8250/8250_bcm2835aux.c: warning: clk_disable_unprepare_missing.cocci The cocci script checks for the existence of clk_disable_unprepare() paired with clk_prepare_enable(). Add the missing clk_disable_unprepare() to the error path. Fixes: fcc446c8aa63 ("serial: 8250_bcm2835aux: Add ACPI support") Reported-by: Hulk Robot <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Guo Mengqi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b5de92e1bb7f303f9903d354659025e4d7e58ef8 Author: Rashmica Gupta <[email protected]> Date: Fri Jun 17 14:39:35 2022 +1000 selftests/powerpc: Fix matrix multiply assist test [ Upstream commit cd1e64935f79e31d666172c52c951ca97152b783 ] The ISA states: "when ACC[i] contains defined data, the contents of VSRs 4×i to 4×i+3 are undefined until either a VSX Move From ACC instruction is used to copy the contents of ACC[i] to VSRs 4×i to 4×i+3 or some other instruction directly writes to one of these VSRs." We aren't doing this. This test only works on Power10 because the hardware implementation happens to map ACC0 to VSRs 0-3, but will fail on any other implementation that doesn't do this. So add xxmfacc between writing to the accumulator and accessing the VSRs. Fixes: 3527e1ab9a79 ("selftests/powerpc: Add matrix multiply assist (MMA) test") Signed-off-by: Rashmica Gupta <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f35c7f506fb96a23a1961c7314c5931ec8bc473e Author: Pali Rohár <[email protected]> Date: Wed Jul 6 12:21:48 2022 +0200 powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias [ Upstream commit 0fe1e96fef0a5c53b4c0d1500d356f3906000f81 ] Other Linux architectures use DT property 'linux,pci-domain' for specifying fixed PCI domain of PCI controller specified in Device-Tree. And lot of Freescale powerpc boards have defined numbered pci alias in Device-Tree for every PCIe controller which number specify preferred PCI domain. So prefer usage of DT property 'linux,pci-domain' (via function of_get_pci_domain_nr()) and DT pci alias (via function of_alias_get_id()) on powerpc architecture for assigning PCI domain to PCI controller. Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 114ed51117be7d8029e38712dce6f6aef9aa3574 Author: Alexey Kardashevskiy <[email protected]> Date: Thu Jul 14 18:11:19 2022 +1000 powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case [ Upstream commit d80f6de9d601c30b53c17f00cb7cfe3169f2ddad ] The existing iommu_table_in_use() helper checks if the kernel is using any of TCEs. There are some reserved TCEs: 1) the very first one if DMA window starts from 0 to avoid having a zero but still valid DMA handle; 2) it_reserved_start..it_reserved_end to exclude MMIO32 window in case the default window spans across that - this is the default for the first DMA window on PowerNV. When 1) is the case and 2) is not the helper does not skip 1) and returns wrong status. This only seems occurring when passing through a PCI device to a nested guest (not something we support really well) so it has not been seen before. This fixes the bug by adding a special case for no MMIO32 reservation. Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 58942f672c6d04b6a3cd7866cb459671df881538 Author: Alexey Kardashevskiy <[email protected]> Date: Wed Jun 29 16:06:14 2022 +1000 pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window [ Upstream commit b1fc44eaa9ba31e28c4125d6b9205a3582b47b5d ] The pseries platform uses 32bit default DMA window (always 4K pages) and optional 64bit DMA window available via DDW ("Dynamic DMA Windows"), 64K or 2M pages. For ages the default one was not removed and a huge window was created in addition. Things changed with SRIOV-enabled PowerVM which creates a default-and-bigger DMA window in 64bit space (still using 4K pages) for IOV VFs so certain OSes do not need to use the DDW API in order to utilize all available TCE budget. Linux on the other hand removes the default window and creates a bigger one (with more TCEs or/and a bigger page size - 64K/2M) in a bid to map the entire RAM, and if the new window size is smaller than that - it still uses this new bigger window. The result is that the default window is removed but the "ibm,dma-window" property is not. When kdump is invoked, the existing code tries reusing the existing 64bit DMA window which location and parameters are stored in the device tree but this fails as the new property does not make it to the kdump device tree blob. So the code falls back to the default window which does not exist anymore although the device tree says that it does. The result of that is that PCI devices become unusable and cannot be used for kdumping. This preserves the DMA64 and DIRECT64 properties in the device tree blob for the crash kernel. Since the crash kernel setup is done after device drivers are loaded and probed, the proper DMA config is stored at least for boot time devices. Because DDW window is optional and the code configures the default window first, the existing code creates an IOMMU table descriptor for the non-existing default DMA window. It is harmless for kdump as it does not touch the actual window (only reads what is mapped and marks those IO pages as used) but it is bad for kexec which clears it thinking it is a smaller default window rather than a bigger DDW window. This removes the "ibm,dma-window" property from the device tree after a bigger window is created and the crash kernel setup picks it up. Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by: Alexey Kardashevskiy <[email protected]> Acked-by: Hari Bathini <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f762d98f0830d062a10876caea0bd45f2fd2294f Author: Christophe Leroy <[email protected]> Date: Fri Jul 8 09:11:05 2022 +0200 video: fbdev: offb: Include missing linux/platform_device.h [ Upstream commit ebef8abc963b9e537c0a0d619dd8faf1b8f2b183 ] A lot of drivers were getting platform and of headers indirectly via headers like asm/pci.h or asm/prom.h Most of them were fixed during 5.19 cycle but a newissue was introduced by commit 52b1b46c39ae ("of: Create platform devices for OF framebuffers") Include missing platform_device.h to allow cleaning asm/pci.h Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers") Signed-off-by: Christophe Leroy <[email protected]> Acked-by: Helge Deller <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/f75b38367[email protected]csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit 39691e151e5ef411a415723c760e68d6a4f3cc5a Author: Christophe Leroy <[email protected]> Date: Mon Jul 11 16:19:29 2022 +0200 powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32 [ Upstream commit 9be013b2a9ecb29b5168e4b9db0e48ed53acf37c ] Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") enlarged the CPU selection logic to PPC32 by removing depend to PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU. Fortunately that got unnoticed because -mcpu=8540 will override the -mcpu=e500mc64 or -mpcu=e6500 as they are ealier, but that's fragile and may no be right in the future. Add back the depend PPC64 on E5500_CPU and E6500_CPU. Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/8abab4888[email protected]csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit fbe72bebba775244f5f54e0df1f278a42819bf0e Author: Christophe Leroy <[email protected]> Date: Fri Jul 1 08:06:15 2022 +0200 powerpc/32s: Fix boot failure with KASAN + SMP + JUMP_LABEL_FEATURE_CHECK_DEBUG [ Upstream commit 6042a1652d643d1d34fa89bb314cb102960c0800 ] Since commit 4291d085b0b0 ("powerpc/32s: Make pte_update() non atomic on 603 core"), pte_update() has been using mmu_has_feature(MMU_FTR_HPTE_TABLE) to avoid a useless atomic operation on 603 cores. When kasan_early_init() sets up the early zero shadow, it uses __set_pte_at(). On book3s/32, __set_pte_at() calls pte_update() when CONFIG_SMP is selected in order to ensure the preservation of _PAGE_HASHPTE in case of concurrent update of the PTE. But that's too early for mmu_has_feature(), so when CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG is selected, mmu_has_feature() calls printk(). That's too early to call printk() because KASAN early zero shadow page is not set up yet. It leads to a deadlock. However, when kasan_early_init() is called, there is only one CPU running and no risk of concurrent PTE update. So __set_pte_at() can be called with the 'percpu' flag. With that flag set, the PTE is written directly instead of being written via pte_update(). Fixes: 4291d085b0b0 ("powerpc/32s: Make pte_update() non atomic on 603 core") Reported-by: Erhard Furtner <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/2ee707512[email protected]csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit e16c3ac0dc6be3358692e549a568e38b2875cfea Author: Christophe Leroy <[email protected]> Date: Tue Jun 14 12:34:08 2022 +0200 powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping. [ Upstream commit 980bbf7ca72012d317617fcdbfabe8708e4cef29 ] mark_initmem_nx() calls either mmu_mark_initmem_nx() or set_memory_attr() based on return from v_block_mapped() of _sinittext. But we can now handle text and data independently, so that text may be mapped by block even when data is mapped by pages. On the 8xx for instance, at startup 32Mbytes of memory are pinned in TLB. So the pinned entries need to go away for sinittext. In next patch a BAT will be set to also covers sinittext on book3s/32. So it will also be needed to call mmu_mark_initmem_nx() even when data above sinittext is not mapped with BATs. As this is highly dependent on the platform, call mmu_mark_initmem_nx() regardless of data block mapping. Then the platform will know what to do. Modify 8xx mmu_mark_initmem_nx() so that inittext mapping is modified only when pagealloc debug and kfence are not active, otherwise inittext is mapped with standard pages. And don't do anything on kernel text which is already mapped with PAGE_KERNEL_TEXT. Fixes: da1adea07576 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/db3fc14f3[email protected]csgroup.eu Signed-off-by: Sasha Levin <[email protected]> commit e7da0b9764742b3e5064cbaf8154a50694ede28c Author: Claudiu Beznea <[email protected]> Date: Wed Jul 27 12:08:13 2022 +0300 ASoC: mchp-spdifrx: disable end of block interrupt on failures [ Upstream commit 768ac4f12ca0fda935f58eb8c5120e9d795bc6e3 ] Disable end of block interrupt in case of wait for completion timeout or errors to undo previously enable operation (done in mchp_spdifrx_isr_blockend_en()). Otherwise we can end up with an unbalanced reference counter for this interrupt. Fixes: ef265c55c1ac ("ASoC: mchp-spdifrx: add driver for SPDIF RX") Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/20220727090814.2446111-2-claudiu.bezne[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a0ed3a0fbe3c29eead5a4154350112de9ceb212 Author: Rustam Subkhankulov <[email protected]> Date: Mon Jul 18 15:43:43 2022 +0300 video: fbdev: sis: fix typos in SiS_GetModeID() [ Upstream commit 3eb8fccc244bfb41a7961969e4db280d44911226 ] The second operand of a '&&' operator has no impact on expression result for cases 400 and 512 in SiS_GetModeID(). Judging by the logic and the names of the variables, in both cases a typo was made. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rustam Subkhankulov <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a88ab277cca99aeb9a3b2b7db358f1a6dd528b0c Author: Liang He <[email protected]> Date: Tue Jul 19 16:25:46 2022 +0800 video: fbdev: amba-clcd: Fix refcount leak bugs [ Upstream commit 26c2b7d9fac42eb8317f3ceefa4c1a9a9170ca69 ] In clcdfb_of_init_display(), we should call of_node_put() for the references returned by of_graph_get_next_endpoint() and of_graph_get_remote_port_parent() which have increased the refcount. Besides, we should call of_node_put() both in fail path or when the references are not used anymore. Fixes: d10715be03bd ("video: ARM CLCD: Add DT support") Signed-off-by: Liang He <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5529988d6ced06ea77798210f64839c29b1e24bd Author: Yong Zhi <[email protected]> Date: Mon Jul 25 14:49:08 2022 -0500 ASoC: Intel: sof_rt5682: Perform quirk check first in card late probe [ Upstream commit 371a3f01fc1862c23fae35cb2c98ffb2eec143f1 ] The check of sof_rt5682_quirk should not be skipped unless the HDMI handling code exits with error, fix by moving the quirk check to the front. Fixes: 94d2d0897474 ("ASoC: Intel: Boards: tgl_max98373: add dai_trigger function") Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Yong Zhi <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cf9e5cc2a663349df1eef728f65e6a6325490a15 Author: William Dean <[email protected]> Date: Fri Jul 22 11:09:38 2022 +0800 watchdog: armada_37xx_wdt: check the return value of devm_ioremap() in armada_37xx_wdt_probe() [ Upstream commit 2d27e52841092e5831dd41f313028c668d816eb0 ] The function devm_ioremap() in armada_37xx_wdt_probe() can fail, so its return value should be checked. Fixes: 54e3d9b518c8a ("watchdog: Add support for Armada 37xx CPU watchdog") Reported-by: Hacash Robot <[email protected]> Signed-off-by: William Dean <[email protected]> Reviewed-by: Marek Beh=C3=BAn <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ee1fb8f75abe361413913e3a6e93c8c0a4d83cd9 Author: Jean Delvare <[email protected]> Date: Tue Jun 21 15:28:40 2022 +0200 watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource [ Upstream commit c6d9c0798ed366a09a9e53d71edcd2266e34a6eb ] Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak. Signed-off-by: Jean Delvare <[email protected]> Fixes: 0578fff4aae5 ("Watchdog: sp5100_tco: Add initialization using EFCH MMIO") Cc: Terry Bowman <[email protected]> Cc: Wim Van Sebroeck <[email protected]> Cc: Guenter Roeck <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f52959044f798dea767709e19abf462b986e523c Author: Jiasheng Jiang <[email protected]> Date: Thu May 26 16:03:03 2022 +0800 watchdog: f71808e_wdt: Add check for platform_driver_register [ Upstream commit 97d5ec548150764946f38632e62e79759832b54b ] As platform_driver_register() could fail, it should be better to deal with the return value in order to maintain the code consisitency. Fixes: 27e0fe00a5c6 ("watchdog: f71808e_wdt: refactor to platform device/driver pair") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9a49540d29ca603a3fba327bbe8ff2d8327530ba Author: Liang He <[email protected]> Date: Fri Jul 22 22:18:01 2022 +0800 ASoC: audio-graph-card2: Add of_node_put() in fail path [ Upstream commit 8ebc4dd8250fd1cb5da2869c0fe6ae3686fe41e9 ] In asoc_simple_parse_dai(), we should call of_node_put() for the reference returned by of_graph_get_port_parent() in fail path. Fixes: 6e5f68fe3f2d ("ASoC: add Audio Graph Card2 driver") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 375613cc7b8d344ddbf29a92d6c7c25e54ecf421 Author: Liang He <[email protected]> Date: Thu Jul 21 22:43:08 2022 +0800 ASoC: audio-graph-card: Add of_node_put() in fail path [ Upstream commit 65fb8e2ef3531a6e950060fca6e551c923fb0f0e ] In asoc_simple_parse_dai(), we should call of_node_put() for the reference returned by of_graph_get_port_parent() in fail path. Fixes: ae30a694da4c ("ASoC: simple-card-utils: add asoc_simple_card_parse_dai()") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d355da79bcdf3c6a397e4e26e4af062db12708a8 Author: Xie Yongji <[email protected]> Date: Mon Jul 18 16:50:12 2022 +0800 fuse: Remove the control interface for virtio-fs [ Upstream commit c64797809a64c73497082aa05e401a062ec1af34 ] The commit 15c8e72e88e0 ("fuse: allow skipping control interface and forced unmount") tries to remove the control interface for virtio-fs since it does not support aborting requests which are being processed. But it doesn't work now. This patch fixes it by skipping creating the control interface if fuse_conn->no_control is set. Fixes: 15c8e72e88e0 ("fuse: allow skipping control interface and forced unmount") Signed-off-by: Xie Yongji <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f36974f93d00a97c25f8129e84855cb3efb7f886 Author: Christophe JAILLET <[email protected]> Date: Thu Jul 21 11:02:22 2022 +0200 ASoC: qcom: q6dsp: Fix an off-by-one in q6adm_alloc_copp() [ Upstream commit 673f58f62ca6fc98979d1cf3fe89c3ff33f29b2e ] find_first_zero_bit() returns MAX_COPPS_PER_PORT at max here. So 'idx' should be tested with ">=" or the test can't match. Fixes: 7b20b2be51e1 ("ASoC: qdsp6: q6adm: Add q6adm driver") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/0fca3271649[email protected]wanadoo.fr Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 19582e76b2095c5fa5eb009b6eee6b19219d6ac5 Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:53 2022 +0800 ASoC: imx-card: use snd_pcm_format_t type for asrc_format [ Upstream commit 409a8652e909e323c715f3088e6c3133e37c8881 ] Fix sparse warning: sound/soc/fsl/imx-card.c:653:59: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/imx-card.c:653:59: sparse: expected unsigned int [usertype] asrc_format sound/soc/fsl/imx-card.c:653:59: sparse: got restricted snd_pcm_format_t [usertype] sound/soc/fsl/imx-card.c:655:59: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/imx-card.c:655:59: sparse: expected unsigned int [usertype] asrc_format sound/soc/fsl/imx-card.c:655:59: sparse: got restricted snd_pcm_format_t [usertype] Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7a62705535202adcc25ef5cae5a12c4ec2540651 Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:52 2022 +0800 ASoC: fsl_easrc: use snd_pcm_format_t type for sample_format [ Upstream commit de27216cf2d645c2fd14e513707bdcd54e5b1de4 ] Fix sparse warning: sound/soc/fsl/fsl_easrc.c:562:33: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:563:34: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:565:38: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:566:39: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:608:33: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:609:34: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:615:40: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:616:41: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:1465:51: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1465:51: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1465:51: sparse: got restricted snd_pcm_format_t [usertype] format sound/soc/fsl/fsl_easrc.c:1467:52: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1467:52: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1467:52: sparse: got restricted snd_pcm_format_t [usertype] asrc_format sound/soc/fsl/fsl_easrc.c:1470:52: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1470:52: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1470:52: sparse: got restricted snd_pcm_format_t [usertype] format sound/soc/fsl/fsl_easrc.c:1472:51: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1472:51: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1472:51: sparse: got restricted snd_pcm_format_t [usertype] asrc_format sound/soc/fsl/fsl_easrc.c:1484:41: sparse: warning: incorrect type in argument 2 (different base types) sound/soc/fsl/fsl_easrc.c:1484:41: sparse: expected restricted snd_pcm_format_t [usertype] *in_raw_format sound/soc/fsl/fsl_easrc.c:1484:41: sparse: got unsigned int * sound/soc/fsl/fsl_easrc.c:1485:41: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_easrc.c:1485:41: sparse: expected restricted snd_pcm_format_t [usertype] *out_raw_format sound/soc/fsl/fsl_easrc.c:1485:41: sparse: got unsigned int * sound/soc/fsl/fsl_easrc.c:1937:60: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_easrc.c:1937:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_easrc.c:1937:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_easrc.c:1943:49: sparse: warning: restricted snd_pcm_format_t degrades to integer Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit cbb116843f29780b965d26c5b83e4c6564a148a1 Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:51 2022 +0800 ASoC: fsl-asoc-card: force cast the asrc_format type [ Upstream commit 6c7b077dad62178c33f9a3ae17f90d6b0bf6e2e5 ] Fix sparse warning: sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: got restricted snd_pcm_format_t * Fixes: 859e364302c5 ("ASoC: fsl-asoc-card: Support new property fsl, asrc-format") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 78bbb972d25831708089744cdbb45ee975580b99 Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:50 2022 +0800 ASoC: fsl_asrc: force cast the asrc_format type [ Upstream commit c49932726de24405d45516b3f8ad2735714fdf05 ] Fix sparse warning: sound/soc/fsl/fsl_asrc.c:1177:60: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_asrc.c:1177:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_asrc.c:1177:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_asrc.c:1200:47: sparse: warning: restricted snd_pcm_format_t degrades to integer Fixes: 4520af41fd21 ("ASoC: fsl_asrc: Support new property fsl,asrc-format") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a06d8ce519a0a69227211bedd24649f0aa3cbf21 Author: Thomas Richter <[email protected]> Date: Wed Jul 20 14:34:19 2022 +0200 perf test: Fix test case 83 ('perf stat CSV output linter') on s390 [ Upstream commit 87abe344cd280802f431998fabfd35d2d340ca90 ] Perf test case 83: perf stat CSV output linter might fail on s390. The reason for this is the output of the command ./perf stat -x, -A -a --no-merge true which depends on a .config file setting. When CONFIG_SCHED_TOPOLOGY is set, the output of above perf command is CPU0,1.50,msec,cpu-clock,1502781,100.00,1.052,CPUs utilized When CONFIG_SCHED_TOPOLOGY is *NOT* set the output of above perf command is 0.95,msec,cpu-clock,949800,100.00,1.060,CPUs utilized Fix the test case to accept both output formats. Output before: # perf test 83 83: perf stat CSV output linter : FAILED! # Output after: # ./perf test 83 83: perf stat CSV output linter : Ok # Fixes: ec906102e5b7d339 ("perf test: Fix "perf stat CSV output linter" test on s390") Signed-off-by: Thomas Richter <[email protected]> Acked-by: Ian Rogers <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: Vasily Gorbik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 22272ced5f8e1df72594f17fa13fc45dbd87769f Author: Alexander Gordeev <[email protected]> Date: Tue Jul 19 07:16:33 2022 +0200 s390/zcore: fix race when reading from hardware system area [ Upstream commit 9ffed254d938c9e99eb7761c7f739294c84e0367 ] Memory buffer used for reading out data from hardware system area is not protected against concurrent access. Reported-by: Matthew Wilcox <[email protected]> Fixes: 411ed3225733 ("[S390] zfcpdump support.") Acked-by: Heiko Carstens <[email protected]> Tested-by: Alexander Egorenkov <[email protected]> Link: https://lore.kernel.org/r/e[email protected]linux.ibm.com Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8108b1f01892f38898d4d00135397b824534ab2d Author: Alexander Gordeev <[email protected]> Date: Fri Jul 15 12:59:33 2022 +0200 s390/crash: fix incorrect number of bytes to copy to user space [ Upstream commit f6749da17a34eb08c9665f072ce7c812ff68aad2 ] The number of bytes in a chunk is correctly calculated, but instead the total number of bytes is passed to copy_to_user_real() function. Reported-by: Matthew Wilcox <[email protected]> Fixes: df9694c7975f ("s390/dump: streamline oldmem copy functions") Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 951183192aa4035267ec59ade6ad8c4dda26382d Author: Sunil V L <[email protected]> Date: Fri May 27 10:47:40 2022 +0530 riscv: spinwait: Fix hartid variable type [ Upstream commit c029e487e7c00e5594a4ae946952605db34e359b ] The hartid variable is of type int but compared with ULONG_MAX(INVALID_HARTID). This issue is fixed by changing the hartid variable type to unsigned long. Fixes: c78f94f35cf6 ("RISC-V: Use __cpu_up_stack/task_pointer only for spinwait method") Signed-off-by: Sunil V L <[email protected]> Reviewed-by: Atish Patra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit babbfc492c315d9c7084db3906de1e80c5ab542d Author: Adrian Hunter <[email protected]> Date: Mon Jul 11 12:31:44 2022 +0300 perf tools: Fix dso_id inode generation comparison [ Upstream commit 68566a7cf56bf3148797c218ed45a9de078ef47c ] Synthesized MMAP events have zero ino_generation, so do not compare them to DSOs with a real ino_generation otherwise we end up with a DSO without a build id. Fixes: 0e3149f86b99ddab ("perf dso: Move dso_id from 'struct map' to 'struct dso'") Signed-off-by: Adrian Hunter <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: [email protected] Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added clarification to the comment from Ian + more detailed explanation from Adrian ] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fac821e8edea387e7d1f2143756a8ff526a96d69 Author: Liang He <[email protected]> Date: Tue Jul 19 20:49:55 2022 +0800 iommu/arm-smmu: qcom_iommu: Add of_node_put() when breaking out of loop [ Upstream commit a91eb6803c1c715738682fece095145cbd68fe0b ] In qcom_iommu_has_secure_context(), we should call of_node_put() for the reference 'child' when breaking out of for_each_child_of_node() which will automatically increase and decrease the refcount. Fixes: d051f28c8807 ("iommu/qcom: Initialize secure page table") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 58031dde446e047723692943fc0450a07cd12fd8 Author: Mario Limonciello <[email protected]> Date: Mon Jul 18 16:34:02 2022 -0500 ASoC: amd: yc: Decrease level of error message [ Upstream commit 393a40b50fe976a121b15752d2dd6151c7a92126 ] On a number of platforms that contain acp3x controller a new ERR level message is showing up: `acp6x pci device not found` This is because ACP3x and ACP6x share same PCI ID but can be identified by PCI revision. As this is expected behavior for a system with ACP3x decrease message to debug. Fixes: b1630fcbfde6c ("ASoC: amd: yc: add new YC platform varaint support") Cc: Vijendar Mukunda <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a29c40814039535b950149311986a5f348b5db14 Author: Miaoqian Lin <[email protected]> Date: Wed Jun 1 08:32:22 2022 +0400 mfd: max77620: Fix refcount leak in max77620_initialise_fps [ Upstream commit 1520669c8255bd637c6b248b2be910e2688d38dd ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 327156c59360 ("mfd: max77620: Add core driver for MAX77620/MAX20024") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d9384f4b9d5354d38fda24a6c9079b87585c0267 Author: Uwe Kleine-König <[email protected]> Date: Mon May 30 21:24:28 2022 +0200 mfd: t7l66xb: Drop platform disable callback [ Upstream commit 128ac294e1b437cb8a7f2ff8ede1cde9082bddbe ] None of the in-tree instantiations of struct t7l66xb_platform_data provides a disable callback. So better don't dereference this function pointer unconditionally. As there is no user, drop it completely instead of calling it conditional. This is a preparation for making platform remove callbacks return void. Fixes: 1f192015ca5b ("mfd: driver for the T7L66XB TMIO SoC") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit bcc3c1780b276bade65fffa523bf5e0b6412280a Author: Sibi Sankar <[email protected]> Date: Tue Jul 5 17:38:19 2022 +0530 remoteproc: sysmon: Wait for SSCTL service to come up [ Upstream commit 47c04e00eff86a81cd357c3feed04c86089bcb85 ] The SSCTL service comes up after a finite time when the remote Q6 comes out of reset. Any graceful shutdowns requested during this period will be a NOP and abrupt tearing down of the glink channel might lead to pending transactions on the remote Q6 side and will ultimately lead to a fatal error. Fix this by waiting for the SSCTL service when a graceful shutdown is requested. Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1c4dca58bbb61f592d39449caab857aad8ed6ed8 Author: Siddharth Gupta <[email protected]> Date: Tue Jul 5 17:38:17 2022 +0530 remoteproc: qcom: pas: Check if coredump is enabled [ Upstream commit 7b6ece968fca4ec9e42d34caff7e06dc84c45717 ] Client drivers need to check if coredump is enabled for the rproc before continuing with coredump generation. This change adds a check in the PAS driver. Fixes: 8ed8485c4f05 ("remoteproc: qcom: Add capability to collect minidumps") Signed-off-by: Siddharth Gupta <[email protected]> Signed-off-by: Sibi Sankar <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 233221d284534a9cd41345b80c2e21354866351e Author: Zhihao Cheng <[email protected]> Date: Wed Jul 13 21:00:29 2022 +0800 proc: fix a dentry lock race between release_task and lookup [ Upstream commit d919a1e79bac890421537cf02ae773007bf55e6b ] Commit 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") moved proc_flush_task() behind __exit_signal(). Then, process systemd can take long period high cpu usage during releasing task in following concurrent processes: systemd ps kernel_waitid stat(/proc/tgid) do_wait filename_lookup wait_consider_task lookup_fast release_task __exit_signal __unhash_process detach_pid __change_pid // remove task->pid_links d_revalidate -> pid_revalidate // 0 d_invalidate(/proc/tgid) shrink_dcache_parent(/proc/tgid) d_walk(/proc/tgid) spin_lock_nested(/proc/tgid/fd) // iterating opened fd proc_flush_pid | d_invalidate (/proc/tgid/fd) | shrink_dcache_parent(/proc/tgid/fd) | shrink_dentry_list(subdirs) ↓ shrink_lock_dentry(/proc/tgid/fd) --> race on dentry lock Function d_invalidate() will remove dentry from hash firstly, but why does proc_flush_pid() process dentry '/proc/tgid/fd' before dentry '/proc/tgid'? That's because proc_pid_make_inode() adds proc inode in reverse order by invoking hlist_add_head_rcu(). But proc should not add any inodes under '/proc/tgid' except '/proc/tgid/task/pid', fix it by adding inode into 'pid->inodes' only if the inode is /proc/tgid or /proc/tgid/task/pid. Performance regression: Create 200 tasks, each task open one file for 50,000 times. Kill all tasks when opened files exceed 10,000,000 (cat /proc/sys/fs/file-nr). Before fix: $ time killall -wq aa real 4m40.946s # During this period, we can see 'ps' and 'systemd' taking high cpu usage. After fix: $ time killall -wq aa real 1m20.732s # During this period, we can see 'systemd' taking high cpu usage. Link: https://lkml.kernel.org/r/[email protected] Fixes: 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216054 Signed-off-by: Zhihao Cheng <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Suggested-by: Brian Foster <[email protected]> Reviewed-by: Brian Foster <[email protected]> Cc: Al Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Baoquan He <[email protected]> Cc: Kalesh Singh <[email protected]> Cc: Yu Kuai <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 80741a6a34a111a83d035bfa558440f5e181b093 Author: Tetsuo Handa <[email protected]> Date: Wed Jun 22 14:46:31 2022 +0900 lib/smp_processor_id: fix imbalanced instrumentation_end() call [ Upstream commit bd27acaac24e4b252ee28dddcabaee80456d0faf ] Currently instrumentation_end() won't be called if printk_ratelimit() returned false. Link: https://lkml.kernel.org/r/[email protected] Fixes: 126f21f0e8d46e2c ("lib/smp_processor_id: Move it into noinstr section") Signed-off-by: Tetsuo Handa <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Alexandre Chartre <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 438be61de8d233c99fbca5ca74bc6f67e281c389 Author: Dan Carpenter <[email protected]> Date: Fri Jun 24 08:30:04 2022 +0300 kfifo: fix kfifo_to_user() return type [ Upstream commit 045ed31e23aea840648c290dbde04797064960db ] The kfifo_to_user() macro is supposed to return zero for success or negative error codes. Unfortunately, there is a signedness bug so it returns unsigned int. This only affects callers which try to save the result in ssize_t and as far as I can see the only place which does that is line6_hwdep_read(). TL;DR: s/_uint/_int/. Link: https://lkml.kernel.org/r/[email protected] Fixes: 144ecf310eb5 ("kfifo: fix kfifo_alloc() to return a signed int value") Signed-off-by: Dan Carpenter <[email protected]> Cc: Stefani Seibold <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 11f6fec9a014e15e7ec2e3f8c82b22d990c5e1b2 Author: Emil Renner Berthing <[email protected]> Date: Tue Jul 5 23:01:40 2022 +0200 leds: pwm-multicolor: Don't show -EPROBE_DEFER as errors [ Upstream commit 399e7aa82105ea46d8998fa535b047541c48030f ] When requesting a PWM it might return -EPROBE_DEFER if it hasn't probed yet. This is not an error, so just propagate the -EPROBE_DEFER without logging anything. There is already dev_err_probe for exactly this situation. Fixes: 9fa2762110dd ("leds: Add PWM multicolor driver") Signed-off-by: Emil Renner Berthing <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Pavel Machek <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 43e42c25a232a6862e7d2f292a069ac828559030 Author: Miaoqian Lin <[email protected]> Date: Wed May 11 16:07:37 2022 +0400 rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge [ Upstream commit 65382585f067d4256ba087934f30f85c9b6984de ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b976cd24e87f673a3d2ef01d7c44eddc5e38b593 Author: Florian Fainelli <[email protected]> Date: Thu Jul 14 15:25:12 2022 -0700 MIPS: Fixed __debug_virt_addr_valid() [ Upstream commit 8a2b456665d1e797123669581524cbb095fb003b ] It is permissible for kernel code to call virt_to_phys() against virtual addresses that are in KSEG0 or KSEG1 and we need to be dealing with both types. Rewrite the test condition to ensure that the kernel virtual addresses are above PAGE_OFFSET which they must be, and below KSEG2 where the non-linear mapping starts. For EVA, there is not much that we can do given the linear address range that is offered, so just return any virtual address as being valid. Finally, when HIGHMEM is not enabled, all virtual addresses are assumed to be valid as well. Fixes: dfad83cb7193 ("MIPS: Add support for CONFIG_DEBUG_VIRTUAL") Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Serge Semin <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 34b9a188557c1d5a50e07cf228d054101aee0af3 Author: Hangyu Hua <[email protected]> Date: Wed Jul 13 09:55:11 2022 +0900 net: 9p: fix refcount leak in p9_read_work() error handling [ Upstream commit 4ac7573e1f9333073fa8d303acc941c9b7ab7f61 ] p9_req_put need to be called when m->rreq->rc.sdata is NULL to avoid temporary refcount leak. Link: https://lkml.kernel.org/r/[email protected] Fixes: 728356dedeff ("9p: Add refcount to p9_req_t") Signed-off-by: Hangyu Hua <[email protected]> [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase] Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c9d5188f5151742eba9b7b671b1739e1304abe07 Author: Kent Overstreet <[email protected]> Date: Sun Jul 3 21:08:18 2022 -0400 9p: Add client parameter to p9_req_put() [ Upstream commit 8b11ff098af42b1fa57fc817daadd53c8b244a0c ] This is to aid in adding mempools, in the next patch. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kent Overstreet <[email protected]> Cc: Eric Van Hensbergen <[email protected]> Cc: Latchesar Ionkov <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2b38ea66703f230b5dbf884696907ac0b9509b24 Author: Kent Overstreet <[email protected]> Date: Sun Jul 3 21:02:49 2022 -0400 9p: Drop kref usage [ Upstream commit 6cda12864cb0f99810a5809e11e3ee5b102c9a47 ] An upcoming patch is going to require passing the client through p9_req_put() -> p9_req_free(), but that's awkward with the kref indirection - so this patch switches to using refcount_t directly. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kent Overstreet <[email protected]> Cc: Eric Van Hensbergen <[email protected]> Cc: Latchesar Ionkov <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 59cb621ace216d4daa47fb63c366ba635af667b3 Author: Sam Protsenko <[email protected]> Date: Thu Jul 14 19:55:46 2022 +0300 iommu/exynos: Handle failed IOMMU device registration properly [ Upstream commit fce398d2d02c0a9a2bedf7c7201b123e153e8963 ] If iommu_device_register() fails in exynos_sysmmu_probe(), the previous calls have to be cleaned up. In this case, the iommu_device_sysfs_add() should be cleaned up, by calling its remove counterpart call. Fixes: d2c302b6e8b1 ("iommu/exynos: Make use of iommu_device_register interface") Signed-off-by: Sam Protsenko <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Acked-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fe831fcc9ab32a0e2ce036e37420a713caa3f361 Author: Doug Berger <[email protected]> Date: Wed Jul 13 20:13:15 2022 -0700 serial: 8250_bcm7271: Save/restore RTS in suspend/resume [ Upstream commit 3182efd036c1b955403d131258234896cbd9fbeb ] Commit 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming from S2") prevented an early enabling of RTS during resume, but it did not actively restore the RTS state after resume. Fixes: 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming from S2") Signed-off-by: Doug Berger <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 27e070151cd39e72150a977a17b3de0d5ed7571d Author: Dan Carpenter <[email protected]> Date: Fri Jul 8 16:48:36 2022 +0300 ASoC: SOF: ipc-msg-injector: fix copy in sof_msg_inject_ipc4_dfs_write() [ Upstream commit fa9b878ff86f4adccddf62492a5894fbdb04f97d ] There are two bugs that have to do with when we copy the payload: size = simple_write_to_buffer(ipc4_msg->data_ptr, priv->max_msg_size, ppos, buffer, count); The value of "*ppos" was supposed to be zero but it is sizeof(ipc4_msg->header_u64) so it will copy the data into the middle of the "ipc4_msg->data_ptr" buffer instead of to the start. The second problem is "buffer" should be "buffer + sizeof(ipc4_msg->header_u64)". This function is used for fuzz testing so the data is normally random and this bug likely does not affect anyone very much. In this context, it's simpler and more appropriate to use copy_from_user() instead of simple_write_to_buffer() so I have re-written the function. Fixes: 066c67624d8c ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1e7fe6906e9755d9e0242f9619c894ecd82fb9da Author: Liang He <[email protected]> Date: Wed Jul 13 18:20:13 2022 +0800 ASoC: mt6359: Fix refcount leak bug [ Upstream commit a8d5df69e2ec702d979f7d04ed519caf8691a032 ] In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 683530285316 ("ASoC: mt6359: fix failed to parse DT properties") Fixes: eef07b9e0925 ("ASoC: mediatek: mt6359: add MT6359 accdet jack driver") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7a63a8c253bf57dfd9fa3ee2a7f1a3727505f947 Author: Liang He <[email protected]> Date: Wed Jul 13 15:12:00 2022 +0800 ASoc: audio-graph-card2: Fix refcount leak bug in __graph_get_type() [ Upstream commit eda26893dabfc6da7a1e1ff5f8628ed9faab3ab9 ] We should call of_node_put() for the reference before its replacement as it returned by of_get_parent() which has increased the refcount. Besides, we should also call of_node_put() before return. Fixes: c8c74939f791 ("ASoC: audio-graph-card2: add Multi CPU/Codec support") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6d90c0829fe73c478e63fe90b4cec716271fb6e1 Author: Yang Yingliang <[email protected]> Date: Tue May 17 21:34:50 2022 +0800 cpufreq: mediatek: fix error return code in mtk_cpu_dvfs_info_init() [ Upstream commit 72d67d6b3447303a441a8cedc34f7224b75f64b5 ] If regulator_get_voltage() fails, it should return the error code in mtk_cpu_dvfs_info_init(). Fixes: 0daa47325bae ("cpufreq: mediatek: Link CCI device to CPU") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c2eddfcafcffaf1b9245ea0dde9143bbfb47d5d1 Author: Peter Ujfalusi <[email protected]> Date: Tue Jul 12 16:01:03 2022 +0300 ASoC: SOF: ipc3-topology: Prevent double freeing of ipc_control_data via load_bytes [ Upstream commit d5bd47f3ca124058a8e87eae4508afeda2132611 ] We have sanity checks for byte controls and if any of the fail the locally allocated scontrol->ipc_control_data is freed up, but not set to NULL. On a rollback path of the error the higher level code will also try to free the scontrol->ipc_control_data which will eventually going to lead to memory corruption as double freeing memory is not a good thing. Fixes: b5cee8feb1d4 ("ASoC: SOF: topology: Make control parsing IPC agnostic") Reported-by: Seppo Ingalsuo <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ee20cdbedeb274629715aed2e74c7e9ff1bce3c2 Author: Alexander Lobakin <[email protected]> Date: Mon Jul 11 20:09:29 2022 +0200 lib/bitmap: fix off-by-one in bitmap_to_arr64() [ Upstream commit 428bc098635680a664779f26f24fe9197d186172 ] GENMASK*() family takes the first and the last bits of the mask *including* them. So, with the current code bitmap_to_arr64() doesn't clear the tail properly: nbits % exp mask must be 1 GENMASK(1, 0) 0x3 0x1 ... 63 GENMASK(63, 0) 0xffffffffffffffff 0x7fffffffffffffff This was found by making the function always available instead of 32-bit BE systems only (for reusing in some new functionality). Turn the number of bits into the last bit set by subtracting 1. @nbits is already checked to be positive beforehand. Fixes: 0a97953fd221 ("lib: add bitmap_{from,to}_arr64") Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4e43ae1055c8eb7f896e7e6058c356df42c6ab7f Author: Robin Murphy <[email protected]> Date: Tue Jul 12 08:46:45 2022 +0200 swiotlb: fail map correctly with failed io_tlb_default_mem [ Upstream commit c51ba246cb172c9e947dc6fb8868a1eaf0b2a913 ] In the failure case of trying to use a buffer which we'd previously failed to allocate, the "!mem" condition is no longer sufficient since io_tlb_default_mem became static and assigned by default. Update the condition to work as intended per the rest of that conversion. Fixes: 463e862ac63e ("swiotlb: Convert io_default_tlb_mem to static allocation") Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4d9985f7935a1a957c6defd33c4545b04cfdc644 Author: YC Hung <[email protected]> Date: Fri Jul 8 15:39:04 2022 -0500 ASoC: SOF: mediatek: fix mt8195 StatvectorSel wrong setting [ Upstream commit 99bad468846f7a255dcfc95454401c83ae02e89b ] Fix StatVectorSel wrong setting. Fixes: b7f6503830 ("ASoC: SOF: mediatek: Add fw loader and mt8195 dsp ops to load firmware") Signed-off-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: YC Hung <[email protected]> Reviewed-by: Li-Yu Yu <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: KuanHsun Cheng <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6712456b97a8b119c8e37150f24615693dc98a7f Author: Florian Fainelli <[email protected]> Date: Thu Jul 7 13:27:58 2022 -0700 MIPS: vdso: Utilize __pa() for gic_pfn [ Upstream commit 8baa65126e19af5ee9f3c07e7bb53da41c39e4b1 ] The GIC user offset is mapped into every process' virtual address and is therefore part of the hot-path of arch_setup_additional_pages(). Utilize __pa() such that we are more optimal even when CONFIG_DEBUG_VIRTUAL is enabled, and while at it utilize PFN_DOWN() instead of open-coding the right shift by PAGE_SHIFT. Reported-by: Greg Ungerer <[email protected]> Suggested-by: Serge Semin <[email protected]> Fixes: dfad83cb7193 ("MIPS: Add support for CONFIG_DEBUG_VIRTUAL") Signed-off-by: Florian Fainelli <[email protected]> Acked-by: Greg Ungerer <[email protected]rg> Tested-by: Greg Ungerer <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 24578ae33973ee1947e7138863c2e8c6cb134616 Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:23 2022 +0200 tty: n_gsm: fix missing corner cases in gsmld_poll() [ Upstream commit 7e5b4322cde067e1d0f1bf8f490e93f664a7c843 ] gsmld_poll() currently fails to handle the following corner cases correctly: - remote party closed the associated tty Add the missing checks and map those to EPOLLHUP. Reorder the checks to group them by their reaction. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 96114c3b26956f536275bc0267d1ba91bfb8782c Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:22 2022 +0200 tty: n_gsm: fix flow control handling in tx path [ Upstream commit 59ff0680ecbfec742b1e0381e7cc46b41eb06647 ] The current implementation constipates all transmission paths during flow control except for flow control frames. However, these may not be located at the beginning of the transmission queue of the control channel. Ensure that flow control frames in the transmission queue for the control channel are always handled even if constipated by skipping through other messages. Fixes: 0af021678d5d ("tty: n_gsm: fix deadlock and link starvation in outgoing data path") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e5e39b524473d86b022b9d45e680f2a66626cb17 Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:21 2022 +0200 tty: n_gsm: fix DM command [ Upstream commit 18a948c7d90995d127785e308fa7b701df4c499f ] n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.3.3 defines the DM response. There exists no DM command. However, the current implementation incorrectly sends DM as command in case of unexpected UIH frames in gsm_queue(). Correct this behavior by always sending DM as response. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9a5143207cad34d13a3f6a912adabad53384a8ad Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:20 2022 +0200 tty: n_gsm: fix wrong T1 retry count handling [ Upstream commit f30e10caa80aa1f35508bc17fc302dbbde9a833c ] n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.7.3 states that the valid range for the maximum number of retransmissions (N2) is from 0 to 255 (both including). gsm_dlci_t1() handles this number incorrectly by performing N2 - 1 retransmission attempts. Setting N2 to zero results in more than 255 retransmission attempts. Fix gsm_dlci_t1() to comply with 3GPP 27.010. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 233be4375a883de45fb9d431e0e4b4b7d28de91a Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 4 10:51:19 2022 +0200 serial: 8250_fsl: Don't report FE, PE and OE twice [ Upstream commit 9d3aaceb73acadf134596a2f8db9c451c1332d3d ] Some Freescale 8250 implementations have the problem that a single long break results in one irq per character frame time. The code in fsl8250_handle_irq() that is supposed to handle that uses the BI bit in lsr_saved_flags to detect such a situation and then skip the second received character. However it also stores other error bits and so after a single frame error the character received in the next irq handling is passed to the upper layer with a frame error, too. So after a spike on the data line (which is correctly recognized as a frame error) the following valid character is thrown away, because the driver reports a frame error for that one, too. To weaken this problem restrict saving LSR to only the BI bit. Note however that the handling is still broken: - lsr_saved_flags is updated using orig_lsr which is the LSR content for the first received char, but there might be more in the FIFO, so a character is thrown away that is received later and not necessarily the one following the break. - The doubled break might be the 2nd and 3rd char in the FIFO, so the workaround doesn't catch these, because serial8250_rx_chars() doesn't handle the workaround. - lsr_saved_flags might have set UART_LSR_BI at the entry of fsl8250_handle_irq() which doesn't originate from fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr & UART_LSR_BI;" but from e.g. from serial8250_tx_empty(). - For a long or a short break this isn't about two characters, but more or only a single one. Fixes: 9deaa53ac7fa ("serial: add irq handler for Freescale 16550 errata.") Acked-by: Ilpo Järvinen <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d4145731e3f875145f21eb780777f7bf2252a476 Author: Kuninori Morimoto <[email protected]> Date: Fri Jul 1 05:18:14 2022 +0000 ASoC: audio-graph-card2.c: use of_property_read_u32() for rate [ Upstream commit 817a62108dfacebd548e38451bf0e7eee023e97f ] Audio Graph Card2 is using of_get_property(), but it should use of_property_read_u32() to getting rate. Otherwise the setting will be strange value. This patch fixup it. Fixes: c3a15c92a67b701 ("ASoC: audio-graph-card2: add Codec2Codec support") Signed-off-by: Kuninori Morimoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8c8d8ff760947ee0f2b7c9220888cea714238154 Author: Eric Farman <[email protected]> Date: Thu Jul 7 15:57:29 2022 +0200 vfio/ccw: Do not change FSM state in subchannel event [ Upstream commit cffcc109fd682075dee79bade3d60a07152a8fd1 ] The routine vfio_ccw_sch_event() is tasked with handling subchannel events, specifically machine checks, on behalf of vfio-ccw. It correctly calls cio_update_schib(), and if that fails (meaning the subchannel is gone) it makes an FSM event call to mark the subchannel Not Operational. If that worked, however, then it decides that if the FSM state was already Not Operational (implying the subchannel just came back), then it should simply change the FSM to partially- or fully-open. Remove this trickery, since a subchannel returning will require more probing than simply "oh all is well again" to ensure it works correctly. Fixes: bbe37e4cb8970 ("vfio: ccw: introduce a finite state machine") Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b9c7dddf384e2ed7e38fc351408acc409348735e Author: Eric Farman <[email protected]> Date: Thu Jul 7 15:57:28 2022 +0200 vfio/ccw: Fix FSM state if mdev probe fails [ Upstream commit f6c876d67e956de8d69349b0ee43bc7277c09e5c ] The FSM is in STANDBY state when arriving in vfio_ccw_mdev_probe(), and this routine converts it to IDLE as part of its processing. The error exit sets it to IDLE (again) but clears the private->mdev pointer. The FSM should of course be managing the state itself, but the correct thing for vfio_ccw_mdev_probe() to do would be to put the state back the way it found it. The corresponding check of private->mdev in vfio_ccw_sch_io_todo() can be removed, since the distinction is unnecessary at this point. Fixes: 3bf1311f351ef ("vfio/ccw: Convert to use vfio_register_emulated_iommu_dev()") Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 46580fbbc52c0a3088fa8fa2d0d7d1818c84c0f0 Author: Michael Kawano <[email protected]> Date: Thu Jul 7 15:57:27 2022 +0200 vfio/ccw: Remove UUID from s390 debug log [ Upstream commit 3566ee1d776c1393393564b2514f9cd52a49c16e ] As vfio-ccw devices are created/destroyed, the uuid of the associated mdevs that are recorded in $S390DBF/vfio_ccw_msg/sprintf get lost. This is because a pointer to the UUID is stored instead of the UUID itself, and that memory may have been repurposed if/when the logs are examined. The result is usually garbage UUID data in the logs, though there is an outside chance of an oops happening here. Simply remove the UUID from the traces, as the subchannel number will provide useful configuration information for problem determination, and is stored directly into the log instead of a pointer. As we were the only consumer of mdev_uuid(), remove that too. Cc: Kirti Wankhede <[email protected]> Signed-off-by: Michael Kawano <[email protected]> Fixes: 60e05d1cf0875 ("vfio-ccw: add some logging") Fixes: b7701dfbf9832 ("vfio-ccw: Register a chp_event callback for vfio-ccw") [farman: reworded commit message, added Fixes: tags] Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Reviewed-by: Kirti Wankhede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 606f14d93ac65c58b5015c202fd4cbd3dea9c988 Author: Sireesh Kodali <[email protected]> Date: Thu May 26 19:47:39 2022 +0530 remoteproc: qcom: wcnss: Fix handling of IRQs [ Upstream commit bed0adac1ded4cb486ba19a3a7e730fbd9a1c9c6 ] The wcnss_get_irq function is expected to return a value > 0 in the event that an IRQ is succssfully obtained, but it instead returns 0. This causes the stop and ready IRQs to never actually be used despite being defined in the device-tree. This patch fixes that. Fixes: aed361adca9f ("remoteproc: qcom: Introduce WCNSS peripheral image loader") Signed-off-by: Sireesh Kodali <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 0114dd51475c484b347984e4028e13cb1a01faad Author: Shengjiu Wang <[email protected]> Date: Wed Jul 6 17:42:55 2022 +0800 ASoC: imx-card: Fix DSD/PDM mclk frequency [ Upstream commit c0fabd12a8570cb932f13d9388f3d887ad44369b ] The DSD/PDM rate not only DSD64/128/256/512, which are the multiple rate of 44.1kHz, but also support the multiple rate of 8kHz, so can't force all mclk frequency to be 22579200Hz, need to assign the frequency according to rate. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit eaba8754c2d2645a7a38b3fd67a5614037a64ec1 Author: Tiezhu Yang <[email protected]> Date: Mon Jun 27 15:07:13 2022 +0800 MIPS: Loongson64: Fix section mismatch warning [ Upstream commit 08472f6ebdc23334ad11dcd761d2d52c32897793 ] prom_init_numa_memory() is annotated __init and not used by any module, thus don't export it. Remove not needed EXPORT_SYMBOL for prom_init_numa_memory() to fix the following section mismatch warning: LD vmlinux.o MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab+prom_init_numa_memory+0x0): Section mismatch in reference from the variable __ksymtab_prom_init_numa_memory to the function .init.text:prom_init_numa_memory() The symbol prom_init_numa_memory is exported and annotated __init Fix this by removing the __init annotation of prom_init_numa_memory or drop the export. This is build on Linux 5.19-rc4. Fixes: 6fbde6b492df ("MIPS: Loongson64: Move files to the top-level directory") Signed-off-by: Tiezhu Yang <[email protected]> Reviewed-by: Huacai Chen <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fc90b34c227c07751aebd52b77d38e92391a6c73 Author: Liang He <[email protected]> Date: Sat Jul 2 10:01:09 2022 +0800 ASoC: qcom: Fix missing of_node_put() in asoc_qcom_lpass_cpu_platform_probe() [ Upstream commit f507c0c67dac57d2bcd5dcae4b6139b0305d8957 ] We should call of_node_put() for the reference 'dsp_of_node' returned by of_parse_phandle() which will increase the refcount. Fixes: 9bae4880acee ("ASoC: qcom: move ipq806x specific bits out of lpass driver.") Co-authored-by: Miaoqian Lin <[email protected]> Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bd5f447061a11a603a97c9810de1b814e283bd2d Author: Daniel Starke <[email protected]> Date: Fri Jul 1 14:23:32 2022 +0200 tty: n_gsm: fix resource allocation order in gsm_activate_mux() [ Upstream commit 7349660438603ed19282e75949561406531785a5 ] Within gsm_activate_mux() all timers and locks are initiated before the actual resource for the control channel is allocated. This can lead to race conditions. Allocate the control channel DLCI object first to avoid race conditions. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7962a4b900099cf90e02859bb297f2c618d8d940 Author: Daniel Starke <[email protected]> Date: Fri Jul 1 14:23:31 2022 +0200 tty: n_gsm: fix deadlock and link starvation in outgoing data path [ Upstream commit 0af021678d5d30c31f5a6b631f404ead3575212a ] The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 </IRQ> <TASK> asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 08 e8 58 bc 02 00 8b 44 24 08 48 83 c4 10 5d c3 48 63 ff b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 76 10 48 8b 15 fd fc 05 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffcee77cd18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007ffcee77cd70 RCX: 00007f3e5e35c15c RDX: 0000000000000100 RSI: 00007ffcee77cd90 RDI: 0000000000000003 RBP: 0000000000000100 R08: 0000000000000000 R09: 7efefefefefefeff R10: 00007f3e5e3bddeb R11: 0000000000000246 R12: 00007ffcee77ce8f R13: 0000000000000001 R14: 000056214404e010 R15: 00007ffcee77cd90 </TASK> Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5320aa45f526ddd3374e6226842467b788894b34 Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:52 2022 +0200 tty: n_gsm: fix race condition in gsmld_write() [ Upstream commit 32dd59f96924f45e33bc79854f7a00679c0fa28e ] The function may be used by the user directly and also by the n_gsm internal functions. They can lead into a race condition which results in interleaved frames if both are writing at the same time. The receiving side is not able to decode those interleaved frames correctly. Add a lock around the low side tty write to avoid race conditions and frame interleaving between user originated writes and n_gsm writes. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 51556905dda5596649147f8704f64a58dfccd19b Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:50 2022 +0200 tty: n_gsm: fix packet re-transmission without open control channel [ Upstream commit 4fae831b3a71fc5a44cc5c7d0b8c1267ee7659f5 ] In the current implementation control packets are re-transmitted even if the control channel closed down during T2. This is wrong. Check whether the control channel is open before re-transmitting any packets. Note that control channel open/close is handled by T1 and not T2 and remains unaffected by this. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2012b064f9895e0958f3c8612fa2c120efd32bbd Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:48 2022 +0200 tty: n_gsm: fix non flow control frames during mux flow off [ Upstream commit bec0224816d19abe4fe503586d16d51890540615 ] n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.4.6.3.6 states that FCoff stops the transmission on all channels except the control channel. This is already implemented in gsm_data_kick(). However, chapter 5.4.8.1 explains that this shall result in the same behavior as software flow control on the ldisc in advanced option mode. That means only flow control frames shall be sent during flow off. The current implementation does not consider this case. Change gsm_data_kick() to send only flow control frames if constipated to abide the standard. gsm_read_ea_val() and gsm_is_flow_ctrl_msg() are introduced as helper functions for this. It is planned to use gsm_read_ea_val() in later code cleanups for other functions, too. Fixes: c01af4fec2c8 ("n_gsm : Flow control handling in Mux driver") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 692e847a8e6607909c4a3f98ab16ccee7849bd11 Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:47 2022 +0200 tty: n_gsm: fix missing timer to handle stalled links [ Upstream commit c568f7086c6e771c77aad13d727c70ef70e07243 ] The current implementation does not handle the situation that no data is in the internal queue and needs to be sent out while the user tty fifo is full. Add a timer that moves more data from user tty down to the internal queue which is then serialized on the ldisc. This timer is triggered if no data was moved from a user tty to the internal queue within 10 * T1. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e5e1eed82338fba33e8d02c841cc26055c2614c9 Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:46 2022 +0200 tty: n_gsm: fix wrong queuing behavior in gsm_dlci_data_output() [ Upstream commit 556fc8ac06513cced381588d6d58c184d95cc4fe ] 1) The function drains the fifo for the given user tty/DLCI without considering 'TX_THRESH_HI' and different to gsm_dlci_data_output_framed(), which moves only one packet from the user side to the internal transmission queue. We can only handle one packet at a time here if we want to allow DLCI priority handling in gsm_dlci_data_sweep() to avoid link starvation. 2) Furthermore, the additional header octet from convergence layer type 2 is not counted against MTU. It is part of the UI/UIH frame message which needs to be limited to MTU. Hence, it is wrong not to consider this octet. 3) Finally, the waiting user tty is not informed about freed space in its send queue. Take at most one packet worth of data out of the DLCI fifo to fix 1). Limit the max user data size per packet to MTU - 1 in case of convergence layer type 2 to leave space for the control signal octet which is added in the later part of the function. This fixes 2). Add tty_port_tty_wakeup() to wake up the user tty if new write space has been made available to fix 3). Fixes: 268e526b935e ("tty/n_gsm: avoid fifo overflow in gsm_dlci_data_output") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5e59c010c6862da329db17acca086afd8bea1aa8 Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:45 2022 +0200 tty: n_gsm: fix tty registration before control channel open [ Upstream commit 01aecd917114577c423f07cec0d186ad007d76fc ] The current implementation registers/deregisters the user ttys at mux attach/detach. That means that the user devices are available before any control channel is open. However, user channel initialization requires an open control channel. Furthermore, the user is not informed if the mux restarts due to configuration changes. Put the registration/deregistration procedure into separate function to improve readability. Move registration to mux activation and deregistration to mux cleanup to keep the user devices only open as long as a control channel exists. The user will be informed via the device driver if the mux was reconfigured in a way that required a mux re-activation. This makes it necessary to add T2 initialization to gsmld_open() for the ldisc open code path (not the reconfiguration code path) to avoid deletion of an uninitialized T2 at mux cleanup. Fixes: d50f6dcaf22a ("tty: n_gsm: expose gsmtty device nodes at ldisc open time") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 07a07c87c0d2a16f145e38a726432f3d845e4445 Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:44 2022 +0200 tty: n_gsm: fix user open not possible at responder until initiator open [ Upstream commit ac77f0077c3265197d378158c85a55eee6d21508 ] After setting up the control channel on both sides the responder side may want to open a virtual tty to listen on until the initiator starts an application on a user channel. The current implementation allows the open() but no other operation, like termios. These fail with EINVAL. The responder sided application has no means to detect an open by the initiator sided application this way. And the initiator sided applications usually expect the responder sided application to listen on the user channel upon open. Set the user channel into half-open state on responder side once a user application opens the virtual tty to allow IO operations on it. Furthermore, keep the user channel constipated until the initiator side opens it to give the responder sided application the chance to detect the new connection and to avoid data loss if the responder sided application starts sending before the user channel is open. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5e512be069fa8d495391fed1f53f500af74da3af Author: Alexander Lobakin <[email protected]> Date: Fri Jun 24 14:13:11 2022 +0200 net/ice: fix initializing the bitmap in the switch code [ Upstream commit 2f7ee2a72ccec8b85a05c4644d7ec9f40c1c50c8 ] Kbuild spotted the following bug during the testing of one of the optimizations: In file included from include/linux/cpumask.h:12, [...] from drivers/net/ethernet/intel/ice/ice_switch.c:4: drivers/net/ethernet/intel/ice/ice_switch.c: In function 'ice_find_free_recp_res_idx.constprop': include/linux/bitmap.h:447:22: warning: 'possible_idx[0]' is used uninitialized [-Wuninitialized] 447 | *map |= GENMASK(start + nbits - 1, start); | ^~ In file included from drivers/net/ethernet/intel/ice/ice.h:7, from drivers/net/ethernet/intel/ice/ice_lib.h:7, from drivers/net/ethernet/intel/ice/ice_switch.c:4: drivers/net/ethernet/intel/ice/ice_switch.c:4929:24: note: 'possible_idx[0]' was declared here 4929 | DECLARE_BITMAP(possible_idx, ICE_MAX_FV_WORDS); | ^~~~~~~~~~~~ include/linux/types.h:11:23: note: in definition of macro 'DECLARE_BITMAP' 11 | unsigned long name[BITS_TO_LONGS(bits)] | ^~~~ %ICE_MAX_FV_WORDS is 48, so bitmap_set() here was initializing only 48 bits, leaving a junk in the rest 16. It was previously hidden due to that filling 48 bits makes bitmap_set() call external __bitmap_set(), but after making it use plain bit arithmetics on small bitmaps, compilers started seeing the issue. It was still working because those 16 weren't used anywhere anyhow. bitmap_{clear,set}() are not really intended to initialize bitmaps, rather to modify already initialized ones, as they don't do anything past the passed number of bits. The correct function to do this in that particular case is bitmap_fill(), so use it here. It will do `*possible_idx = ~0UL` instead of `*possible_idx |= GENMASK(47, 0)`, not leaving anything in an undefined state. Fixes: fd2a6b71e300 ("ice: create advanced switch recipe") Reported-by: kernel test robot <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bba6b12d73d36e0ddbc2c3ac5668a667b00d4345 Author: Yishai Hadas <[email protected]> Date: Tue Jun 28 18:59:10 2022 +0300 vfio: Split migration ops from main device ops [ Upstream commit 6e97eba8ad8748fabb795cffc5d9e1a7dcfd7367 ] vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps. Fixes: 6fadb021266d ("vfio/mlx5: Implement vfio_pci driver for mlx5 devices") Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Yishai Hadas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 74b28771699892df6b6bcb336c3e3542abf2216d Author: Yishai Hadas <[email protected]> Date: Tue Jun 28 18:59:09 2022 +0300 vfio/mlx5: Protect mlx5vf_disable_fds() upon close device [ Upstream commit 2b1c1906286fa547845f5385ee72db74b2b0251d ] Protect mlx5vf_disable_fds() upon close device to be called under the state mutex as done in all other places. This will prevent a race with any other flow which calls mlx5vf_disable_fds() as of health/recovery upon MLX5_PF_NOTIFY_DISABLE_VF event. Encapsulate this functionality in a separate function named mlx5vf_cmd_close_migratable() to consider migration caps and for further usage upon close device. Fixes: 6fadb021266d ("vfio/mlx5: Implement vfio_pci driver for mlx5 devices") Reviewed-by: Kevin Tian <[email protected]> Signed-off-by: Yishai Hadas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8d201dedc793be2dcaf4a44adc7eaa09fdc0213b Author: Srinivas Kandagatla <[email protected]> Date: Thu Jun 30 14:00:22 2022 +0100 ASoC: codecs: wsa881x: handle timeouts in resume path [ Upstream commit cf6af24b54903f9f70c29b3e5b19cb72cc862d60 ] Currently we do not check if SoundWire slave initialization timeout expired before continuing to access its registers. Its possible that the registers are not accessible if timeout is expired. Handle this by returning timeout in resume path. Reported-by: Pierre-Louis Bossart <[email protected]> Fixes: 8dd552458361 ("ASoC: codecs: wsa881x: add runtime pm support") Signed-off-by: Srinivas Kandagatla <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 317a412812d8051af618cbc0ff75f216130e767c Author: Ilpo Järvinen <[email protected]> Date: Tue Jun 28 12:01:28 2022 +0300 serial: 8250_dw: Take port lock while accessing LSR [ Upstream commit b9491b2e45d71eb64245560e208897af95ffbf95 ] Accessing LSR requires port lock because it mutates lsr_saved_flags in serial_lsr_in(). Fixes: 197eb5c416ff ("serial: 8250_dw: Use serial_lsr_in() in dw8250_handle_irq()") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1fbdfbaa3cc3ad9a331bdd49d9b64f8bd49d922e Author: Tom Rix <[email protected]> Date: Wed Jun 29 14:53:45 2022 -0400 ASoC: samsung: change gpiod_speaker_power and rx1950_audio from global to static variables [ Upstream commit d2294461b90e0c5b3bbfaaf2c8baff4fd3e2bb13 ] sparse reports sound/soc/samsung/rx1950_uda1380.c:131:18: warning: symbol 'gpiod_speaker_power' was not declared. Should it be static? sound/soc/samsung/rx1950_uda1380.c:231:24: warning: symbol 'rx1950_audio' was not declared. Should it be static? Both gpiod_speaker_power and rx1950_audio are only used in rx1950_uda1380.c, so their storage class specifiers should be static. Fixes: 83d74e354200 ("ASoC: samsung: rx1950: turn into platform driver") Signed-off-by: Tom Rix <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 33a44de3fa198164f96f331d7fd998c28acf2d4e Author: Kuninori Morimoto <[email protected]> Date: Wed Jun 22 05:54:06 2022 +0000 ASoC: soc-core.c: fixup snd_soc_of_get_dai_link_cpus() [ Upstream commit 586fb2641371cf7f23a401ab1c79b17e3ec457f4 ] commit 900dedd7e47cc3f ("ASoC: Introduce snd_soc_of_get_dai_link_cpus") adds new snd_soc_of_get_dai_link_cpus(), but it is using "codec" everywhere. It is very strange, and is issue when error case. It should call cpu instead of codec in error case. This patch tidyup it. Fixes: 900dedd7e47cc3f ("ASoC: Introduce snd_soc_of_get_dai_link_cpus") Signed-off-by: Kuninori Morimoto <[email protected]> Reviewed-by: Martin Povišer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7e83af3dd4a3afca8f83ffde518cafd52f45b830 Author: Athira Rajeev <[email protected]> Date: Sun May 22 19:52:56 2022 +0530 powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable [ Upstream commit 890005a7d98f7452cfe86dcfb2aeeb7df01132ce ] commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SPR read also. From point 1, we know that if PMI pending in Paca from inactive cases, that is going to be ignored during replay. Hence if there is pending PMI in Paca, just clear it irrespective of PMC overflown or not. In summary, remove the any_pmc_overflown check entirely in power_pmu_disable. ie If there is a pending PMI in Paca, clear it, since we are in pmu_disable. There could be cases where PMI is pending because of inactive PMC ( which later when replayed also will get ignored ), so WARN_ON could give false warning. Hence removing it. Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") Signed-off-by: Athira Rajeev <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f2ed174e16c30a74e379758e2da8c5e700da1327 Author: Krzysztof Kozlowski <[email protected]> Date: Mon Jun 27 16:19:00 2022 +0200 ASoC: samsung: h1940_uda1380: include proepr GPIO consumer header [ Upstream commit bd10b0dafdcf0ec1677cad70101e1f97b9e28f2e ] h1940_uda1380 uses gpiod*/GPIOD* so it should include GPIO consumer header. Fixes: 9666e27f90b9 ("ASoC: samsung: h1940: turn into platform driver") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 21c09fb18c5a135d639d5b6f05ea5df49676f1f3 Author: Michael Ellerman <[email protected]> Date: Mon Jun 20 09:31:03 2022 +1000 selftests/powerpc: Skip energy_scale_info test on older firmware [ Upstream commit 4228a996b072d36f3baafb4afdc2d2d66d2cbadf ] Older machines don't have the firmware feature that enables the code this test is testing. Skip the test if the sysfs directory doesn't exist. Also use the FAIL_IF() macro to provide more verbose error reporting if an error is encountered. Fixes: 57201d657eb7 ("selftest/powerpc: Add PAPR sysfs attributes sniff test") Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c29335612ff44df979678a38e1f55c62004f421c Author: Hangyu Hua <[email protected]> Date: Fri Jun 24 10:41:20 2022 +0800 rpmsg: Fix possible refcount leak in rpmsg_register_device_override() [ Upstream commit d7bd416d35121c95fe47330e09a5c04adbc5f928 ] rpmsg_register_device_override need to call put_device to free vch when driver_set_override fails. Fix this by adding a put_device() to the error path. Fixes: bb17d110cbf2 ("rpmsg: Fix calling device_lock() on non-initialized device") Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Hangyu Hua <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4df1129d46a9b085a06b1b200955855ea82da209 Author: Alexey Kardashevskiy <[email protected]> Date: Wed Jun 22 15:52:35 2022 +1000 KVM: PPC: Book3s: Fix warning about xics_rm_h_xirr_x [ Upstream commit a784101f77b1bef4b40f4ad68af3f54fcfa5321b ] This fixes "no previous prototype": arch/powerpc/kvm/book3s_hv_rm_xics.c:482:15: warning: no previous prototype for 'xics_rm_h_xirr_x' [-Wmissing-prototypes] Reported by the kernel test robot. Fixes: b22af9041927 ("KVM: PPC: Book3s: Remove real mode interrupt controller hcalls handlers") Signed-off-by: Alexey Kardashevskiy <[email protected]> Reviewed-by: Greg Kurz <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 16da9f84e26f89e58cac194ff19fefd9de27d975 Author: Miaoqian Lin <[email protected]> Date: Thu May 12 08:55:58 2022 +0400 remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init [ Upstream commit 61afafe8b938bc74841cf4b1a73dd08b9d287c5a ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. This function has two paths missing of_node_put(). Fixes: 6e962bfe56b9 ("remoteproc: imx_rproc: add missing of_node_put") Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 55404cf492886019f4ac1e99e1f5c4d839e135ee Author: Chen Zhongjin <[email protected]> Date: Tue May 31 09:28:54 2022 +0800 profiling: fix shift too large makes kernel panic [ Upstream commit 0fe6ee8f123a4dfb529a5aff07536bb481f34043 ] 2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs") limits shift value by [0, BITS_PER_LONG -1], which means [0, 63]. However, syzbot found that the max shift value should be the bit number of (_etext - _stext). If shift is outside of this, the "buffer_bytes" will be zero and will cause kzalloc(0). Then the kernel panics due to dereferencing the returned pointer 16. This can be easily reproduced by passing a large number like 60 to enable profiling and then run readprofile. LOGS: BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 6148067 P4D 6148067 PUD 6142067 PMD 0 PREEMPT SMP CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ #162 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_profile+0x104/0x220 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30 FS: 000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0 Call Trace: <TASK> proc_reg_read+0x56/0x70 vfs_read+0x9a/0x1b0 ksys_read+0xa1/0xe0 ? fpregs_assert_state_consistent+0x1e/0x40 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x4d4b4e RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60 </TASK> Modules linked in: CR2: 0000000000000010 Killed ---[ end trace 0000000000000000 ]--- Check prof_len in profile_init() to prevent it be zero. Link: https://lkml.kernel.org/r/[email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Chen Zhongjin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 36e594072bf25857ac062a542ec9fd0e95b83fe5 Author: Joe Lawrence <[email protected]> Date: Thu Jun 2 16:32:33 2022 -0400 selftests/livepatch: better synchronize test_klp_callbacks_busy [ Upstream commit 55eb9a6c8bf3e2099863118ef53e02d9f44f85a8 ] The test_klp_callbacks_busy module conditionally blocks a future livepatch transition by busy waiting inside its workqueue function, busymod_work_func(). After scheduling this work, a test livepatch is loaded, introducing the transition under test. Both events are marked in the kernel log for later verification, but there is no synchronization to ensure that busymod_work_func() logs its function entry message before subsequent selftest commands log their own messages. This can lead to a rare test failure due to unexpected ordering like: # --- expected # +++ result # @@ -1,7 +1,7 @@ # % modprobe test_klp_callbacks_busy block_transition=Y # test_klp_callbacks_busy: test_klp_callbacks_busy_init # -test_klp_callbacks_busy: busymod_work_func enter # % modprobe test_klp_callbacks_demo # +test_klp_callbacks_busy: busymod_work_func enter # livepatch: enabling patch 'test_klp_callbacks_demo' # livepatch: 'test_klp_callbacks_demo': initializing patching transition # test_klp_callbacks_demo: pre_patch_callback: vmlinux Force the module init function to wait until busymod_work_func() has started (and logged its message), before exiting to the next selftest steps. Fixes: 547840bd5ae5 ("selftests/livepatch: simplify test-klp-callbacks busy target tests") Signed-off-by: Joe Lawrence <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3f83c4cf1b78331c23876977aa7b9151aff2f9e1 Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 12:33:34 2022 +0400 remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init [ Upstream commit fa220c05d282e7479abe08b54e3bdffd06c25e97 ] Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. When breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node. Add missing of_node_put() to avoid refcount leak. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Miaoqian Lin <[email protected]> Acked-by: Suman Anna <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e0a25be0d4cc8e0c578ca7ae31d399983d104ad2 Author: AngeloGioacchino Del Regno <[email protected]> Date: Wed May 25 11:12:01 2022 +0200 rpmsg: mtk_rpmsg: Fix circular locking dependency [ Upstream commit 353d9214682e65c55cdffad8c82139a3321c5f13 ] During execution of the worker that's used to register rpmsg devices we are safely locking the channels mutex but, when creating a new endpoint for such devices, we are registering a IPI on the SCP, which then makes the SCP to trigger an interrupt, lock its own mutex and in turn register more subdevices. This creates a circular locking dependency situation, as the mtk_rpmsg channels_lock will then depend on the SCP IPI lock. [ 15.447736] ====================================================== [ 15.460158] WARNING: possible circular locking dependency detected [ 15.460161] 5.17.0-next-20220324+ #399 Not tainted [ 15.460165] ------------------------------------------------------ [ 15.460166] kworker/0:3/155 is trying to acquire lock: [ 15.460170] ffff5b4d0eaf1308 (&scp->ipi_desc[i].lock){+.+.}-{4:4}, at: scp_ipi_lock+0x34/0x50 [mtk_scp_ipi] [ 15.504958] [] but task is already holding lock: [ 15.504960] ffff5b4d0e8f1918 (&mtk_subdev->channels_lock){+.+.}-{4:4}, at: mtk_register_device_work_function+0x50/0x1cc [mtk_rpmsg] [ 15.504978] [] which lock already depends on the new lock. [ 15.504980] [] the existing dependency chain (in reverse order) is: [ 15.504982] [] -> #1 (&mtk_subdev->channels_lock){+.+.}-{4:4}: [ 15.504990] lock_acquire+0x68/0x84 [ 15.504999] __mutex_lock+0xa4/0x3e0 [ 15.505007] mutex_lock_nested+0x40/0x70 [ 15.505012] mtk_rpmsg_ns_cb+0xe4/0x134 [mtk_rpmsg] [ 15.641684] mtk_rpmsg_ipi_handler+0x38/0x64 [mtk_rpmsg] [ 15.641693] scp_ipi_handler+0xbc/0x180 [mtk_scp] [ 15.663905] mt8192_scp_irq_handler+0x44/0xa4 [mtk_scp] [ 15.663915] scp_irq_handler+0x6c/0xa0 [mtk_scp] [ 15.685779] irq_thread_fn+0x34/0xa0 [ 15.685785] irq_thread+0x18c/0x240 [ 15.685789] kthread+0x104/0x110 [ 15.709579] ret_from_fork+0x10/0x20 [ 15.709586] [] -> #0 (&scp->ipi_desc[i].lock){+.+.}-{4:4}: [ 15.731271] __lock_acquire+0x11e4/0x1910 [ 15.740367] lock_acquire.part.0+0xd8/0x220 [ 15.749813] lock_acquire+0x68/0x84 [ 15.757861] __mutex_lock+0xa4/0x3e0 [ 15.766084] mutex_lock_nested+0x40/0x70 [ 15.775006] scp_ipi_lock+0x34/0x50 [mtk_scp_ipi] [ 15.785503] scp_ipi_register+0x40/0xa4 [mtk_scp_ipi] [ 15.796697] scp_register_ipi+0x1c/0x30 [mtk_scp] [ 15.807194] mtk_rpmsg_create_ept+0xa0/0x108 [mtk_rpmsg] [ 15.818912] rpmsg_create_ept+0x44/0x60 [ 15.827660] cros_ec_rpmsg_probe+0x15c/0x1f0 [ 15.837282] rpmsg_dev_probe+0x128/0x1d0 [ 15.846203] really_probe.part.0+0xa4/0x2a0 [ 15.855649] __driver_probe_device+0xa0/0x150 [ 15.865443] driver_probe_device+0x48/0x150 [ 15.877157] __device_attach_driver+0xc0/0x12c [ 15.889359] bus_for_each_drv+0x80/0xe0 [ 15.900330] __device_attach+0xe4/0x190 [ 15.911303] device_initial_probe+0x1c/0x2c [ 15.922969] bus_probe_device+0xa8/0xb0 [ 15.933927] device_add+0x3a8/0x8a0 [ 15.944193] device_register+0x28/0x40 [ 15.954970] rpmsg_register_device+0x5c/0xa0 [ 15.966782] mtk_register_device_work_function+0x148/0x1cc [mtk_rpmsg] [ 15.983146] process_one_work+0x294/0x664 [ 15.994458] worker_thread+0x7c/0x45c [ 16.005069] kthread+0x104/0x110 [ 16.014789] ret_from_fork+0x10/0x20 [ 16.025201] [] other info that might help us debug this: [ 16.047769] Possible unsafe locking scenario: [ 16.063942] CPU0 CPU1 [ 16.075166] ---- ---- [ 16.086376] lock(&mtk_subdev->channels_lock); [ 16.097592] lock(&scp->ipi_desc[i].lock); [ 16.113188] lock(&mtk_subdev->channels_lock); [ 16.129482] lock(&scp->ipi_desc[i].lock); [ 16.140020] [] *** DEADLOCK *** [ 16.158282] 4 locks held by kworker/0:3/155: [ 16.168978] #0: ffff5b4d00008748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1fc/0x664 [ 16.190017] #1: ffff80000953bdc8 ((work_completion)(&mtk_subdev->register_work)){+.+.}-{0:0}, at: process_one_work+0x1fc/0x664 [ 16.215269] #2: ffff5b4d0e8f1918 (&mtk_subdev->channels_lock){+.+.}-{4:4}, at: mtk_register_device_work_function+0x50/0x1cc [mtk_rpmsg] [ 16.242131] #3: ffff5b4d05964190 (&dev->mutex){....}-{4:4}, at: __device_attach+0x44/0x190 To solve this, simply unlock the channels_lock mutex before calling mtk_rpmsg_register_device() and relock it right after, as safety is still ensured by the locking mechanism that happens right after through SCP. Fixes: 7017996951fd ("rpmsg: add rpmsg support for mt8183 SCP.") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 86f340c39bd052b23d62a54b649687fe27e97c68 Author: Shengjiu Wang <[email protected]> Date: Sat May 21 11:35:05 2022 +0800 rpmsg: char: Add mutex protection for rpmsg_eptdev_open() [ Upstream commit abe13e9a561d6b3e82b21362c0d6dd3ecd8a5b13 ] There is no mutex protection for rpmsg_eptdev_open(), especially for eptdev->ept read and write operation. It may cause issues when multiple instances call rpmsg_eptdev_open() in parallel,the return state may be success or EBUSY. Fixes: 964e8bedd5a1 ("rpmsg: char: Return an error if device already open") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1618c25fb078937f60531d3ad58db5b6df85fa4c Author: Charles Keepax <[email protected]> Date: Tue Jun 14 14:10:22 2022 +0100 ASoC: cs35l45: Add endianness flag in snd_soc_component_driver [ Upstream commit d919630fe77904931277e663c902582ea6f4e4cf ] The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Fixes: 0d463d016000 ("ASoC: cs35l45: Add driver for Cirrus Logic CS35L45 Smart Amp") Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4e2103e82f806e26b4f94fb083447a878d77881c Author: Srinivas Kandagatla <[email protected]> Date: Thu Jun 9 12:19:01 2022 +0100 ASoC: codecs: wcd9335: move gains from SX_TLV to S8_TLV [ Upstream commit 2fbe0953732e06b471cdedbf6f615b84235580d8 ] move all the digital gains form using SX_TLV to S8_TLV, these gains are actually 8 bit gains with 7th signed bit and ranges from -84dB to +40dB rest of the Qualcomm wcd codecs uses these properly. Fixes: 8c4f021d806a ("ASoC: wcd9335: add basic controls") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 24d2d825cf872e21d28fba0ec9fc64874f749ef1 Author: Srinivas Kandagatla <[email protected]> Date: Thu Jun 9 12:19:00 2022 +0100 ASoC: codecs: msm8916-wcd-digital: move gains from SX_TLV to S8_TLV [ Upstream commit 5babb012c847beb6c8c7108fd78f650b7a2c6054 ] move all the digital gains form using SX_TLV to S8_TLV, these gains are actually 8 bit gains with 7th signed bit and ranges from -84dB to +40dB rest of the Qualcomm wcd codecs uses these properly. Fixes: ef8a4757a6db ("ASoC: msm8916-wcd-digital: Add sidetone support") Fixes: 150db8c5afa1 ("ASoC: codecs: Add msm8916-wcd digital codec") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f32d8cb34b941df7ceb29a7c8d447f6add4250bc Author: Peter Ujfalusi <[email protected]> Date: Fri Jun 10 11:35:44 2022 +0300 ASoC: SOF: make ctx_store and ctx_restore as optional [ Upstream commit 03f69725749f453b9a4d454a92805f8eb5f095c2 ] Commit 657774acd00f ("ASoC: SOF: Make sof_suspend/resume IPC agnostic") did not marked ctx_store and ctx_restore as Optional. Fixes: 657774acd00f ("ASoC: SOF: Make sof_suspend/resume IPC agnostic") Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 610a3a8a6ce2579cf635fad5efd2adac2b715261 Author: Ilpo Järvinen <[email protected]> Date: Wed Jun 8 12:54:31 2022 +0300 serial: 8250_dw: Store LSR into lsr_saved_flags in dw8250_tx_wait_empty() [ Upstream commit af14f3007e2dca0d112f10f6717ba43093f74e81 ] Make sure LSR flags are preserved in dw8250_tx_wait_empty(). This function is called from a low-level out function and therefore cannot call serial_lsr_in() as it would lead to infinite recursion. It is borderline if the flags need to be saved here at all since this code relates to writing LCR register which usually implies no important characters should be arriving. Fixes: 914eaf935ec7 ("serial: 8250_dw: Allow TX FIFO to drain before writing to UART_LCR") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3de3d9c97135b6b3a630823ecf8aa329acb8b9f7 Author: Ilpo Järvinen <[email protected]> Date: Wed Jun 8 12:54:30 2022 +0300 serial: 8250_dw: Use serial_lsr_in() in dw8250_handle_irq() [ Upstream commit 197eb5c416ff0e52d152e6ff59b4e759d2f3e10d ] dw8250_handle_irq() reads LSR under a few conditions, convert both to use serial_lsr_in() in order to preserve LSR flags properly across reads. Fixes: 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") Fixes: aa63d786cea2 ("serial: 8250: dw: Add support for DMA flow controlling devices") Cc: Douglas Anderson <[email protected]> Cc: Phil Edworthy <[email protected]> Cc: Miquel Raynal <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4ac5b078741c020cee5ff1da5cef79c05bb09a73 Author: Ilpo Järvinen <[email protected]> Date: Wed Jun 8 12:54:28 2022 +0300 serial: 8250: Get preserved flags using serial_lsr_in() [ Upstream commit 6a4241e8f9b17aa17f55842d6478f280c22d2b44 ] serial8250_handle_irq() assumes it's the first to read LSR register. However, there are 8250 drivers which perform LSR read in their own irq handler prior to calling serial8250_handle_irq(). As not all flags are preserved across LSR reads, use serial_lsr_in() helper to get all the preserved flags. This commit might fix other commits too besides the ones for DW UART mentioned below. It's just not clear to me which of the other devices clear some of the LSR flags on read. AFAIK, nobody has complained about this problem (either against DW or other devices) so it might not have that bad impact in the end. Fixes: 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") Fixes: aa63d786cea2 ("serial: 8250: dw: Add support for DMA flow controlling devices") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 623e3648c57144f614cb098ebdf5ccfc4f0c49d8 Author: Ilpo Järvinen <[email protected]> Date: Wed Jun 8 12:54:27 2022 +0300 serial: 8250: Create serial_lsr_in() [ Upstream commit bdb70c424df1543bc02ee2639aecebd20318c599 ] LSR register readers need to be careful in order to not lose bits that are not preserved across reads. Create a helper that takes care of storing the non-preserved bits into lsr_save_flags. Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 597bcd854aa34a06c53dd79f30b1e151726d3904 Author: Yang Yingliang <[email protected]> Date: Wed May 25 10:12:04 2022 +0800 serial: pic32: fix missing clk_disable_unprepare() on error in pic32_uart_startup() [ Upstream commit 6f3cdf2bf1ba9b70de6c2921a415951a0d59873b ] Fix the missing clk_disable_unprepare() before return from pic32_uart_startup() in the error handling case. Fixes: 157b9394709e ("serial: pic32_uart: Add PIC32 UART driver") Reported-by: Hulk Robot <[email protected]> Reviewed-by: Jiri Slaby <jirislab[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5ec83aa7a9e5bcca80ccd49978916feb4e0ffc07 Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 16:42:41 2022 +0400 ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe [ Upstream commit efe2178d1a32492f99e7f1f2568eea5c88a85729 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix refcount leak in some error paths. Fixes: 0f83f9296d5c ("ASoC: mediatek: Add machine driver for ALC5650 codec") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b32aa0f960706d22cef1a9997096cd32ca2ef3ba Author: Jiasheng Jiang <[email protected]> Date: Tue May 31 17:47:12 2022 +0800 ASoC: codecs: da7210: add check for i2c_add_driver [ Upstream commit 82fa8f581a954ddeec1602bed9f8b4a09d100e6e ] As i2c_add_driver could return error if fails, it should be better to check the return value. However, if the CONFIG_I2C and CONFIG_SPI_MASTER are both true, the return value of i2c_add_driver will be covered by spi_register_driver. Therefore, it is necessary to add check and return error if fails. Fixes: aa0e25caafb7 ("ASoC: da7210: Add support for spi regmap") Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 38dc6faef05f33b4c889be8b7d65878e465c1c4b Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 12:34:15 2022 +0400 ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe [ Upstream commit 7472eb8d7dd12b6b9b1a4f4527719cc9c7f5965f ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: f0ab0bf250da ("ASoC: add mt6797-mt6351 driver and config option") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit db305f1c33d2807900f8b82063442ff88a42e157 Author: Randy Dunlap <[email protected]> Date: Sun Jun 5 09:31:23 2022 -0700 ASoC: max98390: use linux/gpio/consumer.h to fix build [ Upstream commit aa7407f807b250eca7697e5fe9a699bc6c2fab71 ] Change the header file to fix build errors in max98390.c: ../sound/soc/codecs/max98390.c: In function 'max98390_i2c_probe': ../sound/soc/codecs/max98390.c:1076:22: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? [-Werror=implicit-function-declaration] 1076 | reset_gpio = devm_gpiod_get_optional(&i2c->dev, ../sound/soc/codecs/max98390.c:1077:55: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function); did you mean 'GPIOF_INIT_HIGH'? 1077 | "reset", GPIOD_OUT_HIGH); ../sound/soc/codecs/max98390.c:1077:55: note: each undeclared identifier is reported only once for each function it appears in ../sound/soc/codecs/max98390.c:1083:17: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] 1083 | gpiod_set_value_cansleep(reset_gpio, 0); Fixes: 397ff0249606 ("ASoC: max98390: Add reset gpio control") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Steve Lee <[email protected]> Cc: Mark Brown <[email protected]> Cc: Liam Girdwood <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 58567ed2878f70e0ded242cb529fb4a7618ea9f8 Author: Miaoqian Lin <[email protected]> Date: Thu Jun 2 07:41:42 2022 +0400 ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe [ Upstream commit ae4f11c1ed2d67192fdf3d89db719ee439827c11 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix missing of_node_put() in error paths. Fixes: 94319ba10eca ("ASoC: mediatek: Use platform_of_node for machine drivers") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 94caca0bd221ce87d8a5568a4cc7e06ecc35f9c3 Author: Fabio Estevam <[email protected]> Date: Wed May 25 22:05:43 2022 -0300 ASoC: imx-audmux: Silence a clang warning [ Upstream commit 2f4a8171da06609bb6a063630ed546ee3d93dad7 ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: sound/soc/fsl/imx-audmux.c:301:16: warning: cast to smaller integer type 'enum imx_audmux_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: 6a8b8b582db1 ("ASoC: imx-audmux: Remove unused .id_table") Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit daa1da970dc7648262f16b4c355bc7f5f1e7d75b Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 17:06:39 2022 +0400 ASoC: samsung: Fix error handling in aries_audio_probe [ Upstream commit 3e2649c5e8643bea0867bb1dd970fedadb0eb7f3 ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function is missing of_node_put(cpu) in the error path. Fix this by goto out label. of_node_put() will check NULL pointer. Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ca6c9244e6c9827a0b2fe8808c5e7b1ee8ab7104 Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 17:10:43 2022 +0400 ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_probe [ Upstream commit 0a034d93ee929a9ea89f3fa5f1d8492435b9ee6e ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: b6bc07d4360d ("ASoC: cros_ec_codec: support WoV") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Tzung-Bi Shih <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 426ac3e29201ba1a138b7471d6f17df9f7d28925 Author: Tang Bin <[email protected]> Date: Tue May 24 20:31:51 2022 +0800 opp: Fix error check in dev_pm_opp_attach_genpd() [ Upstream commit 4ea9496cbc959eb5c78f3e379199aca9ef4e386b ] dev_pm_domain_attach_by_name() may return NULL in some cases, so IS_ERR() doesn't meet the requirements. Thus fix it. Fixes: 6319aee10e53 ("opp: Attach genpds to devices from within OPP core") Signed-off-by: Tang Bin <[email protected]> [ Viresh: Replace ENODATA with ENODEV ] Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c50dd37d05ca9ad3a5a27c7e43eeb0419d14a87f Author: Nathan Chancellor <[email protected]> Date: Wed Aug 3 09:24:22 2022 -0700 usb: cdns3: Don't use priv_dev uninitialized in cdns3_gadget_ep_enable() [ Upstream commit 78acd4ca433425e6dd4032cfc2156c60e34931f2 ] Clang warns: drivers/usb/cdns3/cdns3-gadget.c:2290:11: error: variable 'priv_dev' is uninitialized when used here [-Werror,-Wuninitialized] dev_dbg(priv_dev->dev, "usbss: invalid parameters\n"); ^~~~~~~~ include/linux/dev_printk.h:155:18: note: expanded from macro 'dev_dbg' dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~ include/linux/dynamic_debug.h:167:7: note: expanded from macro 'dynamic_dev_dbg' dev, fmt, ##__VA_ARGS__) ^~~ include/linux/dynamic_debug.h:152:56: note: expanded from macro '_dynamic_func_call' __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__) ^~~~~~~~~~~ include/linux/dynamic_debug.h:134:15: note: expanded from macro '__dynamic_func_call' func(&id, ##__VA_ARGS__); \ ^~~~~~~~~~~ drivers/usb/cdns3/cdns3-gadget.c:2278:31: note: initialize the variable 'priv_dev' to silence this warning struct cdns3_device *priv_dev; ^ = NULL 1 error generated. The priv_dev assignment was moved below the if statement to avoid potentially dereferencing ep before it was checked but priv_dev is used in the dev_dbg() call. To fix this, move the priv_dev and comp_desc assignments back to their original spot and hoist the ep check above those assignments with a call to pr_debug() instead of dev_dbg(). Fixes: c3ffc9c4ca44 ("usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()") Link: https://github.com/ClangBuiltLinux/linux/issues/1680 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ddd896792e1718cb84c96f3e618270589b6886dc Author: Zhihao Cheng <[email protected]> Date: Fri Jul 15 20:51:52 2022 +0800 jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted [ Upstream commit 4a734f0869f970b8a9b65062ea40b09a5da9dba8 ] Following process will fail assertion 'jh->b_frozen_data == NULL' in jbd2_journal_dirty_metadata(): jbd2_journal_commit_transaction unlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMIT unlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // return false --> jbd2 abort <-- while (commit_transaction->t_buffers) if (is_journal_aborted) jbd2_journal_refile_buffer __jbd2_journal_refile_buffer WRITE_ONCE(jh->b_transaction, jh->b_next_transaction) WRITE_ONCE(jh->b_next_transaction, NULL) __jbd2_journal_file_buffer(jh, BJ_Reserved) J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure ! The reproducer (See detail in [Link]) reports: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1629! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: unlink Tainted: G W 5.19.0-rc6-00115-g4a57a8400075-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Call Trace: <TASK> __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80 After journal aborting, __jbd2_journal_refile_buffer() is executed with holding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()' into the area protected by @jh->b_state_lock. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216251 Fixes: 470decc613ab20 ("[PATCH] jbd2: initial copy of files from jbd") Signed-off-by: Zhihao Cheng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 21197733e629ecc6c50959e408065dc94c0807a4 Author: Li Lingfeng <[email protected]> Date: Fri Jun 17 14:25:15 2022 +0800 ext4: recover csum seed of tmp_inode after migrating to extents [ Upstream commit 07ea7a617d6b278fb7acedb5cbe1a81ce2de7d0c ] When migrating to extents, the checksum seed of temporary inode need to be replaced by inode's, otherwise the inode checksums will be incorrect when swapping the inodes data. However, the temporary inode can not match it's checksum to itself since it has lost it's own checksum seed. mkfs.ext4 -F /dev/sdc mount /dev/sdc /mnt/sdc xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/sdc/testfile chattr -e /mnt/sdc/testfile chattr +e /mnt/sdc/testfile umount /dev/sdc fsck -fn /dev/sdc ======== ... Pass 1: Checking inodes, blocks, and sizes Inode 13 passes checks, but checksum does not match inode. Fix? no ... ======== The fix is simple, save the checksum seed of temporary inode, and recover it after migrating to extents. Fixes: e81c9302a6c3 ("ext4: set csum seed in tmp inode while migrating to extents") Signed-off-by: Li Lingfeng <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d65c93290045e868e104d2aee781ea36d4356666 Author: Zhang Yi <[email protected]> Date: Sat Jun 11 21:04:26 2022 +0800 jbd2: fix outstanding credits assert in jbd2_journal_commit_transaction() [ Upstream commit a89573ce4ad32f19f43ec669771726817e185be0 ] We catch an assert problem in jbd2_journal_commit_transaction() when doing fsstress and request falut injection tests. The problem is happened in a race condition between jbd2_journal_commit_transaction() and ext4_end_io_end(). Firstly, ext4_writepages() writeback dirty pages and start reserved handle, and then the journal was aborted due to some previous metadata IO error, jbd2_journal_abort() start to commit current running transaction, the committing procedure could be raced by ext4_end_io_end() and lead to subtract j_reserved_credits twice from commit_transaction->t_outstanding_credits, finally the t_outstanding_credits is mistakenly smaller than t_nr_buffers and trigger assert. kjournald2 kworker jbd2_journal_commit_transaction() write_unlock(&journal->j_state_lock); atomic_sub(j_reserved_credits, t_outstanding_credits); //sub once jbd2_journal_start_reserved() start_this_handle() //detect aborted journal jbd2_journal_free_reserved() //get running transaction read_lock(&journal->j_state_lock) __jbd2_journal_unreserve_handle() atomic_sub(j_reserved_credits, t_outstanding_credits); //sub again read_unlock(&journal->j_state_lock); journal->j_running_transaction = NULL; J_ASSERT(t_nr_buffers <= t_outstanding_credits) //bomb!!! Fix this issue by using journal->j_state_lock to protect the subtraction in jbd2_journal_commit_transaction(). Fixes: 96f1e0974575 ("jbd2: avoid long hold times of j_state_lock while committing a transaction") Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 38fb0d7f39a1e5fcf539f09463028f4f76ff3d50 Author: Keith Busch <[email protected]> Date: Tue Jul 12 08:32:54 2022 -0700 block: ensure iov_iter advances for added pages [ Upstream commit 325347d965e7ccf5424a05398807a6d801846612 ] There are cases where a bio may not accept additional pages, and the iov needs to advance to the last data length that was accepted. The zone append used to handle this correctly, but was inadvertently broken when the setup was made common with the normal r/w case. Fixes: 576ed9135489c ("block: use bio_add_page in bio_iov_iter_get_pages") Fixes: c58c0074c54c2 ("block/bio: remove duplicate append pages code") Signed-off-by: Keith Busch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 70edccb32b60b8ff2b4ea5126c2ae17e642fed37 Author: Keith Busch <[email protected]> Date: Fri Jun 10 12:58:21 2022 -0700 block/bio: remove duplicate append pages code [ Upstream commit c58c0074c54c2e2bb3bb0d5a4d8896bb660cc8bc ] The getting pages setup for zone append and normal IO are identical. Use common code for each. Signed-off-by: Keith Busch <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e731baf1af61ff28f061158e2b44ced28f7ebf49 Author: Christoph Hellwig <[email protected]> Date: Thu Jul 21 07:56:35 2022 +0200 nvme: catch -ENODEV from nvme_revalidate_zones again [ Upstream commit e06b425bc835ead08b9fd935bf5e47eef473e7a0 ] nvme_revalidate_zones can also return -ENODEV if e.g. zone sizes aren't constant or not a power of two. In that case we should jump to marking the gendisk hidden and only support pass through. Fixes: 602e57c9799c ("nvme: also mark passthrough-only namespaces ready in nvme_update_ns_info") Reported-by: Joel Granados <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Joel Granados <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 32bf5d3c61f4de402f1b97bca5dfaf8d6c11d10f Author: Nick Bowler <[email protected]> Date: Wed Jul 20 23:57:35 2022 -0400 nvme: define compat_ioctl again to unbreak 32-bit userspace. [ Upstream commit a25d4261582cf00dad884c194d21084836663d3d ] Commit 89b3d6e60550 ("nvme: simplify the compat ioctl handling") removed the initialization of compat_ioctl from the nvme block_device_operations structures. Presumably the expectation was that 32-bit ioctls would be directed through the regular handler but this is not the case: failing to assign .compat_ioctl actually means that the compat case is disabled entirely, and any attempt to submit nvme ioctls from 32-bit userspace fails outright with -ENOTTY. For example: % smartctl -x /dev/nvme0n1 [...] Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for device The blkdev_compat_ptr_ioctl helper can be used to direct compat calls through the main ioctl handler and makes things work again. Fixes: 89b3d6e60550 ("nvme: simplify the compat ioctl handling") Signed-off-by: Nick Bowler <[email protected]> Reviewed-by: Guixin Liu <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4e8fee340f1f1285d9673576a852c07fc48c030a Author: Bean Huo <[email protected]> Date: Fri Jul 15 23:27:21 2022 +0200 nvme: use command_id instead of req->tag in trace_nvme_complete_rq() [ Upstream commit 679c54f2de672b7d79d02f8c4ad483ff6dd8ce2e ] Use command_id instead of req->tag in trace_nvme_complete_rq(), because of commit e7006de6c238 ("nvme: code command_id with a genctr for use authentication after release"), cmd->common.command_id is set to ((genctl & 0xf)< 12 | req->tag), no longer req->tag, which makes cid in trace_nvme_complete_rq and trace_nvme_setup_cmd are not the same. Fixes: e7006de6c238 ("nvme: code command_id with a genctr for use authentication after release") Signed-off-by: Bean Huo <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ebe02fcbbe23ee78e4da480b6f924ae7beb98488 Author: Christoph Hellwig <[email protected]> Date: Sun Jun 19 08:05:48 2022 +0200 mtip32xx: fix device removal [ Upstream commit e8b58ef09e84c15cf782b01cfc73cc5b1180d519 ] Use the proper helper to mark a surpise removal, remove the gendisk as soon as possible when removing the device and implement the ->free_disk callback to ensure the private data is alive as long as the gendisk has references. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9502680c58d3587cf8c4ea9b95d1fdf95c6e6452 Author: Yu Kuai <[email protected]> Date: Sat Jul 23 16:24:27 2022 +0800 nbd: add missing definition of pr_fmt [ Upstream commit bc9da6dd0630efd81b5c72ff6fa0169aa029a73f ] commit 1243172d5894 ("nbd: use pr_err to output error message") tries to define pr_fmt and use short pr_err() to output error message, however, the definition is missed. This patch also remove existing "nbd:" inside pr_err(). Fixes: 1243172d5894 ("nbd: use pr_err to output error message") Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Josef Bacik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e11ad527774c1190c1bb58f908e8f7ede55cb9f4 Author: Dan Carpenter <[email protected]> Date: Fri Jul 15 11:12:14 2022 +0300 null_blk: fix ida error handling in null_add_dev() [ Upstream commit ee452a8d984f94fa8e894f003a52e776e4572881 ] There needs to be some error checking if ida_simple_get() fails. Also call ida_free() if there are errors later. Fixes: 94bc02e30fb8 ("nullb: use ida to manage index") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bd629539b205f8233d28102bd2aea8df7672a0c5 Author: Md Haris Iqbal <[email protected]> Date: Thu Jul 7 16:31:21 2022 +0200 block/rnbd-srv: Set keep_id to true after mutex_trylock [ Upstream commit 4bc14f3101364877dd59085f39e068a2a7ec9f2d ] After setting keep_id if the mutex trylock fails, the keep_id stays set for the rest of the sess_dev lifetime. Therefore, set keep_id to true after mutex_trylock succeeds, so that a failure of trylock does'nt touch keep_id. Fixes: b168e1d85cf3 ("block/rnbd-srv: Prevent a deadlock generated by accessing sysfs in parallel") Cc: [email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Signed-off-by: Jack Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f05b7cf02123aaf99db78abfe638efefdbe15555 Author: Zhu Yanjun <[email protected]> Date: Sun Jul 31 02:36:21 2022 -0400 RDMA/rxe: Fix error unwind in rxe_create_qp() [ Upstream commit fd5382c5805c4bcb50fd25b7246247d3f7114733 ] In the function rxe_create_qp(), rxe_qp_from_init() is called to initialize qp, internally things like the spin locks are not setup until rxe_qp_init_req(). If an error occures before this point then the unwind will call rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task() which will oops when trying to access the uninitialized spinlock. Move the spinlock initializations earlier before any failures. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Signed-off-by: Zhu Yanjun <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5fd7eefeee9b4f6d96aa749112037f5ebc2b640b Author: Maor Gottlieb <[email protected]> Date: Sun Jul 31 11:29:08 2022 +0300 RDMA/mlx5: Add missing check for return value in get namespace flow [ Upstream commit c9776457bd5eaad4ce4ecb17af8d8f3cc6957c0b ] Add missing check for return value when calling to mlx5_ib_ft_type_to_namespace, even though it can't really fail in this specific call. Fixes: 52438be44112 ("RDMA/mlx5: Allow inserting a steering rule to the FDB") Link: https://lore.kernel.org/r/[email protected]vidia.com Reviewed-by: Itay Aveksis <[email protected]> Signed-off-by: Maor Gottlieb <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d6d4b5f13b88a3755f81bb24009604b14fc6c6dd Author: Xu Qiang <[email protected]> Date: Mon Aug 1 12:05:06 2022 +0000 of/fdt: declared return type does not match actual return type [ Upstream commit 7913145afa51bbed9eaf8e5b4ee55fa9884a71e5 ] The commit 649cab56de8e (“of: properly check for error returned by fdt_get_name()”) changed the return value type from bool to int, but forgot to change the return value simultaneously. populate_node was only called in unflatten_dt_nodes, and returns with values greater than or equal to 0 were discarded without further processing. Considering that return 0 usually indicates success, return 0 instead of return true. Fixes: 649cab56de8e (“of: properly check for error returned by fdt_get_name()”) Signed-off-by: Xu Qiang <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4ef616730a967138fd0d784eab1d55437207773f Author: Andrei Vagin <[email protected]> Date: Fri Jul 22 16:02:40 2022 -0700 selftests: kvm: set rax before vmcall [ Upstream commit 281106f938d3daaea6f8b6723a8217a2a1ef6936 ] kvm_hypercall has to place the hypercall number in rax. Trace events show that kvm_pv_test doesn't work properly: kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 With this change, it starts working as expected: kvm_pv_test-54285: kvm_hypercall: nr 0x5 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-54285: kvm_hypercall: nr 0xa a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-54285: kvm_hypercall: nr 0xb a0 0x0 a1 0x0 a2 0x0 a3 0x0 Signed-off-by: Andrei Vagin <[email protected]> Message-Id: <[email protected]> Fixes: ac4a4d6de22e ("selftests: kvm: test enforcement of paravirtual cpuid features") Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 86dc66ace193aa9489b12aedc3db3245bb605e9a Author: Juergen Gross <[email protected]> Date: Wed Jun 22 08:38:38 2022 +0200 xen: don't require virtio with grants for non-PV guests [ Upstream commit 251e90e7e346a23742b90e2c4db19d322e071d99 ] Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using Xen grant mappings") introduced a new requirement for using virtio devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM feature. This is an undue requirement for non-PV guests, as those can be operated with existing backends without any problem, as long as those backends are running in dom0. Per default allow virtio devices without grant support for non-PV guests. On Arm require VIRTIO_F_ACCESS_PLATFORM for devices having been listed in the device tree to use grants. Add a new config item to always force use of grants for virtio. Fixes: fa1f57421e0b ("xen/virtio: Enable restricted memory access using Xen grant mappings") Reported-by: Viresh Kumar <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Oleksandr Tyshchenko <[email protected]> Tested-by: Oleksandr Tyshchenko <oleksandr_tyshchen[email protected]> # Arm64 guest using Xen Reviewed-by: Stefano Stabellini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e5f57aaccbd3e17e9c0c2080cc4193221230868b Author: Juergen Gross <[email protected]> Date: Wed Jun 22 08:38:36 2022 +0200 virtio: replace restricted mem access flag with callback [ Upstream commit a603002eea8213eec5211be5a85db8340aea06d0 ] Instead of having a global flag to require restricted memory access for all virtio devices, introduce a callback which can select that requirement on a per-device basis. For convenience add a common function returning always true, which can be used for use cases like SEV. Per default use a callback always returning false. As the callback needs to be set in early init code already, add a virtio anchor which is builtin in case virtio is enabled. Signed-off-by: Juergen Gross <[email protected]> Tested-by: Oleksandr Tyshchenko <[email protected]> # Arm64 guest using Xen Reviewed-by: Stefano Stabellini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b737d48db8fe1887a77d61998a8219583183a2ef Author: Andreas Schwab <[email protected]> Date: Mon Jul 25 17:12:18 2022 +0200 rtla: Fix double free [ Upstream commit 4f753c3be52c1d930afc0fe3169baa605dbaf611 ] Avoid double free by making trace_instance_destroy indempotent. When trace_instance_init fails, it calls trace_instance_destroy, but its only caller osnoise_destroy_tool calls it again. Link: https://lkml.kernel.org/r/[email protected] Fixes: 0605bf009f18 ("rtla: Add osnoise tool") Signed-off-by: Andreas Schwab <[email protected]> Acked-by: Daniel Bristot de Oliveira <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4927a4161caa7417e8bce8118854b42d1b040c65 Author: Daniel Bristot de Oliveira <[email protected]> Date: Wed Jul 13 23:32:19 2022 +0200 rtla: Fix Makefile when called from -C tools/ [ Upstream commit c7d8a598c5b1e21a0957f5dec2ef4139d2d1a23a ] Sedat Dilek reported an error on rtla Makefile when running: $ make -C tools/ clean [...] make[2]: Entering directory '/home/dileks/src/linux-kernel/git/tools/tracing/rtla' [...] '/home/dileks/src/linux-kernel/git/Documentation/tools/rtla' /bin/sh: 1: test: rtla-make[2]:: unexpected operator <------ The problem rm: cannot remove '/home/dileks/src/linux-kernel/git': Is a directory make[2]: *** [Makefile:120: clean] Error 1 make[2]: Leaving directory This occurred because the rtla calls kernel's Makefile to get the version in silence mode, e.g., $ make -sC ../../.. kernelversion 5.19.0-rc4 But the -s is being ignored when rtla's makefile is called indirectly, so the output looks like this: $ make -C ../../.. kernelversion make: Entering directory '/root/linux' 5.19.0-rc4 make: Leaving directory '/root/linux' Using 'grep -v make' avoids this problem, e.g., $ make -C ../../.. kernelversion | grep -v make 5.19.0-rc4 Thus, add | grep -v make. Link: https://lkml.kernel.org/r/[email protected]kernel.org Fixes: 8619e32825fd ("rtla: Follow kernel version") Reported-by: Sedat Dilek <[email protected]> Tested-by: Sedat Dilek <[email protected]> Signed-off-by: Daniel Bristot de Oliveira <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c6bc611f371d5a7800dfe21a609dd184f333d237 Author: Dan Carpenter <[email protected]> Date: Tue Jul 19 12:04:14 2022 +0300 selftest/vm: uninitialized variable in main() [ Upstream commit 360b420dbded8ad5b70a41de98e77354dd9e7d36 ] Initialize "length" to zero by default. Link: https://lkml.kernel.org/r/[email protected] Fixes: ff712a627f72 ("selftests/vm: cleanup hugetlb file after mremap test") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Mina Almasry <[email protected]> Reviewed-by: Muchun Song <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Shuah Khan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8d958b6356320788549ff2bdaebc2fd89cd76217 Author: Dan Carpenter <[email protected]> Date: Tue Jul 19 12:42:48 2022 +0300 tools/testing/selftests/vm/hugetlb-madvise.c: silence uninitialized variable warning [ Upstream commit 3d5367a0426da61c7cb616cc85b6239467e261dd ] This code just reads from memory without caring about the data itself. However static checkers complain that "tmp" is never properly initialized. Initialize it to zero and change the name to "dummy" to show that we don't care about the value stored in it. Link: https://lkml.kernel.org/r/[email protected] Fixes: c4b6cb884011 ("selftests/vm: add hugetlb madvise MADV_DONTNEED MADV_REMOVE test") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Souptick Joarder (HPE) <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Cc: Shuah Khan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit aa0d3fb4e8533a9888c65ff8c71094d8a595ae84 Author: Adam Sindelar <[email protected]> Date: Mon Jul 4 19:33:51 2022 +0200 selftests/vm: fix errno handling in mrelease_test [ Upstream commit 3b8e7f5c42d1aa44f71fd219717c80e34101361e ] mrelease_test should return KSFT_SKIP when process_mrelease is not defined, but due to a perror call consuming the errno, it returns KSFT_FAIL. This patch decides the exit code before calling perror. [[email protected]: fix remaining instances of errno mishandling] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 33776141b812 ("selftests: vm: add process_mrelease tests") Signed-off-by: Adam Sindelar <[email protected]> Reviewed-by: David Vernet <[email protected]> Reviewed-by: Suren Baghdasaryan <[email protected]> Cc: Shuah Khan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 28e414bd9d16cd3a8099346764d2395c0efb3e99 Author: Miaohe Lin <[email protected]> Date: Sat Jun 18 16:20:27 2022 +0800 mm/mmap.c: fix missing call to vm_unacct_memory in mmap_region [ Upstream commit 7f82f922319ede486540e8746769865b9508d2c2 ] Since the beginning, charged is set to 0 to avoid calling vm_unacct_memory twice because vm_unacct_memory will be called by above unmap_region. But since commit 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from the unmap_vmas() interfaces"), unmap_region doesn't call vm_unacct_memory anymore. So charged shouldn't be set to 0 now otherwise the calling to paired vm_unacct_memory will be missed and leads to imbalanced account. Link: https://lkml.kernel.org/r/[email protected]om Fixes: 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from the unmap_vmas() interfaces") Signed-off-by: Miaohe Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1ec3f76a436d750fd5023caec5da0494fc2870d2 Author: Liam R. Howlett <[email protected]> Date: Mon Jun 20 21:09:09 2022 -0400 android: binder: stop saving a pointer to the VMA [ Upstream commit a43cfc87caaf46710c8027a8c23b8a55f1078f19 ] Do not record a pointer to a VMA outside of the mmap_lock for later use. This is unsafe and there are a number of failure paths *after* the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, change the binder_alloc struct to record the start address of the VMA and use vma_lookup() to get the vma when needed. Add lockdep mmap_lock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smp_wmb()/smp_rmb() was not necessary. [[email protected]: fix drivers/android/binder_alloc_selftest.c] Link: https://lkml.kernel.org/r/[email protected] Fixes: da1b9564e85b ("android: binder: fix the race mmap and alloc_new_buf_locked") Reported-by: [email protected] Signed-off-by: Liam R. Howlett <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Christian Brauner (Microsoft) <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Hridya Valsaraju <[email protected]> Cc: Joel Fernandes <[email protected]> Cc: Martijn Coenen <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 388326bb1c32fcd09371c1d494af71471ef3a04b Author: Bart Van Assche <[email protected]> Date: Wed Jul 27 12:34:15 2022 -0700 RDMA/srpt: Fix a use-after-free [ Upstream commit b5605148e6ce36bb21020d49010b617693933128 ] Change the LIO port members inside struct srpt_port from regular members into pointers. Allocate the LIO port data structures from inside srpt_make_tport() and free these from inside srpt_make_tport(). Keep struct srpt_device as long as either an RDMA port or a LIO target port is associated with it. This patch decouples the lifetime of struct srpt_port (controlled by the RDMA core) and struct srpt_port_id (controlled by LIO). This patch fixes the following KASAN complaint: BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt] Read of size 8 at addr ffff888141cc34b8 by task check/5093 Call Trace: <TASK> show_stack+0x4e/0x53 dump_stack_lvl+0x51/0x66 print_address_description.constprop.0.cold+0xea/0x41e print_report.cold+0x90/0x205 kasan_report+0xb9/0xf0 __asan_load8+0x69/0x90 srpt_enable_tpg+0x31/0x70 [ib_srpt] target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod] configfs_write_iter+0x18b/0x210 new_sync_write+0x1f2/0x2f0 vfs_write+0x3e3/0x540 ksys_write+0xbb/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> Link: https://lore.kernel.org/r/[email protected] Reported-by: Li Zhijian <[email protected]> Tested-by: Li Zhijian <[email protected]> Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7c448f82908e499281076c729a2467aadccdd310 Author: Bart Van Assche <[email protected]> Date: Wed Jul 27 12:34:14 2022 -0700 RDMA/srpt: Introduce a reference count in struct srpt_device [ Upstream commit aa7dfbb41b5a60ab90e244d6f586b8cb5c791c3e ] This will be used to keep struct srpt_device around as long as either the RDMA port exists or a LIO target port is associated with the struct srpt_device. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5267f0490620479ab68067d70ba7f412e88bedec Author: Bart Van Assche <[email protected]> Date: Wed Jul 27 12:34:13 2022 -0700 RDMA/srpt: Duplicate port name members [ Upstream commit b03b1ae2a3125d4475452e4f19f5d3a6e910ff6e ] Prepare for decoupling the lifetimes of struct srpt_port and struct srpt_port_id by duplicating the port name into struct srpt_port. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 23939304042315fcb3342ace31afbc72df1a8e54 Author: Dan Carpenter <[email protected]> Date: Wed Jul 20 21:23:38 2022 +0300 platform/olpc: Fix uninitialized data in debugfs write [ Upstream commit 40ec787e1adf302c11668d4cc69838f4d584187d ] The call to: size = simple_write_to_buffer(cmdbuf, sizeof(cmdbuf), ppos, buf, size); will succeed if at least one byte is written to the "cmdbuf" buffer. The "*ppos" value controls which byte is written. Another problem is that this code does not check for errors so it's possible for the entire buffer to be uninitialized. Inintialize the struct to zero to prevent reading uninitialized stack data. Debugfs is normally only writable by root so the impact of this bug is very minimal. Fixes: 6cca83d498bd ("Platform: OLPC: move debugfs support from x86 EC driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 95ab0d267eeeb420b478b03aa06617ecc151e9da Author: Vadim Pasternak <[email protected]> Date: Tue Jul 19 18:35:40 2022 +0300 platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity [ Upstream commit b4b830a34d8046633231b7fe87f6f2cb6240dc9f ] Fix error flow: - Clean-up client object in case of probing failure. - Prevent running remove routine in case of probing failure. Probing and removing are invoked by hotplug events raised upon line card insertion and removing. If probing procedure failed all data is cleared and there is nothing to do in remove routine. Fixes: 62f9529b8d5c ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices") Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 341dd8c53ea4bbb859e28ed595852dd730626c8d Author: Hans de Goede <[email protected]om> Date: Thu Jul 28 20:06:35 2022 +0200 platform/x86: pmc_atom: Match all Lex BayTrail boards with critclk_systems DMI table [ Upstream commit c9d959fc32a5f9312282817052d8986614f2dc08 ] The critclk_systems[] DMI match table already contains 2 Lex BayTrail boards and patches were just submitted to add 3 more entries for the following models: 3I380NX, 3I380A, 3I380CW. Looking at: https://www.lex.com.tw/products/embedded-ipc-board/ we can see that Lex BayTrail makes many embedded boards with multiple ethernet boards and none of their products are battery powered so we don't need to worry (too much) about power consumption when suspended. Add a new DMI match which simply matches all Lex BayTrail boards and drop the 2 existing board specific quirks. Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Reported-by: Michael Schöne <[email protected]> Reported-by: Paul Spooren <[email protected]> Reported-by: Matwey V. Kornilov <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 385de404e2b1e957fe158aec800011ded0391b46 Author: Dan Carpenter <[email protected]> Date: Mon Jul 18 16:17:17 2022 +0300 tools/power/x86/intel-speed-select: Fix off by one check [ Upstream commit d9f74d98bbec978edbf860f729b531281ba0d8ff ] Change > MAX_DIE_PER_PACKAGE to >= MAX_DIE_PER_PACKAGE to prevent accessing one element beyond the end of the array. Fixes: 7fd786dfbd2c ("tools/power/x86/intel-speed-select: OOB daemon mode") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a2bcf77490131faef1cb9d6a54ae97b61d4715f4 Author: Sean Christopherson <[email protected]> Date: Tue Jun 7 21:36:00 2022 +0000 KVM: nVMX: Set UMIP bit CR4_FIXED1 MSR when emulating UMIP [ Upstream commit a910b5ab6b250a88fff1866bf708642d83317466 ] Make UMIP an "allowed-1" bit CR4_FIXED1 MSR when KVM is emulating UMIP. KVM emulates UMIP for both L1 and L2, and so should enumerate that L2 is allowed to have CR4.UMIP=1. Not setting the bit doesn't immediately break nVMX, as KVM does set/clear the bit in CR4_FIXED1 in response to a guest CPUID update, i.e. KVM will correctly (dis)allow nested VM-Entry based on whether or not UMIP is exposed to L1. That said, KVM should enumerate the bit as being allowed from time zero, e.g. userspace will see the wrong value if the MSR is read before CPUID is written. Fixes: 0367f205a3b7 ("KVM: vmx: add support for emulating UMIP") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6ae6abe240306f878557d6eadd950a2e2561f59f Author: Peter Suti <[email protected]> Date: Wed Jul 27 09:35:50 2022 +0200 staging: fbtft: core: set smem_len before fb_deferred_io_init call [ Upstream commit 81e878887ff82a7dd42f22951391069a5d520627 ] The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before initializing info->fix.smem_len. It is set to zero by the framebuffer_alloc() function. It will trigger a WARN_ON() at the start of fb_deferred_io_init() and the function will not do anything. Fixes: 856082f021a2 ("fbdev: defio: fix the pagelist corruption") Signed-off-by: Peter Suti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 56a7f5974f25e2c9bd644a807e11f9e6a087341c Author: Patrice Chotard <[email protected]> Date: Wed Jun 29 15:30:13 2022 +0200 mtd: spi-nor: fix spi_nor_spimem_setup_op() call in spi_nor_erase_{sector,chip}() [ Upstream commit f8cd9f632f4415b1e8838bdca8ab42cfb37a6584 ] For erase operations, reg_proto must be used as indicated in struct spi_nor description in spi-nor.h. This issue was found when DT property spi-tx-bus-width is set to 4. In this case the spi_mem_op->addr.buswidth is set to 4 for erase command which is not correct. Tested on stm32mp157c-ev1 board with mx66l51235f spi-nor. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Patrice Chotard <[email protected]> [ta: use nor->reg_proto in spi_nor_controller_ops_erase()] Signed-off-by: Tudor Ambarus <[email protected]> Tested-by: Alexander Sverdlin <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit eb82c0382285ee17a9966aaab27b8becb08eb1ac Author: Andrey Strachuk <[email protected]> Date: Mon Jul 18 19:00:52 2022 +0300 usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable() [ Upstream commit c3ffc9c4ca44bfe9562166793d133e1fb0630ea6 ] If 'ep' is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer and its dereference with priv_ep->cdns3_dev may cause panic. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Acked-by: Peter Chen <[email protected]> Signed-off-by: Andrey Strachuk <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 371a8af4f26e06b4d51d893b4436f520b48d07fd Author: Alexey Sheplyakov <[email protected]> Date: Fri Jul 22 18:17:00 2022 +0400 usb: xhci_plat_remove: avoid NULL dereference [ Upstream commit d7de14d74d6551f0d097430f9893ce82ad17e5b8 ] Since commit 4736ebd7fcaff1eb8481c140ba494962847d6e0a ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") xhci->shared_hcd can be NULL, which causes the following Oops on reboot: [ 710.124450] systemd-shutdown[1]: Rebooting. [ 710.298861] xhci-hcd xhci-hcd.2.auto: remove, state 4 [ 710.304217] usb usb3: USB disconnect, device number 1 [ 710.317441] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered [ 710.323280] xhci-hcd xhci-hcd.2.auto: remove, state 1 [ 710.328401] usb usb2: USB disconnect, device number 1 [ 710.333515] usb 2-3: USB disconnect, device number 2 [ 710.467649] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered [ 710.475450] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b8 [ 710.484425] Mem abort info: [ 710.487265] ESR = 0x0000000096000004 [ 710.491060] EC = 0x25: DABT (current EL), IL = 32 bits [ 710.496427] SET = 0, FnV = 0 [ 710.499525] EA = 0, S1PTW = 0 [ 710.502716] FSC = 0x04: level 0 translation fault [ 710.507648] Data abort info: [ 710.510577] ISV = 0, ISS = 0x00000004 [ 710.514462] CM = 0, WnR = 0 [ 710.517480] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b0050000 [ 710.523976] [00000000000003b8] pgd=0000000000000000, p4d=0000000000000000 [ 710.530961] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 710.536551] Modules linked in: rfkill input_leds snd_soc_simple_card snd_soc_simple_card_utils snd_soc_nau8822 designware_i2s snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine arm_ccn panfrost ac97_bus gpu_sched snd_pcm at24 fuse configfs sdhci_of_dwcmshc sdhci_pltfm sdhci nvme led_class mmc_core nvme_core bt1_pvt polynomial tp_serio snd_seq_midi snd_seq_midi_event snd_seq snd_timer snd_rawmidi snd_seq_device snd soundcore efivarfs ipv6 [ 710.575286] CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc7-00043-gfd8619f4fd54 #1 [ 710.583822] Hardware name: T-Platforms TF307-MB/BM1BM1-A, BIOS 5.6 07/06/2022 [ 710.590972] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 710.597949] pc : usb_remove_hcd+0x34/0x1e4 [ 710.602067] lr : xhci_plat_remove+0x74/0x140 [ 710.606351] sp : ffff800009f3b7c0 [ 710.609674] x29: ffff800009f3b7c0 x28: ffff000800960040 x27: 0000000000000000 [ 710.616833] x26: ffff800008dc22a0 x25: 0000000000000000 x24: 0000000000000000 [ 710.623992] x23: 0000000000000000 x22: ffff000805465810 x21: ffff000805465800 [ 710.631149] x20: ffff000800f80000 x19: 0000000000000000 x18: ffffffffffffffff [ 710.638307] x17: ffff000805096000 x16: ffff00080633b800 x15: ffff000806537a1c [ 710.645465] x14: 0000000000000001 x13: 0000000000000000 x12: ffff00080378d6f0 [ 710.652621] x11: ffff00080041a900 x10: ffff800009b204e8 x9 : ffff8000088abaa4 [ 710.659779] x8 : ffff000800960040 x7 : ffff800009409000 x6 : 0000000000000001 [ 710.666936] x5 : ffff800009241000 x4 : ffff800009241440 x3 : 0000000000000000 [ 710.674094] x2 : ffff000800960040 x1 : ffff000800960040 x0 : 0000000000000000 [ 710.681251] Call trace: [ 710.683704] usb_remove_hcd+0x34/0x1e4 [ 710.687467] xhci_plat_remove+0x74/0x140 [ 710.691400] platform_remove+0x34/0x70 [ 710.695165] device_remove+0x54/0x90 [ 710.698753] device_release_driver_internal+0x200/0x270 [ 710.703992] device_release_driver+0x24/0x30 [ 710.708273] bus_remove_device+0xe0/0x16c [ 710.712293] device_del+0x178/0x390 [ 710.715797] platform_device_del.part.0+0x24/0x90 [ 710.720514] platform_device_unregister+0x30/0x50 [ 710.725232] dwc3_host_exit+0x20/0x30 [ 710.728907] dwc3_remove+0x174/0x1b0 [ 710.732494] platform_remove+0x34/0x70 [ 710.736254] device_remove+0x54/0x90 [ 710.739840] device_release_driver_internal+0x200/0x270 [ 710.745078] device_release_driver+0x24/0x30 [ 710.749359] bus_remove_device+0xe0/0x16c [ 710.753380] device_del+0x178/0x390 [ 710.756881] platform_device_del.part.0+0x24/0x90 [ 710.761598] platform_device_unregister+0x30/0x50 [ 710.766314] of_platform_device_destroy+0xe8/0x100 [ 710.771119] device_for_each_child_reverse+0x70/0xc0 [ 710.776099] of_platform_depopulate+0x48/0x90 [ 710.780468] __dwc3_of_simple_teardown+0x28/0xe0 [ 710.785099] dwc3_of_simple_shutdown+0x20/0x30 [ 710.789555] platform_shutdown+0x30/0x40 [ 710.793490] device_shutdown+0x138/0x32c [ 710.797425] __do_sys_reboot+0x1c4/0x2ac [ 710.801362] __arm64_sys_reboot+0x30/0x40 [ 710.805383] invoke_syscall+0x50/0x120 [ 710.809146] el0_svc_common.constprop.0+0x68/0x124 [ 710.813950] do_el0_svc+0x3c/0xcc [ 710.817275] el0_svc+0x60/0x12c [ 710.820428] el0t_64_sync_handler+0xc0/0x13c [ 710.824710] el0t_64_sync+0x18c/0x190 [ 710.828386] Code: a9025bf5 f942c420 f9001fe0 d2800000 (b943ba62) [ 710.834498] ---[ end trace 0000000000000000 ]--- [ 710.875958] pstore: crypto_comp_compress failed, ret = -22! [ 710.895047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 710.902757] Kernel Offset: disabled [ 710.906255] CPU features: 0x800,00004811,00001082 [ 710.910971] Memory Limit: none [ 710.927474] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- To avoid the problem check for NULL in usb_remove_hcd. Fixes: 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") Signed-off-by: Alexey Sheplyakov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d293cf992a10a77d915a83d0784ba037a9b341cd Author: Johan Hovold <[email protected]> Date: Mon Jul 25 10:44:57 2022 +0200 USB: serial: fix tty-port initialized comments [ Upstream commit 688ee1d1785c1359f9040f615dd8e6054962bce2 ] Fix up the tty-port initialized comments which got truncated and obfuscated when replacing the old ASYNCB_INITIALIZED flag. Fixes: d41861ca19c9 ("tty: Replace ASYNC_INITIALIZED bit and update atomically") Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e2e80c37e00de388dfde42e7a9d5d8709ef1619a Author: Basavaraj Natikar <[email protected]> Date: Sat Jul 23 11:40:33 2022 +0530 HID: amd_sfh: Handle condition of "no sensors" [ Upstream commit 5d4d0f15657535f6a122ab26d47230b5c2b944af ] Add a check for num_hid_devices to handle special case the situation of "no sensors". Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Basavaraj Natikar <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a0dfb4e7b28a66571194d748db580cba25978fd3 Author: Vidya Sagar <[email protected]> Date: Thu Jul 21 19:50:50 2022 +0530 PCI: tegra194: Fix link up retry sequence [ Upstream commit e05fd6ae77c3e2cc0dba283005d24b6d56d2b1fa ] Add the missing DLF capability offset while clearing DL_FEATURE_EXCHANGE_EN bit during link up retry. Link: https://lore.kernel.org/r/[email protected] Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ebe2d576ce0294870a3f036e37204336e7b69a4a Author: Vidya Sagar <[email protected]> Date: Thu Jul 21 19:50:46 2022 +0530 PCI: tegra194: Fix Root Port interrupt handling [ Upstream commit 6646e99bcec627e866bc84365af37942c72b4b76 ] As part of Root Port interrupt handling, level-0 register is read first and based on the bits set in that, corresponding level-1 registers are read for further interrupt processing. Since both these values are currently read into the same 'val' variable, checking level-0 bits the second time around is happening on the 'val' variable value of level-1 register contents instead of freshly reading the level-0 value again. Fix by using different variables to store level-0 and level-1 registers contents. Link: https://lore.kernel.org/r/[email protected] Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 50bf45181c1d565d289fca490001f83d813123bb Author: Bob Pearson <[email protected]> Date: Thu Jun 30 14:04:22 2022 -0500 RDMA/rxe: Fix rnr retry behavior [ Upstream commit 445fd4f4fb76d513de6b05b08b3a4d0bb980fc80 ] Currently the completer tasklet when retransmit timer or the rnr timer fires the same flag (qp->req.need_retry) is set so that if either timer fires it will attempt to perform a retry flow on the send queue. This has the effect of responding to an RNR NAK at the first retransmit timer event which might not allow the requested rnr timeout. This patch adds a new flag (qp->req.wait_for_rnr_timer) which, if set, prevents a retry flow until the rnr nak timer fires. This patch fixes rnr retry errors which can be observed by running the pyverbs test_rdmacm_async_traffic_external_qp multiple times. With this patch applied they do not occur. Link: https://lore.kernel.org/linux-rdma/[email protected]/ Link: https://lore.kernel.org/linux-rdma/[email protected]/ Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fca288d87f6fc350e4f3c412caa3a12f3cec40fc Author: Md Haris Iqbal <[email protected]> Date: Thu Jul 7 09:30:06 2022 +0200 RDMA/rxe: For invalidate compare according to set keys in mr [ Upstream commit 174e7b137042f19b5ce88beb4fc0ff4ec6b0c72a ] The 'rkey' input can be an lkey or rkey, and in rxe the lkey or rkey have the same value, including the variant bits. So, if mr->rkey is set, compare the invalidate key with it, otherwise compare with the mr->lkey. Since we already did a lookup on the non-varient bits to get this far, the check's only purpose is to confirm that the wqe has the correct variant bits. Fixes: 001345339f4c ("RDMA/rxe: Separate HW and SW l/rkeys") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Reviewed-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 467a6c2e8e3de13cb7f314582cab7cf0af824247 Author: Artem Borisov <[email protected]> Date: Tue Jul 19 17:53:24 2022 +0300 HID: alps: Declare U1_UNICORN_LEGACY support [ Upstream commit 1117d182c5d72abd7eb8b7d5e7b8c3373181c3ab ] U1_UNICORN_LEGACY id was added to the driver, but was not declared in the device id table, making it impossible to use. Fixes: 640e403 ("HID: alps: Add AUI1657 device ID") Signed-off-by: Artem Borisov <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3d56b64a0669da1436fe46a65040da84e3c5258a Author: Liang He <[email protected]> Date: Tue Jul 19 17:52:16 2022 +0800 mmc: cavium-thunderx: Add of_node_put() when breaking out of loop [ Upstream commit 7ee480795e41db314f2c445c65ed854a5d6e8e32 ] In thunder_mmc_probe(), we should call of_node_put() when breaking out of for_each_child_of_node() which has increased and decreased the refcount during each iteration. Fixes: 166bac38c3c5 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs") Signed-off-by: Liang He <[email protected]> Acked-by: Robert Richter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit baad60b572da40ed913903022d790e8b03f1faac Author: Liang He <[email protected]> Date: Tue Jul 19 17:52:15 2022 +0800 mmc: cavium-octeon: Add of_node_put() when breaking out of loop [ Upstream commit 19bbb49acf8d7a03cb83e05624363741a4c3ec6f ] In octeon_mmc_probe(), we should call of_node_put() when breaking out of for_each_child_of_node() which has increased and decreased the refcount during each iteration. Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.") Signed-off-by: Liang He <[email protected]> Acked-by: Robert Richter <[email protected]> Link: https://lore.kernel.org/r/[email protected]com Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f22dc8bd31c4a391a98054c78ae540ca617ee3b9 Author: Liang He <[email protected]> Date: Tue Jul 19 17:10:51 2022 +0800 mmc: core: quirks: Add of_node_put() when breaking out of loop [ Upstream commit 883c1d6fa4368a63cae2d6ae2d9c91141c60e233 ] In mmc_fixup_of_compatible_match(), we should call of_node_put() when breaking out of for_each_child_of_node() which will increase and decrease the refcount during one iteration. Fixes: b360b1102670 ("mmc: core: allow to match the device tree to apply quirks") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2c5760339afaf9bdd1adb0f13bc5250feb62a4a6 Author: Bob Pearson <[email protected]> Date: Thu Jul 14 15:46:20 2022 -0500 RDMA/rxe: Fix mw bind to allow any consumer key portion [ Upstream commit 1603f89935ec86d40a7667e1250392626976ccc2 ] The current implementation of rxe_check_bind_mw() in rxe_mw.c is incorrect since it requires the new key portion provided by the mw consumer to be different than the previous key portion. This is not required by the IBA. Remove the test. Link: https://lore.kernel.org/linux-rdma/[email protected]/ Fixes: 32a577b4c3a9 ("Add support for bind MW work requests") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e5cee618792284d37431c5f71b8e43bbf81782f5 Author: Antonio Borneo <[email protected]> Date: Tue Jul 19 14:28:31 2022 +0200 scripts/gdb: fix 'lx-dmesg' on 32 bits arch [ Upstream commit e3c8d33e0d62175c31ca7ab7ab01b18f0b6318d3 ] The type atomic_long_t can have size 4 or 8 bytes, depending on CONFIG_64BIT; it's only content, the field 'counter', is either an int or a s64 value. Current code incorrectly uses the fixed size utils.read_u64() to read the field 'counter' inside atomic_long_t. On 32 bits architectures reading the last element 'tail_id' of the struct prb_desc_ring: struct prb_desc_ring { ... atomic_long_t tail_id; }; causes the utils.read_u64() to access outside the boundary of the struct and the gdb command 'lx-dmesg' exits with error: Python Exception <class 'IndexError'>: index out of range Error occurred in Python: index out of range Query the really used atomic_long_t counter type size. Link: https://lore.kernel.org/r/[email protected] Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer") Signed-off-by: Antonio Borneo <[email protected]> [[email protected]: Query the really used atomic_long_t counter type size] Tested-by: Antonio Borneo <[email protected]> Reviewed-by: John Ogness <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2b7d3d525eeed64fd93b1c3e206569e2704f7b2a Author: Fabio Estevam <[email protected]> Date: Wed Jul 6 08:13:27 2022 -0300 dmaengine: imx-dma: Cast of_device_get_match_data() with (uintptr_t) [ Upstream commit c3266ee185b59e5aab3e0f982e5b7f95d31555a7 ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: 0ab785c894e6 ("dmaengine: imx-dma: Remove unused .id_table") Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7af0350b25d5cc6ba6d2b16f8a63526f321bb523 Author: Basavaraj Natikar <[email protected]> Date: Tue Jul 12 23:48:26 2022 +0530 HID: amd_sfh: Add NULL check for hid device [ Upstream commit 06aa2a43c307cf4096f422dcb575e5d2913e528f ] On removal of hid device during SFH set report may cause NULL pointer exception. Hence add NULL check for hid device before accessing. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Basavaraj Natikar <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3c0f8a59f2cc8841ee6653399a77f4f3e6e9a270 Author: Harshit Mogalapalli <[email protected]> Date: Mon Jun 20 09:28:24 2022 -0700 HID: mcp2221: prevent a buffer overflow in mcp_smbus_write() [ Upstream commit 62ac2473553a00229e67bdf3cb023b62cf7f5a9a ] Smatch Warning: drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() '&mcp->txbuf[5]' too small (59 vs 255) drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf' too small (34 vs 255) The 'len' variable can take a value between 0-255 as it can come from data->block[0] and it is user data. So add an bound check to prevent a buffer overflow in memcpy(). Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Signed-off-by: Harshit Mogalapalli <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b41b0bfdc98326e451b821f00393fa8d95576fac Author: Dan Carpenter <[email protected]> Date: Thu Jul 7 17:54:45 2022 +0300 iio: adc: max1027: unlock on error path in max1027_read_single_value() [ Upstream commit 06ee60eb507f00fb3643876ec05318c63332dc88 ] If max1027_wait_eoc() fails then call iio_device_release_direct_mode() before returning. Fixes: a0e831653ef9 ("iio: adc: max1027: Introduce an end of conversion helper") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit dd5e0e25fb3983773ca958e429cf900db79b6927 Author: Liang He <[email protected]> Date: Mon Jul 11 20:52:38 2022 +0800 gpio: gpiolib-of: Fix refcount bugs in of_mm_gpiochip_add_data() [ Upstream commit 5d07a692f9562f9c06e62cce369e9dd108173a0f ] We should use of_node_get() when a new reference of device_node is created. It is noted that the old reference stored in 'mm_gc->gc.of_node' should also be decreased. This patch is based on the fact that there is a call site in function 'qe_add_gpiochips()' of src file 'drivers\soc\fsl\qe\gpio.c'. In this function, of_mm_gpiochip_add_data() is contained in an iteration of for_each_compatible_node() which will automatically increase and decrease the refcount. So we need additional of_node_get() for the reference escape in of_mm_gpiochip_add_data(). Fixes: a19e3da5bc5f ("of/gpio: Kill of_gpio_chip and add members directly to gpio_chip") Signed-off-by: Liang He <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a9055dfe437efae77e28e57205437c878a03ccb7 Author: Jianglei Nie <[email protected]> Date: Mon Jul 11 15:07:18 2022 +0800 RDMA/hfi1: fix potential memory leak in setup_base_ctxt() [ Upstream commit aa2a1df3a2c85f855af7d54466ac10bd48645d63 ] setup_base_ctxt() allocates a memory chunk for uctxt->groups with hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups is not released, which will lead to a memory leak. We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups() when init_user_ctxt() fails. Fixes: e87473bc1b6c ("IB/hfi1: Only set fd pointer when base context is completely initialized") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jianglei Nie <[email protected]> Acked-by: Dennis Dalessandro <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ebf55177909f3810465e2d042dabdd2bf12c0dca Author: Bryan O'Donoghue <[email protected]> Date: Tue Jul 12 13:59:17 2022 +0100 clk: qcom: gcc-msm8939: Fix weird field spacing in ftbl_gcc_camss_cci_clk [ Upstream commit 2bc308ebc453ba22f3f120f777b9ac48f973ee80 ] Adding a new item to this frequency table I see the existing indentation is incorrect. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 94d80c6d7017211e604f7503d575223cf82ddfa8 Author: Bjorn Andersson <[email protected]> Date: Wed Jul 13 14:28:18 2022 -0700 clk: qcom: gdsc: Bump parent usage count when GDSC is found enabled [ Upstream commit 41fff779d7948147f2440c4bb134cdf8b45b22d7 ] When a GDSC is found to be enabled at boot the pm_runtime state will be unbalanced as the GDSC is later turned off. Fix this by increasing the usage counter on the power-domain, in line with how we handled the regulator state. Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Signed-off-by: Bjorn Andersson <[email protected]> Acked-by: Stephen Boyd <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3f3ea0aeb26195fbc0efeb29299a8223ac129adb Author: Abel Vesa <[email protected]> Date: Wed Jul 13 17:32:00 2022 +0300 clk: qcom: Drop mmcx gdsc supply for dispcc and videocc [ Upstream commit b1ec8b53c9ae5fae33d60e9638d39ca5346b941b ] Both dispcc and videocc use mmcx power domain now. Lets drop the supply mmcx from every gdsc. Cc: Dmitry Baryshkov <[email protected]> Fixes: 266e5cf39a0f ("arm64: dts: qcom: sm8250: remove mmcx regulator") Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 64f5669fa7143f62890f2136af513c8286f5d9b7 Author: Gwendal Grignou <[email protected]> Date: Mon Jul 11 07:47:16 2022 -0700 iio: cros: Register FIFO callback after sensor is registered [ Upstream commit 0b4ae3f6d1210c11f9baf159009c7227eacf90f2 ] Instead of registering callback to process sensor events right at initialization time, wait for the sensor to be register in the iio subsystem. Events can come at probe time (in case the kernel rebooted abruptly without switching the sensor off for instance), and be sent to IIO core before the sensor is fully registered. Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Reported-by: Douglas Anderson <[email protected]> Signed-off-by: Gwendal Grignou <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8598b9d0a364c1663c96fc0fab9df0d36c809aea Author: Zhu Yanjun <[email protected]> Date: Tue Jul 5 18:54:14 2022 -0400 RDMA/rxe: Fix BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup [ Upstream commit 37da51efe6eaa0560f46803c8c436a48a2084da7 ] The function rxe_create_qp calls rxe_qp_from_init. If some error occurs, the error handler of function rxe_qp_from_init will set both scq and rcq to NULL. Then rxe_create_qp calls rxe_put to handle qp. In the end, rxe_qp_do_cleanup is called by rxe_put. rxe_qp_do_cleanup directly accesses scq and rcq before checking them. This will cause null-ptr-deref error. The call graph is as below: rxe_create_qp { ... rxe_qp_from_init { ... err1: ... qp->rcq = NULL; <---rcq is set to NULL qp->scq = NULL; <---scq is set to NULL ... } qp_init: rxe_put{ ... rxe_qp_do_cleanup { ... atomic_dec(&qp->scq->num_wq); <--- scq is accessed ... atomic_dec(&qp->rcq->num_wq); <--- rcq is accessed } } Fixes: 4703b4f0d94a ("RDMA/rxe: Enforce IBA C11-17") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Zhu Yanjun <[email protected]> Reviewed-by: Bob Pearson <[email protected]> Reviewed-by: Md Haris Iqbal <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1434de50a5d9dab91c8ce031bc23b3e2178379c5 Author: Cheng Xu <[email protected]> Date: Thu Jul 14 09:30:47 2022 +0800 RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event [ Upstream commit 3056fc6c32e613b760422b94c7617ac9a24a4721 ] If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY in this case. This may trigger a call trace in iw_cm. A simple way to trigger this: server: ib_send_lat client: ib_send_lat -R <server_ip> The call trace looks like this: kernel BUG at drivers/infiniband/core/iwcm.c:894! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <...> Workqueue: iw_cm_wq cm_work_handler [iw_cm] Call Trace: <TASK> cm_work_handler+0x1dd/0x370 [iw_cm] process_one_work+0x1e2/0x3b0 worker_thread+0x49/0x2e0 ? rescuer_thread+0x370/0x370 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Link: https://lore.kernel.org/r/d[email protected]linux.alibaba.com Signed-off-by: Cheng Xu <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 94569c55422a5df31851b43b3c892631b541191c Author: Haoyue Xu <[email protected]> Date: Thu Jul 14 21:43:51 2022 +0800 RDMA/hns: Fix incorrect clearing of interrupt status register [ Upstream commit ecb4db5c3590aa956b4b2c352081a5b632d1f9f9 ] The driver will clear all the interrupts in the same area when the driver handles the interrupt of type AEQ overflow. It should only set the interrupt status bit of type AEQ overflow. Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Haoyue Xu <[email protected]> Signed-off-by: Wenpeng Liang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b4c9f7db9f0148423557539af0fdf513338efe08 Author: Jianglei Nie <[email protected]> Date: Thu Jul 14 14:15:05 2022 +0800 RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() [ Upstream commit b3236a64ddd125a455ef5b5316c1b9051b732974 ] __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr" is released while "mr->info.pbl_table" is not released, which will lead to a memory leak. We should release the "mr->info.pbl_table" with qedr_free_pbl() when error occurs to fix the memory leak. Fixes: e0290cce6ac0 ("qedr: Add support for memory registeration verbs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jianglei Nie <[email protected]> Acked-by: Michal Kalderon <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9890ddd4768b6d22192a748275a7331659dd66d4 Author: Md Haris Iqbal <[email protected]> Date: Tue Jul 12 12:31:12 2022 +0200 RDMA/rtrs-clt: Replace list_next_or_null_rr_rcu with an inline function [ Upstream commit c14adff285ad1bb8eefc5d8fc202ceb1f7e3a2f1 ] removes list_next_or_null_rr_rcu macro to fix below warnings. That macro is used only twice. CHECK:MACRO_ARG_REUSE: Macro argument reuse 'head' - possible side-effects? CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ptr' - possible side-effects? CHECK:MACRO_ARG_REUSE: Macro argument reuse 'memb' - possible side-effects? Replaces that macro with an inline function. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Suggested-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a14aeefc9853c4ab03c87a423709dc2ee3138370 Author: Jack Wang <[email protected]> Date: Tue Jul 12 12:31:09 2022 +0200 RDMA/rtrs-srv: Fix modinfo output for stringify [ Upstream commit ed6e53820ee4f68ed927de17e5675ff2a07a47e2 ] stringify works with define, not enum. Fixes: 91fddedd439c ("RDMA/rtrs: private headers with rtrs protocol structs and helpers") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Md Haris Iqbal <[email protected]> Reviewed-by: Aleksei Marov <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c12c824822dcfeae35a2fc351b2975147ef611b5 Author: Mustafa Ismail <[email protected]> Date: Tue Jul 5 18:08:15 2022 -0500 RDMA/irdma: Fix setting of QP context err_rq_idx_valid field [ Upstream commit 3a844596ed71b7c12ac602f6f6b7b0f17e4d6a90 ] Setting err_rq_idx_valid field in QP context when the AE source of the AEQE is not associated with an RQ causes the firmware flush to fail. Set err_rq_idx_valid field in QP context only if it is associated with an RQ. Additionally, cleanup the redundant setting of this field in irdma_process_aeq. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mustafa Ismail <[email protected]> Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f420fa0def4700176cb87517928dfb290a60ce31 Author: Mustafa Ismail <[email protected]> Date: Tue Jul 5 18:08:14 2022 -0500 RDMA/irdma: Fix VLAN connection with wildcard address [ Upstream commit 82ab2b52654c43ba24a3f6603fec40874cc5a7e5 ] When an application listens on a wildcard address, and there are VLAN and non-VLAN IP addresses, iWARP connection establishemnt can fail if the listen node VLAN ID does not match. Fix this by checking the vlan_id only if not a wildcard listen node. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mustafa Ismail <[email protected]> Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 350ac793a03c8a30a3f2b27fc282cd1c67070763 Author: Mustafa Ismail <[email protected]> Date: Tue Jul 5 18:08:13 2022 -0500 RDMA/irdma: Fix a window for use-after-free [ Upstream commit 8ecef7890b3aea78c8bbb501a4b5b8134367b821 ] During a destroy CQ an interrupt may cause processing of a CQE after CQ resources are freed by irdma_cq_free_rsrc(). Fix this by moving the call to irdma_cq_free_rsrc() after the irdma_sc_cleanup_ceqes(), which is called under the cq_lock. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Sobczak <[email protected]> Signed-off-by: Mustafa Ismail <[email protected]> Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6cb78e41ce2e36d6f9fee21cecfc020c441328fe Author: Patrick Wang <[email protected]> Date: Tue Jul 5 19:31:58 2022 +0800 mm: percpu: use kmemleak_ignore_phys() instead of kmemleak_free() [ Upstream commit a317ebccaa3609917a2c021af870cf3fa607ab0c ] Kmemleak recently added a rbtree to store the objects allocted with physical address. Those objects can't be freed with kmemleak_free(). According to the comments, percpu allocations are tracked by kmemleak separately. Kmemleak_free() was used to avoid the unnecessary tracking. If kmemleak_free() fails, those objects would be scanned by kmemleak, which is unnecessary but shouldn't lead to other effects. Use kmemleak_ignore_phys() instead of kmemleak_free() for those objects. Link: https://lkml.kernel.org/r/[email protected] Fixes: 0c24e061196c ("mm: kmemleak: add rbtree and store physical address for objects allocated with PA") Signed-off-by: Patrick Wang <[email protected]> Cc: Dennis Zhou <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Catalin Marinas <[email protected]> Signed-off-by: Andrew Morton <[email protected]org> Signed-off-by: Sasha Levin <[email protected]> commit 7974b2039c52e247029a052c77fdd324890e7400 Author: Christopher Obbard <[email protected]> Date: Thu Jun 23 09:58:42 2022 +0100 um: random: Don't initialise hwrng struct with zero [ Upstream commit 9e70cbd11b03889c92462cf52edb2bd023c798fa ] Initialising the hwrng struct with zeros causes a compile-time sparse warning: $ ARCH=um make -j10 W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ... CHECK arch/um/drivers/random.c arch/um/drivers/random.c:31:31: sparse: warning: Using plain integer as NULL pointer Fix the warning by not initialising the hwrng struct with zeros as it is initialised anyway during module init. Fixes: 72d3e093afae ("um: random: Register random as hwrng-core device") Reported-by: kernel test robot <[email protected]> Signed-off-by: Christopher Obbard <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9e3d119d5d6c7f51cba5feb9481f8e88f16c24bd Author: Kalesh Singh <[email protected]> Date: Fri Jul 15 16:58:24 2022 -0700 KVM: arm64: Fix hypervisor address symbolization [ Upstream commit ed6313a93fd11d2015ad17046f3c418bf6a8dab1 ] With CONFIG_RANDOMIZE_BASE=y vmlinux addresses will resolve incorrectly from kallsyms. Fix this by adding the KASLR offset before printing the symbols. Fixes: 6ccf9cb557bd ("KVM: arm64: Symbolize the nVHE HYP addresses") Reported-by: Fuad Tabba <[email protected]> Signed-off-by: Kalesh Singh <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1be95546e8223aa7f72ea669c6a0150bed991e57 Author: Peng Fan <[email protected]> Date: Sun Jul 3 17:11:26 2022 +0800 interconnect: imx: fix max_node_id [ Upstream commit bd734481e172b4827af09c9ab06c51d2ab7201e6 ] max_node_id not equal to the ARRAY_SIZE of node array, need increase 1, otherwise xlate will fail for the last entry. And rename max_node_id to num_nodes to reflect the reality. Fixes: f0d8048525d7d ("interconnect: Add imx core driver") Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 305a0aa6717dbbb180a7b84ba258f3bb720f978a Author: Samuel Holland <[email protected]> Date: Fri Jul 8 01:14:34 2022 -0500 phy: rockchip-inno-usb2: Ignore OTG IRQs in host mode [ Upstream commit fd7d47484125c7d04578de9294faa7fec6e5df0a ] When the OTG port is fixed to host mode, the driver does not request its IRQs, nor does it enable those IRQs in hardware. Similarly, the driver should ignore the OTG port IRQs when handling the shared interrupt. Otherwise, it would update the extcon based on an ID pin which may be in an undefined state, or try to queue a uninitialized work item. Fixes: 6a98df08ccd5 ("phy: rockchip-inno-usb2: Fix muxed interrupt support") Reported-by: Frank Wunderlich <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Tested-by: Peter Geis <[email protected]> Tested-by: Frank Wunderlich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d29787a42e24f58bc5f42a03d99524556474db77 Author: Fabrice Gasnier <[email protected]> Date: Wed Jul 13 15:39:53 2022 +0200 phy: stm32: fix error return in stm32_usbphyc_phy_init [ Upstream commit 32b378a9179ae4db61cfc5d502717214e6cd1e1c ] Error code is overridden, in case the PLL doesn't lock. So, the USB initialization can continue. This leads to a platform freeze. This can be avoided by returning proper error code to avoid USB probe freezing the platform. It also displays proper errors in log. Fixes: 5b1af71280ab ("phy: stm32: rework PLL Lock detection") Signed-off-by: Fabrice Gasnier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 043dc5d046b26227f24a8ac7905b7906dbb9c7d5 Author: Dan Carpenter <[email protected]> Date: Fri Jul 8 16:46:38 2022 +0300 eeprom: idt_89hpesx: uninitialized data in idt_dbgfs_csr_write() [ Upstream commit 71d46f1ff2212ced4852c7e77c5176382a1bdcec ] The simple_write_to_buffer() function will return positive/success if it is able to write a single byte anywhere within the buffer. However that potentially leaves a lot of the buffer uninitialized. In this code it's better to return 0 if the offset is non-zero. This code is not written to support partial writes. And then return -EFAULT if the buffer is not completely initialized. Fixes: cfad6425382e ("eeprom: Add IDT 89HPESx EEPROM/CSR driver") Reviewed-by: Serge Semin <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/Ysg1Pu/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 216055fa5e20c8cc59f6ce317fcd9bcd467a4dd0 Author: Johan Hovold <[email protected]> Date: Wed Jul 13 15:13:36 2022 +0200 usb: dwc3: qcom: fix missing optional irq warnings [ Upstream commit 69bb3520db7cecbccc9e497fc568fa5465c9d43f ] Not all platforms have all of the four currently supported wakeup interrupts so use the optional irq helpers when looking up interrupts to avoid printing error messages when an optional interrupt is not found: dwc3-qcom a6f8800.usb: error -ENXIO: IRQ hs_phy_irq not found Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Reviewed-by: Andrew Halaney <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e3cb5a27c6b240faa2e0f79e08aac4aa6ee3ac56 Author: Rohith Kollalsi <[email protected]> Date: Thu Jul 14 10:26:25 2022 +0530 usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during bootup [ Upstream commit 07903626d98853e605fe63e5ce149f1b7314bbea ] According to the programming guide, it is recommended to perform a GCTL_CORE_SOFTRESET only when switching the mode from device to host or host to device. However, it is found that during bootup when __dwc3_set_mode() is called for the first time, GCTL_CORESOFTRESET is done with suspendable bit(BIT 17) of DWC3_GUSB3PIPECTL set. This some times leads to issues like controller going into bad state and controller registers reading value zero. Until GCTL_CORESOFTRESET is done and run/stop bit is set core initialization is not complete. Setting suspendable bit of DWC3_GUSB3PIPECTL and then performing GCTL_CORESOFTRESET is therefore not recommended. Avoid this by only performing the reset if current_dr_role is set, that is, when doing subsequent role switching. Fixes: f88359e1588b ("usb: dwc3: core: Do core softreset when switch mode") Signed-off-by: Rohith Kollalsi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d0a97d94b7c3184486e93221f0e2acbe4a89501b Author: Thinh Nguyen <[email protected]> Date: Wed Jun 15 17:24:32 2022 -0700 usb: dwc3: core: Deprecate GCTL.CORESOFTRESET [ Upstream commit afbd04e66e5d16ca3c7ea2e3c56eca25558eacf3 ] Synopsys IP DWC_usb32 and DWC_usb31 version 1.90a and above deprecated GCTL.CORESOFTRESET. The DRD mode switching flow is updated to remove the GCTL soft reset. Add version checks to prevent using deprecated setting in mode switching flow. Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/9df52[email protected]synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3503305225ca24c3229414c769323fb8bf39b4bf Author: Liang He <[email protected]> Date: Wed Jul 13 20:05:28 2022 +0800 usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc() [ Upstream commit 220fafb4ed04187e9c17be4152da5a7f2ffbdd8c ] We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 30d2617fd7ed ("usb: gadget: aspeed: allow to set usb strings in device tree") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8e8769e7fa792653cdd6fb42d8e1e5f3397374fc Author: Randy Dunlap <[email protected]> Date: Fri Jul 8 18:36:01 2022 -0700 usb: gadget: udc: amd5536 depends on HAS_DMA [ Upstream commit 8097cf2fb3b2205257f1c76f4808e3398d66b6d9 ] USB_AMD5536UDC should depend on HAS_DMA since it selects USB_SNP_CORE, which depends on HAS_DMA and since 'select' does not follow any dependency chains. Fixes this kconfig warning: WARNING: unmet direct dependencies detected for USB_SNP_CORE Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=y] && (USB_AMD5536UDC [=y] || USB_SNP_UDC_PLAT [=n]) && HAS_DMA [=n] Selected by [y]: - USB_AMD5536UDC [=y] && USB_SUPPORT [=y] && USB_GADGET [=y] && USB_PCI [=y] Fixes: 97b3ffa233b9 ("usb: gadget: udc: amd5536: split core and PCI layer") Cc: Raviteja Garimella <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: [email protected] Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 70cee09b16dc73e637a5fd1656ef685a5199f523 Author: Yang Yingliang <[email protected]> Date: Thu Jul 7 10:32:29 2022 +0800 xtensa: iss: fix handling error cases in iss_net_configure() [ Upstream commit 628ccfc8f5f79dd548319408fcc53949fe97b258 ] The 'pdev' and 'netdev' need to be released in error cases of iss_net_configure(). Change the return type of iss_net_configure() to void, because it's not used. Fixes: 7282bee78798 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 8") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Max Filippov <[email protected]> Signed-off-by: Sasha Levin <[email protected]rg> commit 462a15a38345ae21bd089f1cb37197a77e7bb22e Author: Max Filippov <[email protected]> Date: Thu Jul 7 00:23:16 2022 -0700 xtensa: iss/network: provide release() callback [ Upstream commit 8864fb8359682912ee99235db7db916733a1fd7b ] Provide release() callback for the platform device embedded into struct iss_net_private and registered in the iss_net_configure so that platform_device_unregister could be called for it. Signed-off-by: Max Filippov <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e240328df6add0791464ed3555664897c075d473 Author: Mahesh Rajashekhara <[email protected]> Date: Fri Jul 8 13:47:36 2022 -0500 scsi: smartpqi: Fix DMA direction for RAID requests [ Upstream commit 69695aeaa6621bc49cdd7a8e5a8d1042461e496e ] Correct a SOP READ and WRITE DMA flags for some requests. This update corrects DMA direction issues with SCSI commands removed from the controller's internal lookup table. Currently, SCSI READ BLOCK LIMITS (0x5) was removed from the controller lookup table and exposed a DMA direction flag issue. SCSI READ BLOCK LIMITS was recently removed from our controller lookup table so the controller uses the respective IU flag field to set the DMA data direction. Since the DMA direction is incorrect the FW never completes the request causing a hang. Some SCSI commands which use SCSI READ BLOCK LIMITS * sg_map * mt -f /dev/stX status After updating controller firmware, users may notice their tape units failing. This patch resolves the issue. Also, the AIO path DMA direction is correct. The DMA direction flag is a day-one bug with no reported BZ. Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver") Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Reviewed-by: Kevin Barnett <[email protected]> Signed-off-by: Mahesh Rajashekhara <[email protected]> Signed-off-by: Don Brace <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a86857e9d30956dae8b24a56a297d734580f921e Author: Christian Marangi <[email protected]> Date: Sat Jul 9 00:27:43 2022 +0200 PCI: qcom: Set up rev 2.1.0 PARF_PHY before enabling clocks [ Upstream commit 38f897ae3d44900f627cad708a15db498ce2ca31 ] We currently enable clocks BEFORE we write to PARF_PHY_CTRL reg to enable clocks and resets. This causes the driver to never set to a ready state with the error 'Phy link never came up'. This is caused by the PHY clock getting enabled before setting the required bits in the PARF regs. A workaround for this was set but with this new discovery we can drop the workaround and use a proper solution to the problem by just enabling the clock only AFTER the PARF_PHY_CTRL bit is set. This correctly sets up the PCIe link and makes it usable even when a bootloader leaves the PCIe link in an undefined state. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 65e393fddc5379b2c41ca7e73cd4bb9572c4d90e Author: Stefan Roese <[email protected]> Date: Tue Jan 25 08:18:19 2022 +0100 PCI/portdrv: Don't disable AER reporting in get_port_device_capability() [ Upstream commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 ] AER reporting is currently disabled in the DevCtl registers of all non Root Port PCIe devices on systems using pcie_ports_native || host->native_aer, disabling AER completely in such systems. This is because 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization"), added a call to pci_disable_pcie_error_reporting() *after* the AER setup was completed for the PCIe device tree. Here a longer analysis about the current status of AER enabling / disabling upon bootup provided by Bjorn: pcie_portdrv_probe pcie_port_device_register get_port_device_capability pci_disable_pcie_error_reporting clear CERE NFERE FERE URRE # <-- disable for RP USP DSP pcie_device_init device_register # new AER service device aer_probe aer_enable_rootport # RP only set_downstream_devices_error_reporting set_device_error_reporting # self (RP) if (RP || USP || DSP) pci_enable_pcie_error_reporting set CERE NFERE FERE URRE # <-- enable for RP pci_walk_bus set_device_error_reporting if (RP || USP || DSP) pci_enable_pcie_error_reporting set CERE NFERE FERE URRE # <-- enable for USP DSP In a typical Root Port -> Endpoint hierarchy, the above: - Disables Error Reporting for the Root Port, - Enables Error Reporting for the Root Port, - Does NOT enable Error Reporting for the Endpoint because it is not a Root Port or Switch Port. In a deeper Root Port -> Upstream Switch Port -> Downstream Switch Port -> Endpoint hierarchy: - Disables Error Reporting for the Root Port, - Enables Error Reporting for the Root Port, - Enables Error Reporting for both Switch Ports, - Does NOT enable Error Reporting for the Endpoint because it is not a Root Port or Switch Port, - Disables Error Reporting for the Switch Ports when pcie_portdrv_probe() claims them. AER does not re-enable it because these are not Root Ports. Remove this call to pci_disable_pcie_error_reporting() from get_port_device_capability(), leaving the already enabled AER configuration intact. With this change, AER is enabled in the Root Port and the PCIe switch upstream and downstream ports. Only the PCIe Endpoints don't have AER enabled yet. A follow-up patch will take care of this Endpoint enabling. Fixes: 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Roese <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bharat Kumar Gogada <[email protected]> Cc: Michal Simek <[email protected]> Cc: Yao Hongbo <[email protected]> Cc: Naveen Naidu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 63c71e83d5b6ab8adb5fcebef977052048016957 Author: Claudio Imbrenda <[email protected]> Date: Tue Jun 28 15:56:02 2022 +0200 KVM: s390: pv: leak the topmost page table when destroy fails [ Upstream commit faa2f72cb3569256480c5540d242c84e99965160 ] Each secure guest must have a unique ASCE (address space control element); we must avoid that new guests use the same page for their ASCE, to avoid errors. Since the ASCE mostly consists of the address of the topmost page table (plus some flags), we must not return that memory to the pool unless the ASCE is no longer in use. Only a successful Destroy Secure Configuration UVC will make the ASCE reusable again. If the Destroy Configuration UVC fails, the ASCE cannot be reused for a secure guest (either for the ASCE or for other memory areas). To avoid a collision, it must not be used again. This is a permanent error and the page becomes in practice unusable, so we set it aside and leak it. On failure we already leak other memory that belongs to the ultravisor (i.e. the variable and base storage for a guest) and not leaking the topmost page table was an oversight. This error (and thus the leakage) should not happen unless the hardware is broken or KVM has some unknown serious bug. Signed-off-by: Claudio Imbrenda <[email protected]> Fixes: 29b40f105ec8d55 ("KVM: s390: protvirt: Add initial vm and cpu lifecycle handling") Reviewed-by: Janosch Frank <[email protected]> Link: https://lore.kernel.org/r/[email protected] Message-Id: <[email protected]> Signed-off-by: Janosch Frank <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ef892ef0831be4e0798e78c7f2b27d83089b93e7 Author: Christian Loehle <[email protected]> Date: Fri Jul 1 12:43:09 2022 +0000 mmc: block: Add single read for 4k sector cards [ Upstream commit b3fa3e6dccc465969721b8bd2824213bd235efeb ] Cards with 4k native sector size may only be read 4k-aligned, accommodate for this in the single read recovery and use it. Fixes: 81196976ed946 (mmc: block: Add blk-mq support) Signed-off-by: Christian Loehle <[email protected]> Acked-by: Adrian Hunter <[email protected]> Reviewed-by: Avri Altman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit dfca1e217298ca5cdc4aba9c0ac49e8d3e2bf776 Author: Liang He <[email protected]> Date: Sat Jul 2 09:44:49 2022 +0800 of: device: Fix missing of_node_put() in of_dma_set_restricted_buffer [ Upstream commit d17e37c41b7ed38459957a5d2968ba61516fd5c2 ] We should use of_node_put() for the reference 'node' returned by of_parse_phandle() which will increase the refcount. Fixes: fec9b625095f ("of: Add plumbing for restricted DMA pool") Co-authored-by: Miaoqian Lin <[email protected]> Signed-off-by: Liang He <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 98b2ddfa9471e6bf19054e6541cb3118ee94361a Author: Eugen Hristev <[email protected]> Date: Thu Jun 30 12:09:26 2022 +0300 mmc: sdhci-of-at91: fix set_uhs_signaling rewriting of MC1R [ Upstream commit 5987e6ded29d52e42fc7b06aa575c60a25eee38e ] In set_uhs_signaling, the DDR bit is being set by fully writing the MC1R register. This can lead to accidental erase of certain bits in this register. Avoid this by doing a read-modify-write operation. Fixes: d0918764c17b ("mmc: sdhci-of-at91: fix MMC_DDR_52 timing selection") Signed-off-by: Eugen Hristev <[email protected]> Tested-by: Karl Olsen <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 39be95d1ff7b44c1e969af72ba9da7332dfcc1da Author: Christophe JAILLET <[email protected]> Date: Sat Jun 25 14:55:56 2022 +0200 memstick/ms_block: Fix a memory leak [ Upstream commit 54eb7a55be6779c4d0c25eaf5056498a28595049 ] 'erased_blocks_bitmap' is never freed. As it is allocated at the same time as 'used_blocks_bitmap', it is likely that it should be freed also at the same time. Add the corresponding bitmap_free() in msb_data_clear(). Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/b3b78926569[email protected]wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8bb0c5a19f063cf6a29c0faa4d4bb33c38a3ddcb Author: Christophe JAILLET <[email protected]> Date: Sat Jun 25 14:55:25 2022 +0200 memstick/ms_block: Fix some incorrect memory allocation [ Upstream commit 2e531bc3e0d86362fcd8a577b3278d9ef3cc2ba0 ] Some functions of the bitmap API take advantage of the fact that a bitmap is an array of long. So, to make sure this assertion is correct, allocate bitmaps with bitmap_zalloc() instead of kzalloc()+hand-computed number of bytes. While at it, also use bitmap_free() instead of kfree() to keep the semantic. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/dbf633c48c2[email protected]wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a42d829b75241f084253e7e28564db1f871ef12c Author: Lad Prabhakar <[email protected]> Date: Fri Jun 24 19:14:37 2022 +0100 mmc: renesas_sdhi: Get the reset handle early in the probe [ Upstream commit 0dac1e498f8130fdacfdd5289e3a7ac87ec1b9ad ] In case of devm_reset_control_get_optional_exclusive() failure we returned directly instead of jumping to the error path to roll back initialization. This patch moves devm_reset_control_get_optional_exclusive() early in the probe so that we have the reset handle prior to initialization of the hardware. Fixes: b4d86f37eacb7 ("mmc: renesas_sdhi: do hard reset if possible") Reported-by: Pavel Machek <[email protected]> Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e972c9f132f8f94d23d8b5b7ec892a8e44859226 Author: Fabio Estevam <[email protected]> Date: Wed May 25 22:00:22 2022 -0300 mmc: mxcmmc: Silence a clang warning [ Upstream commit 7dc65e3c0ef4b746a583b7c58f99873fddf5ccfa ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: drivers/mmc/host/mxcmmc.c:1028:18: warning: cast to smaller integer type 'enum mxcmci_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: 8223e885e74b ("mmc: mxc: Convert the driver to DT-only") Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8b902840f6a3584f702bcb59834691b30f3d7c5a Author: Miaoqian Lin <[email protected]> Date: Mon May 23 18:42:54 2022 +0400 mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch [ Upstream commit b5899a3e2f783a27b268e38d37f9b24c71bddf45 ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. Fixes: ea35645a3c66 ("mmc: sdhci-of-esdhc: add support for signal voltage switch") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 517a646109292bf7e4844cb45ed3e6b5de5de726 Author: Bhupesh Sharma <[email protected]> Date: Sun May 15 03:31:16 2022 +0530 dt-bindings: mmc: sdhci-msm: Fix issues in yaml bindings [ Upstream commit 8574adf5222d786b747022c6edcbcdddf409a139 ] Rob pointed some remaining issues in the sdhci-msm yaml bindings (via [1]). Fix the same by first using the 'mmc-controller.yaml' as 'ref' and thereafter also fix the issues reported by 'make dtbs_check' check. [1]. https://lore.kernel.org/linux-arm-msm/[email protected]/ Fixes: a45537723f4b ("dt-bindings: mmc: sdhci-msm: Convert bindings to yaml") Cc: Bjorn Andersson <[email protected]> Cc: Rob Herring <[email protected]> Cc: Ulf Hansson <[email protected]> Signed-off-by: Bhupesh Sharma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ca766e26941ccefb5ed6988ab44e72be6bf2b9fc Author: Dan Carpenter <[email protected]> Date: Wed May 25 15:25:06 2022 +0300 habanalabs: fix double unlock on error in map_device_va() [ Upstream commit a43a9f67774adbd575d10ec88824016fbe034777 ] If hl_mmu_prefetch_cache_range() fails then this code calls mutex_unlock(&ctx->mmu_lock) when it's no longer holding the mutex. Fixes: 9e495e24003e ("habanalabs: do MMU prefetch as deferred work") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e76a9f68081738f8569c8a7162abb8a67ac9be59 Author: jianchunfu <[email protected]> Date: Wed Jun 15 15:33:48 2022 +0800 rtla/utils: Use calloc and check the potential memory allocation failure [ Upstream commit b5f37a0b6f667f5c72340ca9dcd7703f261cb981 ] Replace malloc with calloc and add memory allocating check of mon_cpus before used. Link: https://lkml.kernel.org/r/[email protected] Fixes: 7d0dc9576dc3 ("rtla/timerlat: Add --dma-latency option") Signed-off-by: jianchunfu <[email protected]> Acked-by: Daniel Bristot de Oliveira <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit f10541e2d75ded6046fe1c56733c6d4a8c1ab0d6 Author: Duoming Zhou <[email protected]> Date: Sun Jul 10 18:30:02 2022 +0800 staging: rtl8192u: Fix sleep in atomic context bug in dm_fsync_timer_callback [ Upstream commit 6a0c054930d554ad8f8044ef1fc856d9da391c81 ] There are sleep in atomic context bugs when dm_fsync_timer_callback is executing. The root cause is that the memory allocation functions with GFP_KERNEL or GFP_NOIO parameters are called in dm_fsync_timer_callback which is a timer handler. The call paths that could trigger bugs are shown below: (interrupt context) dm_fsync_timer_callback write_nic_byte kzalloc(sizeof(data), GFP_KERNEL); //may sleep usb_control_msg kmalloc(.., GFP_NOIO); //may sleep write_nic_dword kzalloc(sizeof(data), GFP_KERNEL); //may sleep usb_control_msg kmalloc(.., GFP_NOIO); //may sleep This patch uses delayed work to replace timer and moves the operations that may sleep into the delayed work in order to mitigate bugs. Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 13ac27023f602a81aeb46e93ce88f4fbc341a9bc Author: Carlos Llamas <[email protected]> Date: Fri Jul 1 18:20:41 2022 +0000 binder: fix redefinition of seq_file attributes [ Upstream commit b7e241bbff24f9e106bf616408fd58bcedc44bae ] The patchset in [1] exported some definitions to binder_internal.h in order to make the debugfs entries such as 'stats' and 'transaction_log' available in a binderfs instance. However, the DEFINE_SHOW_ATTRIBUTE macro expands into a static function/variable pair, which in turn get redefined each time a source file includes this internal header. This problem was made evident after a report from the kernel test robot <[email protected]> where several W=1 build warnings are seen in downstream kernels. See the following example: include/../drivers/android/binder_internal.h:111:23: warning: 'binder_stats_fops' defined but not used [-Wunused-const-variable=] 111 | DEFINE_SHOW_ATTRIBUTE(binder_stats); | ^~~~~~~~~~~~ include/linux/seq_file.h:174:37: note: in definition of macro 'DEFINE_SHOW_ATTRIBUTE' 174 | static const struct file_operations __name ## _fops = { \ | ^~~~~~ This patch fixes the above issues by moving back the definitions into binder.c and instead creates an array of the debugfs entries which is more convenient to share with binderfs and iterate through. [1] https://lore.kernel.org/all/[email protected]/ Fixes: 0e13e452dafc ("binder: Add stats, state and transactions files") Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs") Reported-by: kernel test robot <[email protected]> Signed-off-by: Carlos Llamas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4914c50670b6a531e2cb17cd984cc565b4681312 Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:34 2022 +0300 intel_th: msu: Fix vmalloced buffers [ Upstream commit ac12ad3ccf6d386e64a9d6a890595a2509d24edd ] After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's a chance of DMA buffer getting allocated via vmalloc(), which messes up the mmapping code: > RIP: msc_mmap_fault [intel_th_msu] > Call Trace: > <TASK> > __do_fault > do_fault ... Fix this by accounting for vmalloc possibility. Fixes: ba39bd830605 ("intel_th: msu: Switch over to scatterlist") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e1d427d46269db0ac024905128bbb8aa34f565e3 Author: Jiasheng Jiang <jiashe[email protected]> Date: Tue Jul 5 11:26:33 2022 +0300 intel_th: msu-sink: Potential dereference of null pointer [ Upstream commit 82f76a4a720791d889de775b5f7541d601efc8bd ] The return value of dma_alloc_coherent() needs to be checked. To avoid use of null pointer in sg_set_buf() in case of the failure of alloc. Fixes: f220df66f676 ("intel_th: msu-sink: An example msu buffer "sink"") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit fae9da7d4c2ccad3792de03e3cac1fe2bfabb73d Author: Christophe JAILLET <[email protected]> Date: Tue Jul 5 11:26:32 2022 +0300 intel_th: Fix a resource leak in an error handling path [ Upstream commit 086c28ab7c5699256aced0049aae9c42f1410313 ] If an error occurs after calling 'pci_alloc_irq_vectors()', 'pci_free_irq_vectors()' must be called as already done in the remove function. Fixes: 7b7036d47c35 ("intel_th: pci: Use MSI interrupt signalling") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8cc35cd5ae3afc048ebe230f7c4558ddbaf4d276 Author: James Smart <[email protected]> Date: Fri Jul 1 14:14:21 2022 -0700 scsi: lpfc: Revert RSCN_MEMENTO workaround for misbehaved configuration [ Upstream commit ffc566411aded3c12c63e1310fb23830e9608c59 ] The RSCN_MEMENTO logic was to workaround a target that does not register both FCP and NVMe FC4 types at the same time. This caused the configuration to not produce a second RSCN for the NVMe FC4 type registration in a timely manner. The intention of the RSCN_MEMENTO flag was to always signal to try NVMe PRLI. However, there are other FCP-only target arrays in correctly behaved configurations that reject the NVMe PRLI followed by a LOGO leading to never rediscovering the target after an issue_lip (as LOGO causes a repeat of PLOGI/PRLIs). Revert the RSCN_MEMENTO patch as it is causing correctly behaved configs to fail while it exists only to succeed on a misbehaved config. Link: https://lore.kernel.org/r/[email protected] Fixes: 1045592fc968 ("scsi: lpfc: Introduce FC_RSCN_MEMENTO flag for tracking post RSCN completion") Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 873fb210f1c77ecce659fa3a97f310ed5a9d07ed Author: Dan Carpenter <[email protected]> Date: Wed Jun 22 09:21:55 2022 +0300 scsi: qla2xxx: Check correct variable in qla24xx_async_gffid() [ Upstream commit 7c33e477bd883f79cccec418980cb8f7f2d50347 ] There is a copy and paste bug here. It should check ".rsp" instead of ".req". The error message is copy and pasted as well so update that too. Link: https://lore.kernel.org/r/YrK1A/[email protected] Fixes: 9c40c36e75ff ("scsi: qla2xxx: edif: Reduce Initiator-Initiator thrashing") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b7a75acd73434af28e1f93deaed48ba6c38f4463 Author: Dmitry Baryshkov <[email protected]> Date: Tue Jul 5 12:42:53 2022 +0300 phy: qcom-qmp: fix the QSERDES_V5_COM_CMN_MODE register [ Upstream commit 488987b2d5cade4e7680f7e81590435a848d1fa9 ] Change QSERDES_V5_COM_CMN_MODE to be defined to 0x1a0 rather than 0x1a4. The only user of this register name (sm8450_qmp_gen4x2_pcie_serdes_tbl) should use the 0x1a0 register, as stated in the downstream dtsi tree. Fixes: 2c91bf6bf290 ("phy: qcom-qmp: Add SM8450 PCIe1 PHY support") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 81d54873b64bf75d34f8f4f46dd5b559e989ecd9 Author: Shunsuke Mie <[email protected]> Date: Wed Jun 22 13:09:24 2022 +0900 PCI: endpoint: Don't stop controller when unbinding endpoint function [ Upstream commit 1bc2b7bfba6e2f64edf5e246f3af2967261f6c3d ] Unbinding an endpoint function from the endpoint controller shouldn't stop the controller. This is especially a problem for multi-function endpoints where other endpoints may still be active. Don't stop the controller when unbinding one of its endpoints. Normally the controller is stopped via configfs. Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shunsuke Mie <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a93b3f1e11971a91b6441b6d47488f4492cc113f Author: Viacheslav Mitrofanov <[email protected]> Date: Fri Jul 1 11:29:42 2022 +0300 dmaengine: sf-pdma: Add multithread support for a DMA channel [ Upstream commit b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc ] When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 64 > /sys/module/dmatest/parameters/threads_per_chan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one. With current fixes a descriptor changes its value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. Now it is just possible to queue a descriptor for further processing. Fixes: 6973886ad58e ("dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00") Signed-off-by: Viacheslav Mitrofanov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 101e55e02cc84be6eb9e69edc25b56e68e67e137 Author: Quentin Perret <[email protected].com> Date: Tue Jul 5 14:23:10 2022 +0000 KVM: arm64: Don't return from void function [ Upstream commit 1c3ace2b8b3995d3213c5e2d2aca01a0577a3b0f ] Although harmless, the return statement in kvm_unexpected_el2_exception is rather confusing as the function itself has a void return type. The C standard is also pretty clear that "A return statement with an expression shall not appear in a function whose return type is void". Given that this return statement does not seem to add any actual value, let's not pointlessly violate the standard. Build-tested with GCC 10 and CLANG 13 for good measure, the disassembled code is identical with or without the return statement. Fixes: e9ee186bb735 ("KVM: arm64: Add kvm_extable for vaxorcism code") Signed-off-by: Quentin Perret <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 432b30f08ca3303d2ebb22352cb04c4b6cfefe65 Author: Pierre-Louis Bossart <[email protected]> Date: Tue Jun 21 17:56:38 2022 -0500 soundwire: revisit driver bind/unbind and callbacks [ Upstream commit bd29c00edd0a5dac8b6e7332bb470cd50f92e893 ] In the SoundWire probe, we store a pointer from the driver ops into the 'slave' structure. This can lead to kernel oopses when unbinding codec drivers, e.g. with the following sequence to remove machine driver and codec driver. /sbin/modprobe -r snd_soc_sof_sdw /sbin/modprobe -r snd_soc_rt711 The full details can be found in the BugLink below, for reference the two following examples show different cases of driver ops/callbacks being invoked after the driver .remove(). kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150 kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence] kernel: RIP: 0010:mutex_lock+0x19/0x30 kernel: Call Trace: kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae] kernel: ? newidle_balance+0x26a/0x400 kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: BUG: unable to handle page fault for address: ffffffffc07654c8 kernel: Workqueue: pm pm_runtime_work kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus] kernel: Call Trace: kernel: <TASK> kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd] kernel: ? dpm_sysfs_remove+0x60/0x60 This was not detected earlier in Intel tests since the tests first remove the parent PCI device and shut down the bus. The sequence above is a corner case which keeps the bus operational but without a driver bound. While trying to solve this kernel oopses, it became clear that the existing SoundWire bus does not deal well with the unbind case. Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields") added a 'probed' status variable and a 'probe_complete' struct completion. This status is however not reset on remove and likewise the 'probe complete' is not re-initialized, so the bind/unbind/bind test cases would fail. The timeout used before the 'update_status' callback was also a bad idea in hindsight, there should really be no timing assumption as to if and when a driver is bound to a device. An initial draft was based on device_lock() and device_unlock() was tested. This proved too complicated, with deadlocks created during the suspend-resume sequences, which also use the same device_lock/unlock() as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS caused spurious resumes and the use of device_lock() caused hangs during suspend. After multiple weeks or testing and painful reverse-engineering of deadlocks on different devices, we looked for alternatives that did not interfere with the device core. A bus notifier was used successfully to keep track of DRIVER_BOUND and DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests, but it can still be defeated with a theoretical corner case where the memory is freed by a .remove while the callback is in use. The notifier only helps make sure the driver callbacks are valid, but not that the memory allocated in probe remains valid while the callbacks are invoked. This patch suggests the introduction of a new 'sdw_dev_lock' mutex protecting probe/remove and all driver callbacks. Since this mutex is 'local' to SoundWire only, it does not interfere with existing locks and does not create deadlocks. In addition, this patch removes the 'probe_complete' completion, instead we directly invoke the 'update_status' from the probe routine. That removes any sort of timing dependency and a much better support for the device/driver model, the driver could be bound before the bus started, or eons after the bus started and the hardware would be properly initialized in all cases. BugLink: https://github.com/thesofproject/linux/issues/3531 Fixes: 56d4fe31af77 ("soundwire: Add MIPI DisCo property helpers") Fixes: 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields") Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 70ae9224e83b1c734290eb7239785aded899d248 Author: Pierre-Louis Bossart <[email protected]> Date: Fri Jun 10 09:51:05 2022 +0800 soundwire: bus_type: fix remove and shutdown support [ Upstream commit df6407782964dc7e35ad84230abb38f46314b245 ] The bus sdw_drv_remove() and sdw_drv_shutdown() helpers are used conditionally, if the driver provides these routines. These helpers already test if the driver provides a .remove or .shutdown callback, so there's no harm in invoking the sdw_drv_remove() and sdw_drv_shutdown() unconditionally. In addition, the current code is imbalanced with dev_pm_domain_attach() called from sdw_drv_probe(), but dev_pm_domain_detach() called from sdw_drv_remove() only if the driver provides a .remove callback. Fixes: 9251345dca24b ("soundwire: Add SoundWire bus type") Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Rander Wang <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit ccf4269bddbe8d120d0c5492c141f9e009e076ee Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:16 2022 +0300 PCI: dwc: Always enable CDM check if "snps,enable-cdm-check" exists [ Upstream commit ec7b952f453ce7eabe7e1bea584626934d44f668 ] If the "snps,enable-cdm-check" property exists, we should enable the CDM check. But previously dw_pcie_setup() could exit before doing so if the "num-lanes" property was absent or invalid. Move the CDM enable earlier so we do it regardless of whether "num-lanes" is present. [bhelgaas: commit log] Fixes: 07f123def73e ("PCI: dwc: Add support to enable CDM register check") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Vidya Sagar <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3b453f5d06d1f1d6b20a75ea51dc7b53ae78f479 Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:15 2022 +0300 PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors [ Upstream commit 8161e9626b50892eaedbd8070ecb1586ecedb109 ] If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks. [bhelgaas: commit log] Fixes: 2fd0c9d966cc ("PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d71475e422e7347467e855028842e1920c594840 Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:14 2022 +0300 PCI: dwc: Set INCREASE_REGION_SIZE flag based on limit address [ Upstream commit 777e7c3ab73036105e6fc4a67ed950179dbffbab ] We program the 64-bit ATU limit address (in PCIE_ATU_LIMIT/ PCIE_ATU_UPPER_LIMIT or PCIE_ATU_UNR_LOWER_LIMIT/PCIE_ATU_UNR_UPPER_LIMIT), but in addition, the PCIE_ATU_INCREASE_REGION_SIZE bit must be set if the upper 32 bits of the limit address differ from the upper 32 bits of the base address (see [1,2]). 5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU") set PCIE_ATU_INCREASE_REGION_SIZE, but only when the *size* was greater than 4GB. It did not set it when a smaller region crossed a 4GB boundary, e.g., [mem 0x0_f0000000-0x1_0fffffff]. Set PCIE_ATU_INCREASE_REGION_SIZE whenever PCIE_ATU_UPPER_LIMIT is greater than PCIE_ATU_UPPER_BASE. [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v5.40a, March 2019, fig.3-36, p.175 [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v5.40a, March 2019, fig.3-37, p.176 [bhelgaas: commit log] Fixes: 5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 36dbdb257b3f52b6943db01c7842626adb2317a3 Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:13 2022 +0300 PCI: dwc: Disable outbound windows only for controllers using iATU [ Upstream commit d60a2e281e9de2b2f67343b2e39417ca0f4fd54e ] Some DWC-based controllers (e.g., pcie-al.c and pci-keystone.c, identified by the fact that they override the default dw_child_pcie_ops) use their own address translation approach instead of the DWC internal ATU (iATU). For those controllers, skip disabling the iATU outbound windows. [bhelgaas: commit log, update multiple window comment] Fixes: 458ad06c4cdd ("PCI: dwc: Ensure all outbound ATU windows are reset") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e711668aae0f668d2344385514a9cd3315254de4 Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:12 2022 +0300 PCI: dwc: Add unroll iATU space support to dw_pcie_disable_atu() [ Upstream commit d1cf738f2b65a5640234e1da90a68d3523fbed83 ] dw_pcie_disable_atu() was introduced by f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") and supported only the viewport version of the iATU CSRs. DW PCIe IP cores v4.80a and newer also support unrolled iATU/eDMA space. Callers of dw_pcie_disable_atu(), including pci_epc_ops.clear_bar(), pci_epc_ops.unmap_addr(), and dw_pcie_setup_rc(), don't work correctly when it is enabled. Add dw_pcie_disable_atu() support for controllers with unrolled iATU CSRs enabled. [bhelgaas: commit log] Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8b3d4d24fc8616dd62279fdeb7390477961a2085 Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:11 2022 +0300 PCI: dwc: Stop link on host_init errors and de-initialization [ Upstream commit 113fa857b74c947137d845e7e635afcf6a59c43a ] It's logically correct to undo everything that was done when an error is discovered or in the corresponding cleanup counterpart. Otherwise the host controller will be left in an undetermined state. Since the link is set up in the host_init method, deactivate it there in the cleanup-on-error block and stop the link in the antagonistic routine - dw_pcie_host_deinit(). Link deactivation is platform-specific and should be implemented in dw_pcie_ops.stop_link(). Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 14b1f65f2f3ca4570da273e8794f17b67854ed0b Author: Peter Geis <[email protected]> Date: Tue Jun 21 20:31:40 2022 -0400 phy: rockchip-inno-usb2: Sync initial otg state [ Upstream commit 8dc60f8da22fdbaa1fafcfb5ff6d24bc9eff56aa ] The initial otg state for the phy defaults to device mode. The actual state isn't detected until an ID IRQ fires. Fix this by syncing the ID state during initialization. Fixes: 51a9b2c03dd3 ("phy: rockchip-inno-usb2: Handle ID IRQ") Signed-off-by: Peter Geis <[email protected]> Reviewed-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c49616d1f9cf33ed0162dbc0c63e4d0f16e515f5 Author: Andy Shevchenko <[email protected]> Date: Mon Jun 13 19:08:48 2022 +0300 phy: ti: tusb1210: Don't check for write errors when powering on [ Upstream commit d4a0a189b72a7c98e4256292b18b67c69fbc9343 ] On some platforms, like Intel Merrifield, the writing values during power on may timeout: tusb1210 dwc3.0.auto.ulpi: error -110 writing val 0x41 to reg 0x80 phy phy-dwc3.0.auto.ulpi.0: phy poweron failed --> -110 dwc3 dwc3.0.auto: error -ETIMEDOUT: failed to initialize core dwc3: probe of dwc3.0.auto failed with error -110 which effectively fails the probe of the USB controller. Drop the check as it was before the culprit commit (see Fixes tag). Fixes: 09a3512681b3 ("phy: ti: tusb1210: Improve ulpi_read()/_write() error checking") Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Hans de Goede <[email protected]> Tested-by: Ferry Toth <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d1b5113674c3e95bb53c601ce2ea4719e851c74d Author: Tianyu Li <[email protected]> Date: Wed Jun 1 17:32:11 2022 +0800 mm/mempolicy: fix get_nodes out of bound access [ Upstream commit 000eca5d044d1ee23b4ca311793cf3fc528da6c6 ] When user specified more nodes than supported, get_nodes will access nmask array out of bounds. Link: https://lkml.kernel.org/r/[email protected] Fixes: e130242dc351 ("mm: simplify compat numa syscalls") Signed-off-by: Tianyu Li <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 02b8b1b5a98bbc77b8b0e902090fe7b43b974784 Author: Andrey Konovalov <[email protected]> Date: Thu Jun 9 20:18:47 2022 +0200 kasan: fix zeroing vmalloc memory with HW_TAGS [ Upstream commit 6c2f761dad7851d8088b91063ccaea3c970efe78 ] HW_TAGS KASAN skips zeroing page_alloc allocations backing vmalloc mappings via __GFP_SKIP_ZERO. Instead, these pages are zeroed via kasan_unpoison_vmalloc() by passing the KASAN_VMALLOC_INIT flag. The problem is that __kasan_unpoison_vmalloc() does not zero pages when either kasan_vmalloc_enabled() or is_vmalloc_or_module_addr() fail. Thus: 1. Change __vmalloc_node_range() to only set KASAN_VMALLOC_INIT when __GFP_SKIP_ZERO is set. 2. Change __kasan_unpoison_vmalloc() to always zero pages when the KASAN_VMALLOC_INIT flag is set. 3. Add WARN_ON() asserts to check that KASAN_VMALLOC_INIT cannot be set in other early return paths of __kasan_unpoison_vmalloc(). Also clean up the comment in __kasan_unpoison_vmalloc. Link: https://lkml.kernel.org/r/4bc[email protected]google.com Fixes: 23689e91fb22 ("kasan, vmalloc: add vmalloc tagging for HW_TAGS") Signed-off-by: Andrey Konovalov <[email protected]> Cc: Marco Elver <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 35530c1639815cd7848bd6c53d62cf2a40fbfeef Author: Andrey Konovalov <[email protected]> Date: Thu Jun 9 20:18:46 2022 +0200 mm: introduce clear_highpage_kasan_tagged commit d9da8f6cf55eeca642c021912af1890002464c64 upstream. Add a clear_highpage_kasan_tagged() helper that does clear_highpage() on a page potentially tagged by KASAN. This helper is used by the following patch. Link: https://lkml.kernel.org/r/447[email protected]google.com Signed-off-by: Andrey Konovalov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Marco Elver <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Jiri Slaby <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 0a5f45aeca9f5082a676ed99d31590f695cf4285 Author: Miaohe Lin <[email protected]> Date: Mon May 30 19:30:16 2022 +0800 mm/migration: fix potential pte_unmap on an not mapped pte [ Upstream commit ad1ac596e8a8c4b06715dfbd89853eb73c9886b2 ] __migration_entry_wait and migration_entry_wait_on_locked assume pte is always mapped from caller. But this is not the case when it's called from migration_entry_wait_huge and follow_huge_pmd. Add a hugetlbfs variant that calls hugetlb_migration_entry_wait(ptep == NULL) to fix this issue. Link: https://lkml.kernel.org/r/[email protected] Fixes: 30dad30922cc ("mm: migration: add migrate_entry_wait_huge()") Signed-off-by: Miaohe Lin <[email protected]> Suggested-by: David Hildenbrand <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Howells <[email protected]> Cc: Huang Ying <[email protected]> Cc: kernel test robot <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Muchun Song <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Peter Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit b39dbd9b674b81406e2a58966838eed27404d8c9 Author: Miaohe Lin <[email protected]> Date: Mon May 30 19:30:15 2022 +0800 mm/migration: return errno when isolate_huge_page failed [ Upstream commit 7ce82f4c3f3ead13a9d9498768e3b1a79975c4d8 ] We might fail to isolate huge page due to e.g. the page is under migration which cleared HPageMigratable. We should return errno in this case rather than always return 1 which could confuse the user, i.e. the caller might think all of the memory is migrated while the hugetlb page is left behind. We make the prototype of isolate_huge_page consistent with isolate_lru_page as suggested by Huang Ying and rename isolate_huge_page to isolate_hugetlb as suggested by Muchun to improve the readability. Link: https://lkml.kernel.org/r/[email protected] Fixes: e8db67eb0ded ("mm: migrate: move_pages() supports thp migration") Signed-off-by: Miaohe Lin <[email protected]> Suggested-by: Huang Ying <[email protected]> Reported-by: kernel test robot <[email protected]> (build error) Cc: Alistair Popple <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Howells <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Muchun Song <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: Peter Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 42c3e36ee76e39d84be0da7fc91da8e35ac33bb8 Author: Yang Shi <[email protected]> Date: Sun Jul 3 18:08:36 2022 -0700 mm: rmap: use the correct parameter name for DEFINE_PAGE_VMA_WALK [ Upstream commit 507db7927cd181d409dd495c8384b8e14c21c600 ] The parameter used by DEFINE_PAGE_VMA_WALK is _page not page, fix the parameter name. It didn't cause any build error, it is probably because the only caller is write_protect_page() from ksm.c, which pass in page. Link: https://lkml.kernel.org/r/[email protected] Fixes: 2aff7a4755be ("mm: Convert page_vma_mapped_walk to work on PFNs") Signed-off-by: Yang Shi <[email protected]> Reviewed-by: Muchun Song <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Cc: Muchun Song <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4a9f35b8729c5bf13ea671c908c17ed74c48fc50 Author: Yushan Zhou <[email protected]> Date: Thu Jun 30 16:25:12 2022 +0800 kernfs: fix potential NULL dereference in __kernfs_remove [ Upstream commit 72b5d5aef246a0387cefa23121dd90901c7a691a ] When lockdep is enabled, lockdep_assert_held_write would cause potential NULL pointer dereference. Fix the following smatch warnings: fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check 'kn' (see line 1346) Fixes: 393c3714081a ("kernfs: switch global kernfs_rwsem lock to per-fs lock") Signed-off-by: Yushan Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit a0c4d1ebfaee6af04e00b6a8d9cbfe1d26506a3e Author: Nikita Travkin <[email protected]> Date: Sun Jun 12 19:59:53 2022 +0500 clk: qcom: clk-rcg2: Make sure to not write d=0 to the NMD register [ Upstream commit d0696770cef35a1fd16ea2167e2198c18aa6fbfe ] Sometimes calculation of d value may result in 0 because of the rounding after integer division. This causes the following error: [ 113.969689] camss_gp1_clk_src: rcg didn't update its configuration. [ 113.969754] WARNING: CPU: 3 PID: 35 at drivers/clk/qcom/clk-rcg2.c:122 update_config+0xc8/0xdc Make sure that D value is never zero. Fixes: 7f891faf596e ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Nikita Travkin <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 23526845a84b3c7fa20c9cc860d3b34e1513ab14 Author: Nikita Travkin <[email protected]> Date: Sun Jun 12 19:59:52 2022 +0500 clk: qcom: clk-rcg2: Fail Duty-Cycle configuration if MND divider is not enabled. [ Upstream commit bdafb609c3bb848d710ad9cd4debd2ee9d6a4049 ] In cases when MND is not enabled (e.g. when only Half Integer Divider is used), setting D registers makes no effect. Fail instead of making ineffective write. Fixes: 7f891faf596e ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Nikita Travkin <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c29bc42790e83d41c51f50568590870f49711878 Author: Vladimir Zapolskiy <[email protected]> Date: Fri May 20 00:41:33 2022 +0300 clk: qcom: camcc-sm8250: Fix topology around titan_top power domain [ Upstream commit f8acf01a6a4f84baf05181e24bd48def4ba23f5b ] On SM8250 two found VFE GDSC power domains shall not be operated, if titan top is turned off, thus the former power domains will be set as subdomains by a GDSC registration routine. Fixes: 5d66ca79b58c ("clk: qcom: Add camera clock controller driver for SM8250") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 5467cdf879c70493905580fe6c846202c4f7d8b5 Author: Vladimir Zapolskiy <[email protected]> Date: Fri May 20 00:41:32 2022 +0300 clk: qcom: camcc-sdm845: Fix topology around titan_top power domain [ Upstream commit 103dd2338bbff567bce7acd00fc5a09c806b38ec ] On SDM845 two found VFE GDSC power domains shall not be operated, if titan top is turned off, thus the former power domains will be set as subdomains by a GDSC registration routine. Fixes: 78412c262004 ("clk: qcom: Add camera clock controller driver for SDM845") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a86b76f573b9d383e3cd3922d60e736d2f528fad Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:43 2022 +0200 clk: qcom: ipq8074: set BRANCH_HALT_DELAY flag for UBI clocks [ Upstream commit 2bd357e698207e2e65db03007e4be65bf9d6a7b3 ] Currently, attempting to enable the UBI clocks will cause the stuck at off warning to be printed and clk_enable will fail. [ 14.936694] gcc_ubi1_ahb_clk status stuck at 'off' Downstream 5.4 QCA kernel has fixed this by seting the BRANCH_HALT_DELAY flag on UBI clocks, so lets do the same. Fixes: 5736294aef83 ("clk: qcom: ipq8074: add NSS clocks") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 950d25e77894220d5fb256190197fb941badf1e0 Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:40 2022 +0200 clk: qcom: ipq8074: fix NSS port frequency tables [ Upstream commit 0e9e61a2815b5cd34f1b495b2d72e8127ce9b794 ] NSS port 5 and 6 frequency tables are currently broken and are causing a wide ranges of issue like 1G not working at all on port 6 or port 5 being clocked with 312 instead of 125 MHz as UNIPHY1 gets selected. So, update the frequency tables with the ones from the downstream QCA 5.4 based kernel which has already fixed this. Fixes: 7117a51ed303 ("clk: qcom: ipq8074: add NSS ethernet port clocks") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit abd86837d72e054aaf5e05edf5af74fa4602a2cf Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:39 2022 +0200 clk: qcom: ipq8074: SW workaround for UBI32 PLL lock [ Upstream commit 3401ea2856ef84f39b75f0dc5ebcaeda81cb90ec ] UBI32 Huayra PLL fails to lock in 5 us in some SoC silicon and thus it will cause the wait_for_pll() to timeout and thus return the error indicating that the PLL failed to lock. This is bug in Huayra PLL HW for which SW workaround is to set bit 26 of TEST_CTL register. This is ported from the QCA 5.4 based downstream kernel. Fixes: b8e7e519625f ("clk: qcom: ipq8074: add remaining PLL’s") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2086f388fa9e3020cecaad2c45406745265f073a Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:38 2022 +0200 clk: qcom: ipq8074: fix NSS core PLL-s [ Upstream commit ca41ec1b30434636c56c5600b24a8d964d359d9c ] Like in IPQ6018 the NSS related Alpha PLL-s require initial configuration to work. So, obtain the regmap that is required for the Alpha PLL configuration and thus utilize the qcom_cc_really_probe() as we already have the regmap. Then utilize the Alpha PLL configs from the downstream QCA 5.4 based kernel to configure them. This fixes the UBI32 and NSS crypto PLL-s failing to get enabled by the kernel. Fixes: b8e7e519625f ("clk: qcom: ipq8074: add remaining PLL’s") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 0073eda15921a3212fdf8f6f716e31a2edb7db36 Author: Bob Pearson <[email protected]> Date: Mon May 23 17:32:52 2022 -0500 RDMA/rxe: Fix deadlock in rxe_do_local_ops() [ Upstream commit 7cb33d1bc1ac8e51fd88928f96674d392f8e07c4 ] When a local operation (invalidate mr, reg mr, bind mw) is finished there will be no ack packet coming from a responder to cause the wqe to be completed. This may happen anyway if a subsequent wqe performs IO. Currently if the wqe is signalled the completer tasklet is scheduled immediately but not otherwise. This leads to a deadlock if the next wqe has the fence bit set in send flags and the operation is not signalled. This patch removes the condition that the wqe must be signalled in order to schedule the completer tasklet which is the simplest fix for this deadlock and is fairly low cost. This is the analog for local operations of always setting the ackreq bit in all last or only request packets even if the operation is not signalled. Link: https://lore.kernel.org/r/[email protected] Reported-by: Jenny Hack <[email protected]> Fixes: c1a411268a4b ("RDMA/rxe: Move local ops to subroutine") Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 3065415763069b3cd3f7d1277d763e77b570e12e Author: Bob Pearson <[email protected]> Date: Mon Jun 6 09:38:34 2022 -0500 RDMA/rxe: Add a responder state for atomic reply [ Upstream commit 0ed5493e430a1d887eb62b45c75dd5d6bb2dcf48 ] Add a responder state for atomic reply similar to read reply and rename process_atomic() rxe_atomic_reply(). In preparation for merging the normal and retry atomic responder flows. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 1dd6ea298dc65a00b1d8542530a26c2b9c4511de Author: Sergey Shtylyov <[email protected]> Date: Thu Jun 30 15:46:45 2022 +0300 usb: host: xhci: use snprintf() in xhci_decode_trb() [ Upstream commit 1ce69c35b86038dd11d3a6115a04501c5b89a940 ] Commit cbf286e8ef83 ("xhci: fix unsafe memory usage in xhci tracing") apparently missed one sprintf() call in xhci_decode_trb() -- replace it with the snprintf() call as well... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: cbf286e8ef83 ("xhci: fix unsafe memory usage in xhci tracing") Signed-off-by: Sergey Shtylyov <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 8444b1369fef7f9c3f57fa74c96a9e2dd3a5d8f0 Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:35 2022 +0100 clk: qcom: gcc-msm8939: Point MM peripherals to system_mm_noc clock [ Upstream commit 05eed0990927aa9634682fec58660e30f7b7ae30 ] Qcom docs indciate the following peripherals operating from System NOC MM not from System NOC clocks. - MDP - VFE - JPEGe - Venus Switch over the relevant parent pointers. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b410b931ff3d64cf5df52d3e3725a1840866314d Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:34 2022 +0100 clk: qcom: gcc-msm8939: Add missing system_mm_noc_bfdcd_clk_src [ Upstream commit dd363e2f7196278e7a30f509a0e8a841cb763b14 ] The msm8939 has an additional higher operating point for the multi-media peripherals. The higher throughput MM componets operate off of the system-mm noc not the system noc. system_mm_noc_bfdcd_clk_src is the source clock for the higher frequency capable system noc mm. Maximum frequency for the MM SNOC is 400 MHz. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit f17eb596f9f7aaffbbbe81b99aa8f703fc5f97ca Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:33 2022 +0100 clk: qcom: gcc-msm8939: Fix bimc_ddr_clk_src rcgr base address [ Upstream commit 63d42708320d6d2ca9ed505123d50ff4a542c36f ] Reviewing qcom docs for the 8939 we can see the command rcgr is pointing to the wrong address. bimc_ddr_clk_src_rcgr is @ 0x01832024 not 0x01832004. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 8a1f5c67422dd91c5a514acb18a735168bfe8d81 Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:32 2022 +0100 clk: qcom: gcc-msm8939: Add missing SYSTEM_MM_NOC_BFDCD_CLK_SRC [ Upstream commit 07e7fcf1714c5f9930ad27613fea940aedba68da ] When adding in the indexes for this clock-controller we missed SYSTEM_MM_NOC_BFDCD_CLK_SRC. Add it in now. Fixes: 4c71d6abc4fc ("clk: qcom: Add DT bindings for MSM8939 GCC") Cc: Rob Herring <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 38b4908e767f6ae1a82ae589298da115ddd87516 Author: Neal Liu <[email protected]> Date: Tue Jun 28 10:14:36 2022 +0800 usb: gadget: f_mass_storage: Make CD-ROM emulation works with Windows OS [ Upstream commit 3b91edd624ab1ab694deef513a45eb9e9d49d75f ] Add read TOC with format 1 to support CD-ROM emulation with Windows OS. This patch is tested on Windows OS Server 2019. Fixes: 89ada0fe669a ("usb: gadget: f_mass_storage: Make CD-ROM emulation work with Mac OS-X") Reviewed-by: Alan Stern <[email protected]> Signed-off-by: Neal Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 517ce24958f06bbcaf4e32aa664187e3feb1a135 Author: Mike Leach <[email protected]> Date: Tue Jun 28 18:30:04 2022 +0100 coresight: syscfg: Update load and unload operations [ Upstream commit 8add26f7ef33bba7984cb6ff7911c6aa970fe55a ] The configfs system is a source of access to the config information in the configuration and feature lists. This can result in additional LOCKDEP issues as a result of the mutex ordering between the config list mutex (cscfg_mutex) and the configfs system mutexes. As such we need to adjust how load/unload operations work to ensure correct operation. 1) Previously the cscfg_mutex was held throughout the load/unload operation. This is now only held during configuration list manipulations, resulting in a multi-stage load/unload process. 2) All operations that manipulate the configfs representation of the configurations and features are now separated out and run without the cscfg_mutex being held. This avoids circular lock_dep issue with the built-in configfs mutexes and semaphores 3) As the load and unload is now multi-stage, some parts under the cscfg_mutex and others not: i) A flag indicating a load / unload operation in progress is used to serialise load / unload operations. ii) activating any configuration not possible when unload is in progress. iii) Configurations have an "available" flag set only after the last load stage for the configuration is complete. Activation of the configuration not possible till flag is set. 4) Following load/unload rules remain: i) Unload prevented while any configuration is active remains. ii) Unload in strict reverse order of load. iii) Existing configurations can be activated while a new load operation is underway. (by definition there can be no dependencies between an existing configuration and a new loading one due to ii) above.) Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules") Reported-by: Suzuki Poulose <[email protected]> Signed-off-by: Mike Leach <[email protected]> Reviewed-and-tested-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 471a84356c357190484992254bd493f8f3eb491f Author: Mike Leach <[email protected]> Date: Tue Jun 28 18:30:03 2022 +0100 coresight: configfs: Fix unload of configurations on module exit [ Upstream commit 199380decc5f9188a9e65676031950f1734aaffe ] Any loaded configurations must be correctly unloaded on coresight module exit, or issues can arise with nested locking in the configfs directory code if built with CONFIG_LOCKDEP. Prior to this patch, the preloaded configuration configfs directory entries were being unloaded by the recursive code in configfs_unregister_subsystem(). However, when built with CONFIG_LOCKDEP, this caused a nested lock warning, which was not mitigated by the LOCKDEP dependent code in fs/configfs/dir.c designed to prevent this, due to the different directory levels for the root of the directory being removed. As the preloaded (and all other) configurations are registered after configfs_register_subsystem(), we now explicitly unload them before the call to configfs_unregister_subsystem(). The new routine cscfg_unload_cfgs_on_exit() iterates through the load owner list to unload any remaining configurations that were not unloaded by the user before the module exits. This covers both the CSCFG_OWNER_PRELOAD and CSCFG_OWNER_MODULE owner types, and will be extended to cover future load owner types for CoreSight configurations. Fixes: eb2ec49606c2 ("coresight: syscfg: Update load API for config loadable modules") Reported-by: Suzuki Poulose <[email protected]> Signed-off-by: Mike Leach <[email protected]> Reviewed-and-tested-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9007c92c1b490374f5f2c7cb379c10e7ed2b3cb6 Author: Christian Marangi <[email protected]> Date: Sat Apr 30 07:44:57 2022 +0200 clk: qcom: clk-krait: unlock spin after mux completion [ Upstream commit df83d2c9e72910416f650ade1e07cc314ff02731 ] Unlock spinlock after the mux switch is completed to prevent any corner case of mux request while the switch still needs to be done. Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks") Signed-off-by: Ansuel Smith <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 37f908038402c9b8325763f306a1c65d88757e15 Author: Zhang Wensheng <[email protected]> Date: Wed Jun 22 15:43:27 2022 +0800 driver core: fix potential deadlock in __driver_attach [ Upstream commit 70fe758352cafdee72a7b13bf9db065f9613ced8 ] In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). stack like commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As above show, when it is allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute instead. it will lead to A-A deadlock because of __driver_attach_async_helper getting lock dev. Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like below: [ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00004000 [ 370.788865] Call Trace: [ 370.789374] <TASK> [ 370.789841] __schedule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __mutex_lock.isra.0+0x757/0xec0 [ 370.793158] __mutex_lock_slowpath+0x1f/0x30 [ 370.794079] mutex_lock+0x50/0x60 [ 370.794795] __device_driver_lock+0x2f/0x70 [ 370.795677] ? driver_probe_device+0xd0/0xd0 [ 370.796576] __driver_attach_async_helper+0x1d/0xd0 [ 370.797318] ? driver_probe_device+0xd0/0xd0 [ 370.797957] async_schedule_node_domain+0xa5/0xc0 [ 370.798652] async_schedule_node+0x19/0x30 [ 370.799243] __driver_attach+0x246/0x290 [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801666] bus_add_driver+0x290/0x340 [ 370.802246] driver_register+0x88/0x140 [ 370.802817] ? virtio_scsi_init+0x116/0x116 [ 370.803425] scsi_register_driver+0x1a/0x30 [ 370.804057] init_sd+0x184/0x226 [ 370.804533] do_one_initcall+0x71/0x3a0 [ 370.805107] kernel_init_freeable+0x39a/0x43a [ 370.805759] ? rest_init+0x150/0x150 [ 370.806283] kernel_init+0x26/0x230 [ 370.806799] ret_from_fork+0x1f/0x30 To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver") Signed-off-by: Zhang Wensheng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c4eb8f43965b729886229551445a493c4b06e211 Author: Christophe JAILLET <[email protected]> Date: Wed Jun 15 07:33:44 2022 +0200 misc: rtsx: Fix an error handling path in rtsx_pci_probe() [ Upstream commit 44fd1917314e9d4f53dd95dd65df1c152f503d3a ] If an error occurs after a successful idr_alloc() call, the corresponding resource must be released with idr_remove() as already done in the .remove function. Update the error handling path to add the missing idr_remove() call. Fixes: ada8a8a13b13 ("mfd: Add realtek pcie card reader driver") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/e8dc41716cb[email protected]wanadoo.fr Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 18a32f18062bc9bdb39e546f896eff85c30d8aa9 Author: Vladimir Zapolskiy <[email protected]> Date: Wed May 18 13:35:54 2022 +0300 clk: qcom: camcc-sm8250: Fix halt on boot by reducing driver's init level [ Upstream commit c4f40351901a10cd662ac2c081396d8fb04f584d ] Access to I/O of SM8250 camera clock controller IP depends on enabled GCC_CAMERA_AHB_CLK clock supplied by global clock controller, the latter one is inited on subsys level, so, to satisfy the dependency, it would make sense to deprive the init level of camcc-sm8250 driver. If both drivers are compiled as built-in, there is a change that a board won't boot up due to a race, which happens on the same init level. Fixes: 5d66ca79b58c ("clk: qcom: Add camera clock controller driver for SM8250") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 864548b1ccdfeda5d9e675901de55648383166c6 Author: Mark Brown <[email protected]> Date: Mon Jun 20 16:23:13 2022 +0100 mtd: dataflash: Add SPI ID table [ Upstream commit ac4f83482afbfd927d0fe118151b747cf175e724 ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 219f5478099cefc92e0f3dcea213b81b2de70e51 Author: Geert Uytterhoeven <[email protected]> Date: Fri Jun 17 11:26:51 2022 +0200 mtd: hyperbus: rpc-if: Fix RPM imbalance in probe error path [ Upstream commit c223a38d62e57aa60a890ea7247e3c58a54478e6 ] If rpcif_hw_init() fails, Runtime PM is left enabled. Fixes: b04cc0d912eb80d3 ("memory: renesas-rpc-if: Add support for RZ/G2L") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/f3070e[email protected]glider.be Signed-off-by: Sasha Levin <[email protected]> commit 43bfa481072d5261584a1d9f69a87196d5b4b6e3 Author: Ben Gardon <[email protected]> Date: Mon Jun 13 21:25:20 2022 +0000 KVM: x86: Fix errant brace in KVM capability handling [ Upstream commit 1c4dc57328bf218e999951824dce75c6125c4f3c ] The braces around the KVM_CAP_XSAVE2 block also surround the KVM_CAP_PMU_CAPABILITY block, likely the result of a merge issue. Simply move the curly brace back to where it belongs. Fixes: ba7bb663f5547 ("KVM: x86: Provide per VM capability for disabling PMU virtualization") Reviewed-by: David Matlack <[email protected]> Reviewed-by: Peter Xu <[email protected]> Signed-off-by: Ben Gardon <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 82f7fac052c396974151aa96359c695073db821b Author: Serge Semin <[email protected]> Date: Tue May 24 10:21:57 2022 -0500 dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics [ Upstream commit c1e33979171da63cf47e56243ccb8ba82363c7d3 ] In accordance with [1, 2] the DW eDMA controller has been created to be part of the DW PCIe Root Port and DW PCIe End-point controllers and to offload the transferring of large blocks of data between application and remote PCIe domains leaving the system CPU free for other tasks. In the first case (eDMA being part of DW PCIe Root Port) the eDMA controller is always accessible via the CPU DBI interface and never over the PCIe wire. The latter case is more complex. Depending on the DW PCIe End-Point IP-core synthesize parameters it's possible to have the eDMA registers accessible not only from the application CPU side, but also via mapping the eDMA CSRs over a dedicated endpoint BAR. So based on the specifics denoted above the eDMA driver is supposed to support two types of the DMA controller setups: 1) eDMA embedded into the DW PCIe Root Port/End-point and accessible over the local CPU from the application side. 2) eDMA embedded into the DW PCIe End-point and accessible via the PCIe wire with MWr/MRd TLPs generated by the CPU PCIe host controller. Since the CPU memory resides different sides in these cases the semantics of the MEM_TO_DEV and DEV_TO_MEM operations is flipped with respect to the Tx and Rx DMA channels. So MEM_TO_DEV/DEV_TO_MEM corresponds to the Tx/Rx channels in setup 1) and to the Rx/Tx channels in case of setup 2). The DW eDMA driver has supported the case 2) since e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") in the framework of the drivers/dma/dw-edma/dw-edma-pcie.c driver. The case 1) support was added later by bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics"). Afterwards the driver was supposed to cover the both possible eDMA setups, but the latter commit turned out to be not fully correct. The problem was that the commit together with the new functionality support also changed the channel direction semantics so the eDMA Read-channel (corresponding to the DMA_DEV_TO_MEM direction for case 1) now uses the sgl/cyclic base addresses as the Source addresses of the DMA transfers and dma_slave_config.dst_addr as the Destination address of the DMA transfers. Similarly the eDMA Write-channel (corresponding to the DMA_MEM_TO_DEV direction for case 1) now uses dma_slave_config.src_addr as a source address of the DMA transfers and sgl/cyclic base address as the Destination address of the DMA transfers. This contradicts the logic of the DMA-interface, which implies that DEV side is supposed to belong to the PCIe device memory and MEM - to the CPU/Application memory. Indeed it seems irrational to have the SG-list defined in the PCIe bus space, while expecting a contiguous buffer allocated in the CPU memory. Moreover the passed SG-list and cyclic DMA buffers are supposed to be mapped in a way so to be seen by the DW eDMA Application (CPU) interface. So in order to have the correct DW eDMA interface we need to invert the eDMA Rd/Wr-channels and DMA-slave directions semantics by selecting the src/dst addresses based on the DMA transfer direction instead of using the channel direction capability. [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v.5.40a, March 2019, p.1092 [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint, v.5.40a, March 2019, p.1189 Co-developed-by: Manivannan Sadhasivam <[email protected]> Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]ctronics.ru> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-By: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 984be156c3b51f0da8598dba4926ee0e027ee268 Author: Mike Christie <[email protected]> Date: Thu Jun 16 17:27:38 2022 -0500 scsi: iscsi: Fix session removal on shutdown [ Upstream commit 31500e902759322ba3c64b60dabae2704e738df8 ] When the system is shutting down, iscsid is not running so we will not get a response to the ISCSI_ERR_INVALID_HOST error event. The system shutdown will then hang waiting on userspace to remove the session. This has libiscsi force the destruction of the session from the kernel when iscsi_host_remove() is called from a driver's shutdown callout. This fixes a regression added in qedi boot with commit d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions") which made qedi use the common session removal function that waits on userspace instead of rolling its own kernel based removal. Link: https://lore.kernel.org/r/[email protected] Fixes: d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions") Tested-by: Nilesh Javali <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Nilesh Javali <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9bb43a58d195d47579692211c65bb116b2a7c6f4 Author: Mike Christie <[email protected]> Date: Thu Jun 16 17:27:36 2022 -0500 scsi: iscsi: Add helper to remove a session from the kernel [ Upstream commit bb42856bfd54fda1cbc7c470fcf5db1596938f4f ] During qedi shutdown we need to stop the iSCSI layer from sending new nops as pings and from responding to target ones and make sure there is no running connection cleanups. Commit d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions") converted the driver to use the libicsi helper to drive session removal, so the above issues could be handled. The problem is that during system shutdown iscsid will not be running so when we try to remove the root session we will hang waiting for userspace to reply. Add a helper that will drive the destruction of sessions like these during system shutdown. Link: https://lore.kernel.org/r/[email protected] Tested-by: Nilesh Javali <[email protected]> Reviewed-by: Nilesh Javali <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 0ccf5a803820ee5516b706a4a8fe8aefc2e6679a Author: Mike Christie <[email protected]> Date: Thu Jun 16 17:27:34 2022 -0500 scsi: iscsi: Allow iscsi_if_stop_conn() to be called from kernel [ Upstream commit 3328333b47f4163504267440ec0a36087a407a5f ] iscsi_if_stop_conn() is only called from the userspace interface but in a subsequent commit we will want to call it from the kernel interface to allow drivers like qedi to remove sessions from inside the kernel during shutdown. This removes the iscsi_uevent code from iscsi_if_stop_conn() so we can call it in a new helper. Link: https://lore.kernel.org/r/[email protected] Tested-by: Nilesh Javali <[email protected]> Reviewed-by: Nilesh Javali <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c8e8b8b9f23a0c68855ecfc756b96be6c9946ec1 Author: Duoming Zhou <[email protected]> Date: Tue Jun 7 11:26:26 2022 +0800 mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv [ Upstream commit a52ed4866d2b90dd5e4ae9dabd453f3ed8fa3cbc ] There are sleep in atomic context bugs when uploading device dump data in mwifiex. The root cause is that dev_coredumpv could not be used in atomic contexts, because it calls dev_set_name which include operations that may sleep. The call tree shows execution paths that could lead to bugs: (Interrupt context) fw_dump_timer_fn mwifiex_upload_device_dump dev_coredumpv(..., GFP_KERNEL) dev_coredumpm() kzalloc(sizeof(*devcd), gfp); //may sleep dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep The corresponding fail log is shown below: [ 135.275938] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start [ 135.281029] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265 ... [ 135.293613] Call Trace: [ 135.293613] <IRQ> [ 135.293613] dump_stack_lvl+0x57/0x7d [ 135.293613] __might_resched.cold+0x138/0x173 [ 135.293613] ? dev_coredumpm+0xca/0x2e0 [ 135.293613] kmem_cache_alloc_trace+0x189/0x1f0 [ 135.293613] ? devcd_match_failing+0x30/0x30 [ 135.293613] dev_coredumpm+0xca/0x2e0 [ 135.293613] ? devcd_freev+0x10/0x10 [ 135.293613] dev_coredumpv+0x1c/0x20 [ 135.293613] ? devcd_match_failing+0x30/0x30 [ 135.293613] mwifiex_upload_device_dump+0x65/0xb0 [ 135.293613] ? mwifiex_dnld_fw+0x1b0/0x1b0 [ 135.293613] call_timer_fn+0x122/0x3d0 [ 135.293613] ? msleep_interruptible+0xb0/0xb0 [ 135.293613] ? lock_downgrade+0x3c0/0x3c0 [ 135.293613] ? __next_timer_interrupt+0x13c/0x160 [ 135.293613] ? lockdep_hardirqs_on_prepare+0xe/0x220 [ 135.293613] ? mwifiex_dnld_fw+0x1b0/0x1b0 [ 135.293613] __run_timers.part.0+0x3f8/0x540 [ 135.293613] ? call_timer_fn+0x3d0/0x3d0 [ 135.293613] ? arch_restore_msi_irqs+0x10/0x10 [ 135.293613] ? lapic_next_event+0x31/0x40 [ 135.293613] run_timer_softirq+0x4f/0xb0 [ 135.293613] __do_softirq+0x1c2/0x651 ... [ 135.293613] RIP: 0010:default_idle+0xb/0x10 [ 135.293613] RSP: 0018:ffff888006317e68 EFLAGS: 00000246 [ 135.293613] RAX: ffffffff82ad8d10 RBX: ffff888006301cc0 RCX: ffffffff82ac90e1 [ 135.293613] RDX: ffffed100d9ff1b4 RSI: ffffffff831ad140 RDI: ffffffff82ad8f20 [ 135.293613] RBP: 0000000000000003 R08: 0000000000000000 R09: ffff88806cff8d9b [ 135.293613] R10: ffffed100d9ff1b3 R11: 0000000000000001 R12: ffffffff84593410 [ 135.293613] R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff11000c62fd2 ... [ 135.389205] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end This patch uses delayed work to replace timer and moves the operations that may sleep into a delayed work in order to mitigate bugs, it was tested on Marvell 88W8801 chip whose port is usb and the firmware is usb8801_uapsta.bin. The following is the result after using delayed work to replace timer. [ 134.936453] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start [ 135.043344] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end As we can see, there is no bug now. Fixes: f5ecd02a8b20 ("mwifiex: device dump support for usb interface") Reviewed-by: Brian Norris <[email protected]> Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected]zju.edu.cn Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <s[email protected]> commit e6a4d422002bf46bca0ae350782e03da5fd28188 Author: Duoming Zhou <[email protected]> Date: Tue Jun 7 11:26:25 2022 +0800 devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm [ Upstream commit 77515ebaf01920e2db49e04672ef669a7c2907f2 ] The dev_coredumpv() and dev_coredumpm() could not be used in atomic context, because they call kvasprintf_const() and kstrdup() with GFP_KERNEL parameter. The process is shown below: dev_coredumpv(.., gfp_t gfp) dev_coredumpm(.., gfp_t gfp) dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep This patch removes gfp_t parameter of dev_coredumpv() and dev_coredumpm() and changes the gfp_t parameter of kzalloc() in dev_coredumpm() to GFP_KERNEL in order to show they could not be used in atomic context. Fixes: 833c95456a70 ("device coredump: add new device coredump class") Reviewed-by: Brian Norris <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected]zju.edu.cn Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 2b1a324933bdda27b00c877d3cd3a6bac3a01440 Author: Sean Christopherson <[email protected]> Date: Tue Apr 19 11:35:28 2022 -0700 KVM: selftests: Use vm_create_with_vcpus() in max_guest_memory_test [ Upstream commit 3468fd7d883110e481dfb8c8c7b802dc252ab186 ] Use vm_create_with_vcpus() in max_guest_memory_test and reference vCPUs by their 'struct kvm_vcpu' object instead of their ID. Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5bb7f541d07dc63131519ae13a3bdee022ab054e Author: Sean Christopherson <[email protected]> Date: Wed Feb 16 12:40:18 2022 -0800 KVM: selftests: Convert s390x/diag318_test_handler away from VCPU_ID [ Upstream commit 7cdcdfe50d8d68b7b9ba2e1b0345ff47fdda390f ] Convert diag318_test_handler to use vm_create_with_vcpus() and pass around a 'struct kvm_vcpu' object instead of passing around vCPU IDs. Note, this is a "functional" change in the sense that the test now creates a vCPU with vcpu_id==0 instead of vcpu_id==6. The non-zero VCPU_ID was 100% arbitrary and added little to no validation coverage. If testing non-zero vCPU IDs is desirable for generic tests, that can be done in the future by tweaking the VM creation helpers. Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit d225591d016bf1dc544d7f1d69bd336c21836cc7 Author: Sean Christopherson <[email protected]> Date: Fri Apr 29 01:04:09 2022 +0000 KVM: Don't set Accessed/Dirty bits for ZERO_PAGE [ Upstream commit a1040b0d42acf69bb4f6dbdc54c2dcd78eea1de5 ] Don't set Accessed/Dirty bits for a struct page with PG_reserved set, i.e. don't set A/D bits for the ZERO_PAGE. The ZERO_PAGE (or pages depending on the architecture) should obviously never be written, and similarly there's no point in marking it accessed as the page will never be swapped out or reclaimed. The comment in page-flags.h is quite clear that PG_reserved pages should be managed only by their owner, and strictly following that mandate also simplifies KVM's logic. Fixes: 7df003c85218 ("KVM: fix overflow of zero page refcount with ksm running") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <20220429010416.2788472-4-seanj[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e4aed16c42adabdf9743933eb3b4d30b6a8f3434 Author: Miaohe Lin <[email protected]> Date: Thu Jun 9 20:13:05 2022 +0800 mm/memremap: fix memunmap_pages() race with get_dev_pagemap() [ Upstream commit 1e57ffb6e3fd9583268c6462c4e3853575b21701 ] Think about the below scene: CPU1 CPU2 memunmap_pages percpu_ref_exit __percpu_ref_exit free_percpu(percpu_count); /* percpu_count is freed here! */ get_dev_pagemap xa_load(&pgmap_array, PHYS_PFN(phys)) /* pgmap still in the pgmap_array */ percpu_ref_tryget_live(&pgmap->ref) if __ref_is_percpu /* __PERCPU_REF_ATOMIC_DEAD not set yet */ this_cpu_inc(*percpu_count) /* access freed percpu_count here! */ ref->percpu_count_ptr = __PERCPU_REF_ATOMIC_DEAD; /* too late... */ pageunmap_range To fix the issue, do percpu_ref_exit() after pgmap_array is emptied. So we won't do percpu_ref_tryget_live() against a being freed percpu_ref. Link: https://lkml.kernel.org/r/[email protected] Fixes: b7b3c01b1915 ("mm/memremap_pages: support multiple ranges per invocation") Signed-off-by: Miaohe Lin <[email protected]> Cc: Dan Williams <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 7e71aafa652acbb358b157e4be867c00d3847654 Author: Miaohe Lin <[email protected]> Date: Thu Jun 9 21:08:35 2022 +0800 lib/test_hmm: avoid accessing uninitialized pages [ Upstream commit ed913b055a74b723976f8e885a3395162a0371e6 ] If make_device_exclusive_range() fails or returns pages marked for exclusive access less than required, remaining fields of pages will left uninitialized. So dmirror_atomic_map() will access those yet uninitialized fields of pages. To fix it, do dmirror_atomic_map() iff all pages are marked for exclusive access (we will break if mapped is less than required anyway) so we won't access those uninitialized fields of pages. Link: https://lkml.kernel.org/r/[email protected] Fixes: b659baea7546 ("mm: selftests for exclusive device memory") Signed-off-by: Miaohe Lin <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Ralph Campbell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 6d8682d45df46bfed5f4983bd9d6e2b64c453f92 Author: Dongliang Mu <[email protected]> Date: Thu Jun 9 15:06:56 2022 +0800 RDMA/rxe: fix xa_alloc_cycle() error return value check again [ Upstream commit 1a685940e6200e9def6e34bbaa19dd31dc5aeaf8 ] Currently rxe_alloc checks ret to indicate error, but 1 is also a valid return and just indicates that the allocation succeeded with a wrap. Fix this by modifying the check to be < 0. Link: https://lore.kernel.org/r/[email protected] Fixes: 3225717f6dfa ("RDMA/rxe: Replace red-black trees by xarrays") Signed-off-by: Dongliang Mu <[email protected]> Reviewed-by: Bob Pearson <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 5067b776620e197f5bd54426b3d66d8f9b029777 Author: Peng Fan <[email protected]nxp.com> Date: Thu Jun 9 21:29:01 2022 +0800 clk: imx: clk-fracn-gppll: correct rdiv [ Upstream commit f300cb7fccf69ba1835b983c76d70deb818ad194 ] According to Reference Manual: 000b - Divide by 1 001b - Divide by 1 010b - Divide by 2 011b - Divide by 3 100b - Divide by 4 101b - Divide by 5 110b - Divide by 6 111b - Divide by 7 So only need increase rdiv by 1 when the register value is 0. Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 10348c6693b106e6f2c86189a9151b13ee100294 Author: Liu Ying <[email protected]> Date: Thu Jun 9 21:29:00 2022 +0800 clk: imx: clk-fracn-gppll: Return rate in rate table properly in ->recalc_rate() [ Upstream commit 5ebaf9f7da5bb2dc56d394eabfcbe46dc6b1ea8d ] The PLL parameters in rate table should be directly compared with those read from PLL registers instead of the cooked ones. Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll") Cc: Abel Vesa <[email protected]> Cc: Michael Turquette <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: NXP Linux Team <[email protected]> Cc: Peng Fan <[email protected]> Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Peng Fan <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit e0fad1a5362c51e1237f8448f3bb64f3c697f9de Author: Peng Fan <[email protected]> Date: Thu Jun 9 21:28:59 2022 +0800 clk: imx: clk-fracn-gppll: fix mfd value [ Upstream commit 044034efbeea05f65c09d2ba15ceeab53b60e947 ] According to spec: A value of 0 is disallowed and should not be programmed in this register Fix to 1. Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit c94e191f791a51c28033ed9fe36eae7b7cd8c0de Author: Peng Fan <[email protected]> Date: Thu Jun 9 21:28:57 2022 +0800 clk: imx93: correct nic_media parent [ Upstream commit 1e3c837a663e9a12c4afabb3279d18cb5110a8f4 ] NIC_MEDIA sources from media_axi_root, not media_apb_root. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit bcf40bc61c2d1047b8398f9f76fac84e94f7adec Author: Haibo Chen <[email protected]> Date: Thu Jun 9 21:28:56 2022 +0800 clk: imx93: use adc_root as the parent clock of adc1 [ Upstream commit 18d6d8fe4f24938985844d52c481b86fcce9d102 ] When debug, find after system boot up, all adc register operation will trigger system hang, this is because the internal adc ipg clock is gate off. In dts, only reference the IMX93_CLK_ADC1_GATE, which is adc1, no one touch the adc_root, so adc_root will be gate off automatically after system boot up. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Jacky Bai <[email protected]> Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Peng Fan <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 9e969b0b91a835a01398d81036d60a04aa000ea5 Author: Rex-BC Chen <[email protected]> Date: Mon May 23 17:33:29 2022 +0800 clk: mediatek: reset: Fix written reset bit offset [ Upstream commit edabcf71d100fd433a0fc2d0c97057c446c33b2a ] Original assert/deassert bit is BIT(0), but it's more resonable to modify them to BIT(id % 32) which is based on id. This patch will not influence any previous driver because the reset is only used for thermal. The id (MT8183_INFRACFG_AO_THERM_SW_RST) is 0. Fixes: 64ebb57a3df6 ("clk: reset: Modify reset-controller driver") Signed-off-by: Rex-BC Chen <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Nícolas F. R. A. Prado <[email protected]> Tested-by: Nícolas F. R. A. Prado <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]> commit 4fe070b5d5af15301c970c525e908895822f7633 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:12 2022 +0100 iio: temp: maxim_thermocouple: Fix alignment for DMA safety [ Upstream commit 10897f34309b3c7bc14698407436c82d11c07f47 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition Fixes: 1f25ca11d84a ("iio: temperature: add support for Maxim thermocouple chips") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Matt Ranostay <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4f7a71a85c8e39bcd0fee3ec1d109f40f05184bd Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:11 2022 +0100 iio: temp: max31865: Fix alignment for DMA safety [ Upstream commit ecdef5b8317cdf18acb46223e087f04a226fa619 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition Fixes: e112dc4e18ea ("iio: temperature: Add MAX31865 RTD Support") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Navin Sankar Velliangiri <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 114ffd465579162368a463b70390e36057af303d Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:10 2022 +0100 iio: temp: ltc2983: Fix alignment for DMA safety [ Upstream commit 732f2cb2fbb51bd5bc03a114bd102ab3b2f537fe ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: f110f3188e56 ("iio: temperature: Add support for LTC2983") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3af5ec85f49d86ba225fdf043a2675e2733e4735 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:09 2022 +0100 iio: resolver: ad2s90: Fix alignment for DMA safety [ Upstream commit faa05ecb1349070d874810e161b653c2220e0006 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes tag is probably not where the issue was first introduced, but is likely to be far beyond the point where anyone considers backporting this fix. Fixes: 58f08b0af857 ("staging:iio:resolver:ad2s90 general cleanup") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c00e752df981f442af8e1e87a6f3a5d630b7ecdd Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:08 2022 +0100 iio: resolver: ad2s1200: Fix alignment for DMA safety [ Upstream commit 37882314d3bdc2ae775ebb9fa8ed7a94cd1aad61 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes tag is probably not where the issue was first introduced, but is likely to be as far as anyone considers backporting this fix. Fixes: 0bd3d338f61b ("staging: iio: ad2s1200: Improve readability with be16_to_cpup") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 59ee01f39242e76de27f935505f02122af97f386 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:06 2022 +0100 iio: proximity: as3935: Fix alignment for DMA safety [ Upstream commit 2386c0f8c5b740873a4b9126c3706601b127fe22 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 24ddb0e4bba4 ("iio: Add AS3935 lightning sensor support") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Matt Ranostay <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 5179a573724f9612beee56056c12c44a6874bab6 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:04 2022 +0100 iio: potentiometer: mcp4131: Fix alignment for DMA safety [ Upstream commit 4842e5de6f39ebf2c0f6da9e6a0cb751c7108507 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 22d199a53910 ("iio: potentiometer: add driver for Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 51143f66752745405c2fcb075808699421d7c0d4 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:03 2022 +0100 iio: potentiometer: mcp41010: Fix alignment for DMA safety [ Upstream commit c5f78f4d2168ba21324095b0d46d4353c2eace4d ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 092cb71a604e ("iio: potentiometer: Add driver for Microchip MCP41xxx/42xxx") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 903e5ff430d678facab4fe2ed37bd2f65f194ce1 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:02 2022 +0100 iio: potentiometer: max5481: Fix alignment for DMA safety [ Upstream commit ec1ac1c0e7a14657d729159ccfbea72f434bdaf1 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: df1fd2de118e ("iio: max5481: Add support for Maxim digital potentiometers") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit b39859bf3e10ae5e04794e4e257306503db644e5 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:01 2022 +0100 iio: potentiometer: ad5272: Fix alignment for DMA safety [ Upstream commit da803652534271dbb4af0802bd678c759e27e6de ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 79e8a32d2aa9 ("iio: ad5272: Add support for Analog Devices digital potentiometers") Signed-off-by: Jonathan Cameron <[email protected]> Reviewed-by: Phil Reid <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 669a1aca327459fb36266d7e352c0febd2011a5a Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:57:00 2022 +0100 iio: potentiometer: ad5110: Fix alignment for DMA safety [ Upstream commit b5841c38cb2f7e54b0787b3e0326a6b21b89ea3e ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: d03a74bfacce ("iio: potentiometer: Add driver support for AD5110") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Mugilraj Dhavachelvan <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit ad602e33470842b7ee50a87d930f16201b4c4892 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:59 2022 +0100 iio: imu: mpu6050: Fix alignment for DMA safety [ Upstream commit 54e03562bb960e78af050d2e550c28d77642ee44 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 6b0cc5dce072 ("iio:imu:inv_mpu6050 Fix dma and ts alignment and data leak issues.") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Jean-Baptiste Maneyrol <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c5cf267aa73f4ebdd354849f26ca0fb582401c1d Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:58 2022 +0100 iio: imu: inv_icm42600: Fix alignment for DMA safety in buffer code. [ Upstream commit b0aa05065a0c1d1bffa10923dbc36f7193babbb7 ] Second fix for this driver due to different introducing patches. ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 7f85e42a6c54 ("iio: imu: inv_icm42600: add buffer support in iio devices") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Jean-Baptiste Maneyrol <[email protected]> Acked-by: Jean-Baptiste Maneyrol <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit bc0f8830ff2eb1332abc8b7f7b6d71e4048714db Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:57 2022 +0100 iio: imu: inv_icm42600: Fix alignment for DMA safety [ Upstream commit 848847702bd10bf0bf547e38adc44c14e9742784 ] Partial fix for this driver as a second instance was introduced in a later patch. ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: a095fadb443b ("iio: imu: inv_icm42600: add gyroscope IIO device") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Jean-Baptiste Maneyrol <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 750b892f6d08a390bd477378fe6162f9ab513f4f Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:56 2022 +0100 iio: imu: fxos8700: Fix alignment for DMA safety [ Upstream commit c9a8417a13ed9c81383662fca8a4b89f84d31e78 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 84e5ddd5c46e ("iio: imu: Add support for the FXOS8700 IMU") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Robert Jones <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 48f034120d1e43cf15af9e913e2656dc1bed1c65 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:55 2022 +0100 iio: gyro: fxas210002c: Fix alignment for DMA safety [ Upstream commit 3aafe923987cb4a15e16f03c6185ed4b6a78ca00 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Updated the comment to 'may' require. Fixes: a0701b6263ae ("iio: gyro: add core driver for fxas21002c") Signed-off-by: Jonathan Cameron <[email protected]> Reviewed-by: Rui Miguel Silva <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit dd8e2a2b9f63b1121134fe28c14c8ffd6554b7c4 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:54 2022 +0100 iio: gyro: adxrs450: Fix alignment for DMA safety [ Upstream commit 966d2f4ee7f6e189df47abf67223266ad31e201f ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes tag is inaccurate but unlikely anyone will be interested in backporting beyond that point. Fixes: 53ac8500ba9b ("staging:iio:adxrs450: Move header file contents to main file") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d10b2c4c9a77ba26a92d4d195f58904efee14d56 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:53 2022 +0100 iio: gyro: adis16130: Fix alignment for DMA safety [ Upstream commit ff3211b2ba9afac80ceb795d148831dd879b30b7 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 8e67875141b2 ("staging:iio:gyro: adis16130 cleanup, move to abi and bug fixes.") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3caad4fd0e3eb8b999de6918dce1c96dbe33e125 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:52 2022 +0100 iio: gyro: adis16080: Fix alignment for DMA safety [ Upstream commit ae6eeb534924ecc2afd5a394964fd6de0ca54d39 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes tag is inaccurate but unlikely anyone will backport this beyond that point so I haven't chased the history futher than 2013. Fixes: 3c80372dae17 ("staging:iio:adis16080: be16 cleanups") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit e525b311339556974710ff40cb1d241eec40889e Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:51 2022 +0100 iio: frequency: adrf6780: Fix alignment for DMA safety [ Upstream commit 9a5b11884cb72780cb824cac8aab47094654a84f ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 63aaf6d06d87 ("iio: frequency: adrf6780: add support for ADRF6780") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Antoniu Miclaus <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 40e10f398c676291f8440330ea972f447729b2cd Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:50 2022 +0100 iio: frequency: admv4420: Fix alignment for DMA safety [ Upstream commit f890aaac771bd015c348eddb967b4027e88344c0 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: b59c04155901 ("iio: frequency: admv4420.c: Add support for ADMV4420") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 99994f124d9d68d011df60380879ab4320e9adf8 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:49 2022 +0100 iio: frequency: admv1014: Fix alignment for DMA safety [ Upstream commit a3e38a557a54df0edea791d7eb623515bb86e39a ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: f4eb9ac7842f ("iio: frequency: admv1014: add support for ADMV1014") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Antoniu Miclaus <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 817d7b7436ae273659c9257676d4699b84176e79 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:48 2022 +0100 iio: frequency: admv1013: Fix alignment for DMA safety [ Upstream commit b3f3f8d264b9be0cb3e50e89e3f8789a948a43bb ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Antoniu Miclaus <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit ce119d7b52001d7d2a817f7ee89ebf7b34cd8159 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:47 2022 +0100 iio: frequency: adf4371: Fix alignment for DMA safety [ Upstream commit 0bb5675befe666eeed71ad808426cf2ec1c9a714 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 7f699bd14913 ("iio: frequency: adf4371: Add support for ADF4371 PLL") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 0d9ce7682d9a4f5c9951e7e78fd46125a3d9cce7 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:46 2022 +0100 iio: frequency: adf4350: Fix alignment for DMA safety [ Upstream commit 389b8972eb2a614cb3189e5fa55b1b7f66142c71 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Updated help text to 'may' require buffers to be in their own cacheline. Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit cc7b3068c795663b75bec8806520e6a9d117985c Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:45 2022 +0100 iio: frequency: ad9523: Fix alignment for DMA safety [ Upstream commit 8ff2eb625c353b1491d9f89f1dfd52e7aef5734c ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Updated help text to 'may' require buffers to be in their own cacheline. Fixes: cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 33fcddee1999dad22cc7b36fdbe282ad73d9ec9b Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:44 2022 +0100 iio: dac: ti-dac7612: Fix alignment for DMA safety [ Upstream commit b9ac08b3282a95fcefb057c2886028a6807725d8 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Updated help text to 'may' require buffers to be in their own cacheline. Fixes: 977724d20584 ("iio:dac:ti-dac7612: Add driver for Texas Instruments DAC7612") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Ricardo Ribalda <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit d8aa41f4d8e63ebc688f2589c25387a8728408e4 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:43 2022 +0100 iio: dac: ti-dac7311: Fix alignment for DMA safety [ Upstream commit 3637c49ed54632d7c221af718d2d7b1d381d4b6e ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 7a02ef7907d8 ("iio:dac:ti-dac7311 Add driver for Texas Instrument DAC7311") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Charles-Antoine Couret <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 450562e3d562b050892bda17fb0c590e8b4a4b7f Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:42 2022 +0100 iio: dac: ti-dac5571: Fix alignment for DMA safety [ Upstream commit 58e22371539e01c742be5c30295f591a6a17e348 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Sean Nyekjaer <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c8942b7c25d50ee3bf294f093aa86784bcdaa134 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:41 2022 +0100 iio: dac: ti-dac082s085: Fix alignment for DMA safety [ Upstream commit 03a0cc77f164e4e59b970d50c6e9a6caf06dae80 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 61011264c1af ("iio: dac: Add Texas Instruments 8/10/12-bit 2/4-channel DAC driver") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 7aa18f077fb0730ee50bbdecaeadc2b7808a4886 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:40 2022 +0100 iio: dac: mcp4922: Fix alignment for DMA safety [ Upstream commit e66bf04797f1f95a2402414c00e64d00f63d31ec ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 1b791fadf3a1 ("iio: dac: mcp4902/mcp4912/mcp4922 dac driver") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Acked-by: Michael Welling <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 21cd3bb91b1eca9886d54c7ab7e12a4209dd7aee Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:39 2022 +0100 iio: dac: ltc2688: Fix alignment for DMA safety [ Upstream commit 2030708377a219b548a9a36da57d3852382baf1d ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: 832cb9eeb931 ("iio: dac: add support for ltc2688") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 8e23928dcb35f1f2e9bddb726b69b2ade05549a5 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:38 2022 +0100 iio: dac: ad8801: Fix alignment for DMA safety [ Upstream commit 1c20292c6b60cfc60a5e652174b8063e5cc03fec ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 7f270bc9a2d9 ("iio: dac: AD8801: add Analog Devices AD8801/AD8803 support") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 1d62ff49669f05ca633e489d4e7489ba975bd8f1 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:37 2022 +0100 iio: dac: ad7303: Fix alignment for DMA safety [ Upstream commit 69e51448ddfb9062efdf83e2d3179498e0aeb293 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: f83478240e74 ("iio:dac: Add support for the AD7303") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 6819e3ac1aeae360d23499c07b5cd45b6b21dfdf Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:36 2022 +0100 iio: dac: ad7293: Fix alignment for DMA safety [ Upstream commit 8482468b30bdb16d4a764f995d7a63d94fa0cf40 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 0bb12606c05f ("iio:dac:ad7293: add support for AD7293") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Antoniu Miclaus <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3b4f0dca7956172caa03330761c32bcdcec56a7e Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:35 2022 +0100 iio: dac: ad5791: Fix alignment for DMA saftey [ Upstream commit b2d5e9de77c8774a5a6cff59d928f2fa38cbc642 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 791bb52a0cd2 ("iio:ad5791: Do not store transfer buffers on the stack") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 369235dc62c402437747f9c8347b37d59aed1303 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:34 2022 +0100 iio: dac: ad5770r: Fix alignment for DMA safety [ Upstream commit 27f2261d16d01858b8e5baca5a1a515b040429c4 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: cbbb819837f6 ("iio: dac: ad5770r: Add AD5770R support") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Alexandru Tachici <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 4d20fe3d45c1372af9ff236a5a6f7d53075f6d05 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:33 2022 +0100 iio: dac: ad5766: Fix alignment for DMA safety [ Upstream commit c32be7f035ae430ba9c142b03ceb9f935b09ed6b ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: fd9373e41b9b ("iio: dac: ad5766: add driver support for AD5766") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 49713818d578ac378ce2979156ebdbf28474f99d Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:32 2022 +0100 iio: dac: ad5764: Fix alignment for DMA safety [ Upstream commit b378722a3e9bb51318c0de7eeb4d71f2fcd6987f ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: 68b14d7ea956 ("staging:iio:dac: Add AD5764 driver") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit c0c4bb0311b47a4c26d093bbd22d08d7eebb57af Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:31 2022 +0100 iio: dac: ad5761: Fix alignment for DMA safety [ Upstream commit 7d12a61187aed57863c41032acbc1fae516d6e49 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: 131497acd88a ("iio: add ad5761 DAC driver") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2d3a77561c42659a9f53c6c36f0d7e284854942b Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:30 2022 +0100 iio: dac: ad5755: Fix alignment for DMA safety [ Upstream commit d0c167ceff2d833ee493dd58164dc87bd36e48aa ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: c499d029d805 ("iio:dac: Add ad5755 driver") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 3a5423cc991ab9f8175352391bfb50a2069f443e Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:29 2022 +0100 iio: dac: ad5686: Fix alignment for DMA safety [ Upstream commit 444e38927d9af093de7cdc6afbb7afdc3485da2d ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: 0357e488b825 ("iio:dac:ad5686: Refactor the driver") Signed-off-by: Jonathan Cameron <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9748b6c196e86d7047f168e2550ce8f277e8325a Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:28 2022 +0100 iio: dac: ad5592r: Fix alignment for DMA safety [ Upstream commit 4a4a79c06caeec47003bcbee1cf3094479f26e24 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Paul Cercueil <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit cee702a2792da21b88f6b7a1663f0c800f82c1f6 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:27 2022 +0100 iio: dac: ad5504: Fix alignment for DMA safety [ Upstream commit 00b9737caa5aaed5cf45a7c7498edf5957efa3b2 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Fixes: 0dbe59c7a788 ("iio:ad5504: Do not store transfer buffers on the stack") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 2179debf1e24406ce294e2d4162e97d0e048531c Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:26 2022 +0100 iio: dac: ad5449: Fix alignment for DMA safety [ Upstream commit 678d536bb454e3bbedcaa68208550ac9dc1cc066 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: 8341dc04dfb3 ("iio:dac: Add support for the ad5449") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit a0bc019a086eec664ca4aecdb2bb1c03accb38dc Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:25 2022 +0100 iio: dac: ad5421: Fix alignment for DMA safety [ Upstream commit d2b240d3d31c66df4d2da54c75ff8e27a0e006c3 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: 5691b23489db ("staging:iio:dac: Add AD5421 driver") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit 9f7a41a64a4b638bf09ce3421ff8756d27c65323 Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:24 2022 +0100 iio: dac: ad5360: Fix alignment for DMA safety [ Upstream commit 94ec314e1bd686b669c24385ce2dbc967eb74147 ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to include 'may'. Fixes: a3e2940c24d3 ("staging:iio:dac: Add AD5360 driver") Signed-off-by: Jonathan Cameron <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Acked-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]> commit cec6ad48e0ad7b658e756f97c5a274772e07e47e Author: Jonathan Cameron <[email protected]> Date: Sun May 8 18:56:23 2022 +0100 iio: dac: ad5064: Fix alignment for DMA safety [ Upstream commit 8779b88c214fa0f8fdfb9c54a124f468884d356a ] ____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. Update the comment to