kernel/linux.git, branch v5.19.2

Linux 5.19.2

2022-08-17T13:16:21+00:00

Link: https://lore.kernel.org/r/20220815180439.416659447@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Ronald Warsow Tested-by: Bagas Sanjaya Tested-by: Ron Economos Link: https://lore.kernel.org/r/20220816124610.393032991@linuxfoundation.org Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Guenter Roeck Tested-by: Jiri Slaby Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman

vxlan: Use ip_tunnel_key flow flags in route lookups

2022-08-17T13:16:21+00:00

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 Signed-off-by: Daniel Borkmann Reviewed-by: Nikolay Aleksandrov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/1ffc95c3d60182fd5ec0cf6602083f8f68afe98f.1658759380.git.paul@isovalent.com Signed-off-by: Greg Kroah-Hartman

geneve: Use ip_tunnel_key flow flags in route lookups

2022-08-17T13:16:21+00:00

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 Signed-off-by: Daniel Borkmann Reviewed-by: Nikolay Aleksandrov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/fcc2e0eea01e8ea465a180126366ec20596ba530.1658759380.git.paul@isovalent.com Signed-off-by: Greg Kroah-Hartman

ASoC: Intel: avs: Use lookup table to create modules

2022-08-17T13:16:21+00:00

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/YtlzY9aYdbS4Y3+l@dev-arch.thelio-3990X/T/ Link: https://github.com/ClangBuiltLinux/linux/issues/1642 Signed-off-by: Amadeusz Sławiński Reported-by: Nathan Chancellor Build-tested-by: Nathan Chancellor Reviewed-by: Cezary Rojewski Link: https://lore.kernel.org/r/20220722111959.2588597-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Cc: Naresh Kamboju Signed-off-by: Greg Kroah-Hartman

Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression

2022-08-17T13:16:21+00:00

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 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman

io_uring: mem-account pbuf buckets

2022-08-17T13:16:21+00:00

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: Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/d34c452e45793e978d26e2606211ec9070d329ea.1659622312.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

powerpc/kexec: Fix build failure from uninitialised variable

2022-08-17T13:16:21+00:00

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 Signed-off-by: Russell Currey Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220810054331.373761-1-ruscur@russell.cc Signed-off-by: Greg Kroah-Hartman

Revert "s390/smp: enforce lowcore protection on CPU restart"

2022-08-17T13:16:20+00:00

commit 953503751a426413ea8aee2299ae3ee971b70d9b upstream. This reverts commit 6f5c672d17f583b081e283927f5040f726c54598. This breaks normal crash dump when CPU0 is offline. Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman

net: dsa: felix: fix min gate len calculation for tc when its first gate is closed

2022-08-17T13:16:20+00:00

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 Link: https://lore.kernel.org/r/20220804202817.1677572-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

tracing: Use a copy of the va_list for __assign_vstr()

2022-08-17T13:16:20+00:00

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/259d53a5-958e-6508-4e45-74dba2821242@marvell.com/ Link: https://lkml.kernel.org/r/20220719182004.21daa83e@gandalf.local.home Fixes: 0563231f93c6d ("tracing/events: Add __vstring() and __assign_vstr() helper macros") Reported-by: Arun Easi Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman