kernel/linux.git/include, branch v6.6.2

net/sched: act_ct: Always fill offloading tuple iifidx

2023-11-20T10:59:37+00:00

[ Upstream commit 9bc64bd0cd765f696fcd40fc98909b1f7c73b2ba ] Referenced commit doesn't always set iifidx when offloading the flow to hardware. Fix the following cases: - nf_conn_act_ct_ext_fill() is called before extension is created with nf_conn_act_ct_ext_add() in tcf_ct_act(). This can cause rule offload with unspecified iifidx when connection is offloaded after only single original-direction packet has been processed by tc data path. Always fill the new nf_conn_act_ct_ext instance after creating it in nf_conn_act_ct_ext_add(). - Offloading of unidirectional UDP NEW connections is now supported, but ct flow iifidx field is not updated when connection is promoted to bidirectional which can result reply-direction iifidx to be zero when refreshing the connection. Fill in the extension and update flow iifidx before calling flow_offload_refresh(). Fixes: 9795ded7f924 ("net/sched: act_ct: Fill offloading tuple iifidx") Reviewed-by: Paul Blakey Signed-off-by: Vlad Buslov Reviewed-by: Simon Horman Fixes: 6a9bad0069cf ("net/sched: act_ct: offload UDP NEW connections") Link: https://lore.kernel.org/r/20231103151410.764271-1-vladbu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

Fix termination state for idr_for_each_entry_ul()

2023-11-20T10:59:35+00:00

[ Upstream commit e8ae8ad479e2d037daa33756e5e72850a7bd37a9 ] The comment for idr_for_each_entry_ul() states after normal termination @entry is left with the value NULL This is not correct in the case where UINT_MAX has an entry in the idr. In that case @entry will be non-NULL after termination. No current code depends on the documentation being correct, but to save future code we should fix it. Also fix idr_for_each_entry_continue_ul(). While this is not documented as leaving @entry as NULL, the mellanox driver appears to depend on it doing so. So make that explicit in the documentation as well as in the code. Fixes: e33d2b74d805 ("idr: fix overflow case for idr_for_each_entry_ul()") Cc: Matthew Wilcox Cc: Chris Mi Cc: Cong Wang Signed-off-by: NeilBrown Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

inet: shrink struct flowi_common

2023-11-20T10:59:34+00:00

[ Upstream commit 1726483b79a72e0150734d5367e4a0238bf8fcff ] I am looking at syzbot reports triggering kernel stack overflows involving a cascade of ipvlan devices. We can save 8 bytes in struct flowi_common. This patch alone will not fix the issue, but is a start. Fixes: 24ba14406c5c ("route: Add multipath_hash in flowi_common to make user-define hash") Signed-off-by: Eric Dumazet Cc: wenxu Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20231025141037.3448203-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

mfd: core: Un-constify mfd_cell.of_reg

2023-11-20T10:59:23+00:00

[ Upstream commit 3c70342f1f0045dc827bb2f02d814ce31e0e0d05 ] Enable dynamically filling in the whole mfd_cell structure. All other fields already allow that. Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/b73fe4bc4bd6ba1af90940a640ed65fe254c0408.1693253717.git.mirq-linux@rere.qmqm.pl Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

crypto: hisilicon/qm - fix PF queue parameter issue

2023-11-20T10:59:20+00:00

[ Upstream commit 5831fc1fd4a578232fea708b82de0c666ed17153 ] If the queue isolation feature is enabled, the number of queues supported by the device changes. When PF is enabled using the current default number of queues, the default number of queues may be greater than the number supported by the device. As a result, the PF fails to be bound to the driver. After modification, if queue isolation feature is enabled, when the default queue parameter is greater than the number supported by the device, the number of enabled queues will be changed to the number supported by the device, so that the PF and driver can be properly bound. Fixes: 8bbecfb402f7 ("crypto: hisilicon/qm - add queue isolation support for Kunpeng930") Signed-off-by: Longfang Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

hwrng: bcm2835 - Fix hwrng throughput regression

2023-11-20T10:59:18+00:00

[ Upstream commit b58a36008bfa1aadf55f516bcbfae40c779eb54b ] The last RCU stall fix caused a massive throughput regression of the hwrng on Raspberry Pi 0 - 3. hwrng_msleep doesn't sleep precisely enough and usleep_range doesn't allow scheduling. So try to restore the best possible throughput by introducing hwrng_yield which interruptable sleeps for one jiffy. Some performance measurements on Raspberry Pi 3B+ (arm64/defconfig): sudo dd if=/dev/hwrng of=/dev/null count=1 bs=10000 cpu_relax ~138025 Bytes / sec hwrng_msleep(1000) ~13 Bytes / sec hwrng_yield ~2510 Bytes / sec Fixes: 96cb9d055445 ("hwrng: bcm2835 - use hwrng_msleep() instead of cpu_relax()") Link: https://lore.kernel.org/linux-arm-kernel/bc97ece5-44a3-4c4e-77da-2db3eb66b128@gmx.net/ Signed-off-by: Stefan Wahren Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

KEYS: Include linux/errno.h in linux/verification.h

2023-11-20T10:59:18+00:00

[ Upstream commit 0a596b0682a7ce37e26c36629816f105c6459d06 ] Add inclusion of linux/errno.h as otherwise the reference to EINVAL may be invalid. Fixes: f3cf4134c5c6 ("bpf: Add bpf_lookup_*_key() and bpf_key_put() kfuncs") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202308261414.HKw1Mrip-lkp@intel.com/ Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

ASoC: cs35l41: Fix broken shared boost activation

2023-11-20T10:59:17+00:00

[ Upstream commit 77bf613f0bf08c021309cdb5f84b5f630b829261 ] Enabling the active/passive shared boosts requires setting SYNC_EN, but *not* before receiving the PLL Lock signal. Due to improper error handling, it was not obvious that waiting for the completion operation times out and, consequently, the shared boost is never activated. Further investigations revealed the signal is triggered while snd_pcm_start() is executed, right after receiving the SNDRV_PCM_TRIGGER_START command, which happens long after the SND_SOC_DAPM_PRE_PMU event handler is invoked as part of snd_pcm_prepare(). That is where cs35l41_global_enable() is called from. Increasing the wait duration doesn't help, as it only causes an unnecessary delay in the invocation of snd_pcm_start(). Moving the wait and the subsequent regmap operations to the SNDRV_PCM_TRIGGER_START callback is not a solution either, since they would be executed in an IRQ-off atomic context. Solve the issue by setting the SYNC_EN bit in PWR_CTRL3 register right after receiving the PLL Lock interrupt. Additionally, drop the unnecessary writes to PWR_CTRL1 register, part of the original mdsync_up_seq, which would have toggled GLOBAL_EN with unwanted consequences on PLL locking behavior. Fixes: f5030564938b ("ALSA: cs35l41: Add shared boost feature") Signed-off-by: Cristian Ciocaltea Reviewed-by: David Rhodes Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20230907171010.1447274-5-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

firmware: tegra: Add suspend hook and reset BPMP IPC early on resume

2023-11-20T10:59:16+00:00

[ Upstream commit ea608a01d4ee66f8b51070e623f9adb8684c0dd4 ] Add suspend hook and a 'suspended' field in the 'struct tegra_bpmp' to mark if BPMP is suspended. Also, add a 'flags' field in the 'struct tegra_bpmp_message' whose 'TEGRA_BPMP_MESSAGE_RESET' bit can be set from the Tegra MC driver to signal that the reset of BPMP IPC channels is required before sending MRQ to the BPMP FW. Together both the fields allow us to handle any requests that might be sent too soon as they can cause hang during system resume. One case where we see BPMP requests being sent before the BPMP driver has resumed is the memory bandwidth requests which are triggered by onlining the CPUs during system resume. The CPUs are onlined before the BPMP has resumed and we need to reset the BPMP IPC channels to handle these requests. The additional check for 'flags' is done to avoid any un-intended BPMP IPC reset if the tegra_bpmp_transfer*() API gets called during suspend sequence after the BPMP driver is suspended. Fixes: f41e1442ac5b ("cpufreq: tegra194: add OPP support and set bandwidth") Co-developed-by: Thierry Reding Signed-off-by: Sumit Gupta Acked-by: Thierry Reding Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

xen: irqfd: Use _IOW instead of the internal _IOC() macro

2023-11-20T10:59:12+00:00

[ Upstream commit 767e33ca47dd8ace7769e0b0c19d7b0c38b2f72d ] _IOC() an internal helper that we should not use in driver code. In particular, we got the data direction wrong here, which breaks a number of tools, as having "_IOC_NONE" should never be paired with a nonzero size. Use _IOW() instead. Fixes: f8941e6c4c71 ("xen: privcmd: Add support for irqfd") Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/all/268a2031-63b8-4c7d-b1e5-8ab83ca80b4a@app.fastmail.com/ Signed-off-by: Viresh Kumar Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/599ca6f1b9dd2f0e6247ea37bee3ea6827404b6d.1697439990.git.viresh.kumar@linaro.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin