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

Linux 6.1.32

2023-06-05T07:26:22Z

Link: https://lore.kernel.org/r/20230601131939.051934720@linuxfoundation.org Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20230601143327.479886832@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Takeshi Ogasawara Tested-by: Conor Dooley Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Markus Reichelt Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

tools headers UAPI: Sync the linux/in.h with the kernel sources

2023-06-05T07:26:22Z

commit 5d1ac59ff7445e51a0e4958fa39ac8aa23691698 upstream. Picking the changes from: 91d0b78c5177f3e4 ("inet: Add IP_LOCAL_PORT_RANGE socket option") Silencing these perf build warnings: Warning: Kernel ABI header at 'tools/include/uapi/linux/in.h' differs from latest version at 'include/uapi/linux/in.h' diff -u tools/include/uapi/linux/in.h include/uapi/linux/in.h Signed-off-by: Yanteng Si Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: loongson-kernel@lists.loongnix.cn Link: https://lore.kernel.org/r/23aabc69956ac94fbf388b05c8be08a64e8c7ccc.1683712945.git.siyanteng@loongson.cn Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

netfilter: ctnetlink: Support offloaded conntrack entry deletion

2023-06-05T07:26:22Z

commit 9b7c68b3911aef84afa4cbfc31bce20f10570d51 upstream. Currently, offloaded conntrack entries (flows) can only be deleted after they are removed from offload, which is either by timeout, tcp state change or tc ct rule deletion. This can cause issues for users wishing to manually delete or flush existing entries. Support deletion of offloaded conntrack entries. Example usage: # Delete all offloaded (and non offloaded) conntrack entries # whose source address is 1.2.3.4 $ conntrack -D -s 1.2.3.4 # Delete all entries $ conntrack -F Signed-off-by: Paul Blakey Reviewed-by: Simon Horman Acked-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Cc: Demi Marie Obenour Signed-off-by: Greg Kroah-Hartman

cpufreq: amd-pstate: Add ->fast_switch() callback

2023-06-05T07:26:21Z

commit 4badf2eb1e986bdbf34dd2f5d4c979553a86fe54 upstream. Schedutil normally calls the adjust_perf callback for drivers with adjust_perf callback available and fast_switch_possible flag set. However, when frequency invariance is disabled and schedutil tries to invoke fast_switch. So, there is a chance of kernel crash if this function pointer is not set. To protect against this scenario add fast_switch callback to amd_pstate driver. Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Signed-off-by: Gautham R. Shenoy Signed-off-by: Wyes Karny Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: amd-pstate: Update policy->cur in amd_pstate_adjust_perf()

2023-06-05T07:26:21Z

commit 3bf8c6307bad5c0cc09cde982e146d847859b651 upstream. Driver should update policy->cur after updating the frequency. Currently amd_pstate doesn't update policy->cur when `adjust_perf` is used. Which causes /proc/cpuinfo to show wrong cpu frequency. Fix this by updating policy->cur with correct frequency value in adjust_perf function callback. - Before the fix: (setting min freq to 1.5 MHz) [root@amd]# cat /proc/cpuinfo | grep "cpu MHz" | sort | uniq --count 1 cpu MHz : 1777.016 1 cpu MHz : 1797.160 1 cpu MHz : 1797.270 189 cpu MHz : 400.000 - After the fix: (setting min freq to 1.5 MHz) [root@amd]# cat /proc/cpuinfo | grep "cpu MHz" | sort | uniq --count 1 cpu MHz : 1753.353 1 cpu MHz : 1756.838 1 cpu MHz : 1776.466 1 cpu MHz : 1776.873 1 cpu MHz : 1777.308 1 cpu MHz : 1779.900 183 cpu MHz : 1805.231 1 cpu MHz : 1956.815 1 cpu MHz : 2246.203 1 cpu MHz : 2259.984 Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Signed-off-by: Wyes Karny [ rjw: Subject edits ] Cc: 5.17+ # 5.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

block: fix bio-cache for passthru IO

2023-06-05T07:26:21Z

commit 46930b7cc7727271c9c27aac1fdc97a8645e2d00 upstream. commit <8af870aa5b847> ("block: enable bio caching use for passthru IO") introduced bio-cache for passthru IO. In case when nr_vecs are greater than BIO_INLINE_VECS, bio and bvecs are allocated from mempool (instead of percpu cache) and REQ_ALLOC_CACHE is cleared. This causes the side effect of not freeing bio/bvecs into mempool on completion. This patch lets the passthru IO fallback to allocation using bio_kmalloc when nr_vecs are greater than BIO_INLINE_VECS. The corresponding bio is freed during call to blk_mq_map_bio_put during completion. Cc: stable@vger.kernel.org # 6.1 fixes <8af870aa5b847> ("block: enable bio caching use for passthru IO") Signed-off-by: Anuj Gupta Signed-off-by: Kanchan Joshi Link: https://lore.kernel.org/r/20230523111709.145676-1-anuj20.g@samsung.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

Revert "thermal/drivers/mellanox: Use generic thermal_zone_get_trip() function"

2023-06-05T07:26:21Z

This reverts commit a71f388045edbf6788a61f43e2cdc94b392a4ea3. Commit a71f388045ed ("thermal/drivers/mellanox: Use generic thermal_zone_get_trip() function") was backported as a dependency of the fix in upstream commit 6d206b1ea9f4 ("mlxsw: core_thermal: Fix fan speed in maximum cooling state"). However, it is dependent on changes in the thermal core that were merged in v6.3. Without them, the mlxsw driver is unable to register its thermal zone: mlxsw_spectrum 0000:03:00.0: Failed to register thermal zone mlxsw_spectrum 0000:03:00.0: cannot register bus device mlxsw_spectrum: probe of 0000:03:00.0 failed with error -22 Fix this by reverting this commit and instead fix the small conflict with the above mentioned fix. Tested using the test case mentioned in the change log of the fix: # cat /sys/class/thermal/thermal_zone2/cdev0/type mlxsw_fan # echo 10 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # cat /sys/class/hwmon/hwmon1/name mlxsw # cat /sys/class/hwmon/hwmon1/pwm1 255 After setting the fan to its maximum cooling state (10), it operates at 100% duty cycle instead of being stuck at 0 RPM. Fixes: a71f388045ed ("thermal/drivers/mellanox: Use generic thermal_zone_get_trip() function") Reported-by: Joe Botha Tested-by: Joe Botha Signed-off-by: Ido Schimmel Signed-off-by: Greg Kroah-Hartman

bluetooth: Add cmd validity checks at the start of hci_sock_ioctl()

2023-06-05T07:26:21Z

commit 000c2fa2c144c499c881a101819cf1936a1f7cf2 upstream. Previously, channel open messages were always sent to monitors on the first ioctl() call for unbound HCI sockets, even if the command and arguments were completely invalid. This can leave an exploitable hole with the abuse of invalid ioctl calls. This commit hardens the ioctl processing logic by first checking if the command is valid, and immediately returning with an ENOIOCTLCMD error code if it is not. This ensures that ioctl calls with invalid commands are free of side effects, and increases the difficulty of further exploitation by forcing exploitation to find a way to pass a valid command first. Signed-off-by: Ruihan Li Co-developed-by: Marcel Holtmann Signed-off-by: Marcel Holtmann Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Dragos-Marian Panait Signed-off-by: Greg Kroah-Hartman

drm/amd: Don't allow s0ix on APUs older than Raven

2023-06-05T07:26:21Z

commit ca47518663973083c513cd6b2801dcda0bfaaa99 upstream. APUs before Raven didn't support s0ix. As we just relieved some of the safety checks for s0ix to improve power consumption on APUs that support it but that are missing BIOS support a new blind spot was introduced that a user could "try" to run s0ix. Plug this hole so that if users try to run s0ix on anything older than Raven it will just skip suspend of the GPU. Fixes: cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") Suggested-by: Alexander Deucher Signed-off-by: Mario Limonciello Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

octeontx2-af: Add validation for lmac type

2023-06-05T07:26:21Z

[ Upstream commit cb5edce271764524b88b1a6866b3e626686d9a33 ] Upon physical link change, firmware reports to the kernel about the change along with the details like speed, lmac_type_id, etc. Kernel derives lmac_type based on lmac_type_id received from firmware. In a few scenarios, firmware returns an invalid lmac_type_id, which is resulting in below kernel panic. This patch adds the missing validation of the lmac_type_id field. Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 35.321595] Modules linked in: [ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.4.210-g2e3169d8e1bc-dirty #17 [ 35.337014] Hardware name: Marvell CN103XX board (DT) [ 35.344297] Workqueue: events work_for_cpu_fn [ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO) [ 35.360267] pc : strncpy+0x10/0x30 [ 35.366595] lr : cgx_link_change_handler+0x90/0x180 Fixes: 61071a871ea6 ("octeontx2-af: Forward CGX link notifications to PFs") Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: Sai Krishna Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin