user/sven/linux.git, branch v6.1.30

Linux 6.1.30

2023-05-24T16:32:53Z

Link: https://lore.kernel.org/r/20230522190405.880733338@linuxfoundation.org Tested-by: Chris Paterson (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Theodore Ts'o Tested-by: Bagas Sanjaya Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Linux Kernel Functional Testing Tested-by: Conor Dooley Tested-by: Markus Reichelt Tested-by: Ron Economos Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: reserve the old gc_11_0_*_mes.bin

2023-05-24T16:32:53Z

commit 8855818ce7554fb7420200187fac9c3b69500da0 upstream. Reserve the MOUDLE_FIRMWARE declaration of gc_11_0_*_mes.bin to fix falling back to old mes bin on failure via autoload. Fixes: 97998b893c30 ("drm/amd/amdgpu: introduce gc_*_mes_2.bin v2") Signed-off-by: Li Ma Reviewed-by: Yifan Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/amdgpu: introduce gc_*_mes_2.bin v2

2023-05-24T16:32:53Z

commit 97998b893c3000b27a780a4982e16cfc8f4ea555 upstream. To avoid new mes fw running with old driver, rename mes schq fw to gc_*_mes_2.bin. v2: add MODULE_FIRMWARE declaration v3: squash in fixup patch Signed-off-by: Jack Xiao Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: declare firmware for new MES 11.0.4

2023-05-24T16:32:53Z

commit a462ef872fd1e83ebd075cf82d91f111acaa629e upstream. To support new mes ip block Signed-off-by: Li Ma Reviewed-by: Yifan Zhang Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

crypto: testmgr - fix RNG performance in fuzz tests

2023-05-24T16:32:53Z

commit f900fde28883602b6c5e1027a6c912b673382aaf upstream. The performance of the crypto fuzz tests has greatly regressed since v5.18. When booting a kernel on an arm64 dev board with all software crypto algorithms and CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled, the fuzz tests now take about 200 seconds to run, or about 325 seconds with lockdep enabled, compared to about 5 seconds before. The root cause is that the random number generation has become much slower due to commit d4150779e60f ("random32: use real rng for non-deterministic randomness"). On my same arm64 dev board, at the time the fuzz tests are run, get_random_u8() is about 345x slower than prandom_u32_state(), or about 469x if lockdep is enabled. Lockdep makes a big difference, but much of the rest comes from the get_random_*() functions taking a *very* slow path when the CRNG is not yet initialized. Since the crypto self-tests run early during boot, even having a hardware RNG driver enabled (CONFIG_CRYPTO_DEV_QCOM_RNG in my case) doesn't prevent this. x86 systems don't have this issue, but they still see a significant regression if lockdep is enabled. Converting the "Fully random bytes" case in generate_random_bytes() to use get_random_bytes() helps significantly, improving the test time to about 27 seconds. But that's still over 5x slower than before. This is all a bit silly, though, since the fuzz tests don't actually need cryptographically secure random numbers. So let's just make them use a non-cryptographically-secure RNG as they did before. The original prandom_u32() is gone now, so let's use prandom_u32_state() instead, with an explicitly managed state, like various other self-tests in the kernel source tree (rbtree_test.c, test_scanf.c, etc.) already do. This also has the benefit that no locking is required anymore, so performance should be even better than the original version that used prandom_u32(). Fixes: d4150779e60f ("random32: use real rng for non-deterministic randomness") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

remoteproc: imx_dsp_rproc: Fix kernel test robot sparse warning

2023-05-24T16:32:53Z

[ Upstream commit 3c497f624d40171ebead1a6705793100d92ecb85 ] This patch fixes the kernel test robot warning reported here: https://lore.kernel.org/bpf/642f916b.pPIKZ%2Fl%2F%2Fbw8tvIH%25lkp@intel.com/T/ Fixes: 408ec1ff0caa ("remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores") Link: https://lore.kernel.org/r/20230407161429.3973177-1-mathieu.poirier@linaro.org Tested-by: Iuliana Prodan Reviewed-by: Iuliana Prodan Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin

rethook, fprobe: do not trace rethook related functions

2023-05-24T16:32:53Z

commit 571a2a50a8fc546145ffd3bf673547e9fe128ed2 upstream. These functions are already marked as NOKPROBE to prevent recursion and we have the same reason to blacklist them if rethook is used with fprobe, since they are beyond the recursion-free region ftrace can guard. Link: https://lore.kernel.org/all/20230517034510.15639-5-zegao@tencent.com/ Fixes: f3a112c0c40d ("x86,rethook,kprobes: Replace kretprobe with rethook on x86") Signed-off-by: Ze Gao Reviewed-by: Steven Rostedt (Google) Acked-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

rethook: use preempt_{disable, enable}_notrace in rethook_trampoline_handler

2023-05-24T16:32:52Z

commit be243bacfb25f5219f2396d787408e8cf1301dd1 upstream. This patch replaces preempt_{disable, enable} with its corresponding notrace version in rethook_trampoline_handler so no worries about stack recursion or overflow introduced by preempt_count_{add, sub} under fprobe + rethook context. Link: https://lore.kernel.org/all/20230517034510.15639-2-zegao@tencent.com/ Fixes: 54ecbe6f1ed5 ("rethook: Add a generic return hook") Signed-off-by: Ze Gao Acked-by: Masami Hiramatsu (Google) Cc: Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

arm64: mte: Do not set PG_mte_tagged if tags were not initialized

2023-05-24T16:32:52Z

commit c4c597f1b367433c52c531dccd6859a39b4580fb upstream. The mte_sync_page_tags() function sets PG_mte_tagged if it initializes page tags. Then we return to mte_sync_tags(), which sets PG_mte_tagged again. At best, this is redundant. However, it is possible for mte_sync_page_tags() to return without having initialized tags for the page, i.e. in the case where check_swap is true (non-compound page), is_swap_pte(old_pte) is false and pte_is_tagged is false. So at worst, we set PG_mte_tagged on a page with uninitialized tags. This can happen if, for example, page migration causes a PTE for an untagged page to be replaced. If the userspace program subsequently uses mprotect() to enable PROT_MTE for that page, the uninitialized tags will be exposed to userspace. Fix it by removing the redundant call to set_page_mte_tagged(). Fixes: e059853d14ca ("arm64: mte: Fix/clarify the PG_mte_tagged semantics") Signed-off-by: Peter Collingbourne Cc: # 6.1 Link: https://linux-review.googlesource.com/id/Ib02d004d435b2ed87603b858ef7480f7b1463052 Reviewed-by: Catalin Marinas Reviewed-by: Alexandru Elisei Link: https://lore.kernel.org/r/20230420214327.2357985-1-pcc@google.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

s390/qdio: fix do_sqbs() inline assembly constraint

2023-05-24T16:32:52Z

commit 2862a2fdfae875888e3c1c3634e3422e01d98147 upstream. Use "a" constraint instead of "d" constraint to pass the state parameter to the do_sqbs() inline assembly. This prevents that general purpose register zero is used for the state parameter. If the compiler would select general purpose register zero this would be problematic for the used instruction in rsy format: the register used for the state parameter is a base register. If the base register is general purpose register zero the contents of the register are unexpectedly ignored when the instruction is executed. This only applies to z/VM guests using QIOASSIST with dedicated (pass through) QDIO-based devices such as FCP [zfcp driver] as well as real OSA or HiperSockets [qeth driver]. A possible symptom for this case using zfcp is the following repeating kernel message pattern: zfcp : A QDIO problem occurred zfcp : A QDIO problem occurred zfcp : qdio: ZFCP on SC using AI:1 QEBSM:1 PRI:1 TDD:1 SIGA: W zfcp : A QDIO problem occurred zfcp : A QDIO problem occurred Each of the qdio problem message can be accompanied by the following entries for the affected subchannel in /sys/kernel/debug/s390dbf/qdio_error/hex_ascii for zfcp or qeth: ccq: 69.... SQBS ERROR. Reviewed-by: Benjamin Block Cc: Steffen Maier Fixes: 8129ee164267 ("[PATCH] s390: qdio V=V pass-through") Cc: Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman