The test creates non-FDB nexthops without a nexthop device which leads
to the expected failure, but for the wrong reason:
# ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
IPv6 fdb groups functional
--------------------------
[...]
COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
Error: Device attribute required for non-blackhole and non-fdb nexthops.
COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
Error: Device attribute required for non-blackhole and non-fdb nexthops.
COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
Error: Invalid nexthop id.
TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
[...]
IPv4 fdb groups functional
--------------------------
[...]
COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
Error: Device attribute required for non-blackhole and non-fdb nexthops.
COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
Error: Device attribute required for non-blackhole and non-fdb nexthops.
COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
Error: Invalid nexthop id.
TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
Error: Invalid nexthop id.
TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
[...]
COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
Error: Nexthop id does not exist.
TEST: Route add with fdb nexthop [ OK ]
In addition, as can be seen in the above output, a couple of IPv4 test
cases used the non-FDB nexthops (14 and 15) when they intended to use
the FDB nexthops (16 and 17). These test cases only passed because
failure was expected, but they failed for the wrong reason.
Fix the test to create the non-FDB nexthops with a nexthop device and
adjust the IPv4 test cases to use the FDB nexthops instead of the
non-FDB nexthops.
Output after the fix:
# ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
IPv6 fdb groups functional
--------------------------
[...]
COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
Error: FDB nexthop group can only have fdb nexthops.
TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
[...]
IPv4 fdb groups functional
--------------------------
[...]
COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
Error: FDB nexthop group can only have fdb nexthops.
TEST: Fdb Nexthop group with non-fdb nexthops [ OK ]
COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
Error: Non FDB nexthop group cannot have fdb nexthops.
TEST: Non-Fdb Nexthop group with fdb nexthops [ OK ]
[...]
COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
Error: Route cannot point to a fdb nexthop.
TEST: Route add with fdb nexthop [ OK ]
[...]
Tests passed: 30
Tests failed: 0
Tests skipped: 0
Fixes: 0534c5489c ("selftests: net: add fdb nexthop tests")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20250921150824.149157-3-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The kernel forbids the creation of non-FDB nexthop groups with FDB
nexthops:
# ip nexthop add id 1 via 192.0.2.1 fdb
# ip nexthop add id 2 group 1
Error: Non FDB nexthop group cannot have fdb nexthops.
And vice versa:
# ip nexthop add id 3 via 192.0.2.2 dev dummy1
# ip nexthop add id 4 group 3 fdb
Error: FDB nexthop group can only have fdb nexthops.
However, as long as no routes are pointing to a non-FDB nexthop group,
the kernel allows changing the type of a nexthop from FDB to non-FDB and
vice versa:
# ip nexthop add id 5 via 192.0.2.2 dev dummy1
# ip nexthop add id 6 group 5
# ip nexthop replace id 5 via 192.0.2.2 fdb
# echo $?
0
This configuration is invalid and can result in a NPD [1] since FDB
nexthops are not associated with a nexthop device:
# ip route add 198.51.100.1/32 nhid 6
# ping 198.51.100.1
Fix by preventing nexthop FDB status change while the nexthop is in a
group:
# ip nexthop add id 7 via 192.0.2.2 dev dummy1
# ip nexthop add id 8 group 7
# ip nexthop replace id 7 via 192.0.2.2 fdb
Error: Cannot change nexthop FDB status while in a group.
[1]
BUG: kernel NULL pointer dereference, address: 00000000000003c0
[...]
Oops: Oops: 0000 [#1] SMP
CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
[...]
Call Trace:
<TASK>
fib_table_lookup+0x541/0x650
ip_route_output_key_hash_rcu+0x2ea/0x970
ip_route_output_key_hash+0x55/0x80
__ip4_datagram_connect+0x250/0x330
udp_connect+0x2b/0x60
__sys_connect+0x9c/0xd0
__x64_sys_connect+0x18/0x20
do_syscall_64+0xa4/0x2a0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Fixes: 38428d6871 ("nexthop: support for fdb ecmp nexthops")
Reported-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/68c9a4d2.050a0220.3c6139.0e63.GAE@google.com/
Tested-by: syzbot+6596516dd2b635ba2350@syzkaller.appspotmail.com
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20250921150824.149157-2-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, alloc_skb_with_frags() will only fill (MAX_SKB_FRAGS - 1)
slots. I think it should use all MAX_SKB_FRAGS slots, as callers of
alloc_skb_with_frags() will size their allocation of frags based
on MAX_SKB_FRAGS.
This issue was discovered via a test patch that sets 'order' to 0
in alloc_skb_with_frags(), which effectively tests/simulates high
fragmentation. In this case sendmsg() on unix sockets will fail every
time for large allocations. If the PAGE_SIZE is 4K, then data_len will
request 68K or 17 pages, but alloc_skb_with_frags() can only allocate
64K in this case or 16 pages.
Fixes: 09c2c90705 ("net: allow alloc_skb_with_frags() to allocate bigger packets")
Signed-off-by: Jason Baron <jbaron@akamai.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250922191957.2855612-1-jbaron@akamai.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEn/sM2K9nqF/8FWzzDHRl3/mQkZwFAmjSTPsTHG1rbEBwZW5n
dXRyb25peC5kZQAKCRAMdGXf+ZCRnDOfB/4id/Fio0JP6Uw0otlL8E/QlRh6L92N
tkdkrOtDO/cvxqBviiCHQjvjfqmTn/PMglpfRxfwBO7FHhrXBXiWB889/ojqvRGP
+KT0v/+z/sGsXmHjXvvax9QHbO7lH2E9GUtObaUYtDjI8ID3hnCIYJ5m33yclLJP
araLAhVQaVuwqgE8THkntKkHn3K8I/jDGaJyA+erPL4S725hcZv5bAY3p7plS1jc
tuvdXNmumc31KVK2l04zHG5iTxSh8Qzx6n0yrYyfJ7kp2iwl+ahuIRvst8ZeOPl4
4ic6rMTIR1ylvy+e+CRIdSI/hkgT8JC3G3cHwl1bzSAXnwOUV43TXMBF
=czyt
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-6.17-20250923' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2025-09-23
The 1st patch is by Chen Yufeng and fixes a potential NULL pointer
deref in the hi311x driver.
Duy Nguyen contributes a patch for the rcar_canfd driver to fix the
controller mode setting.
The next 4 patches are by Vincent Mailhol and populate the
ndo_change_mtu(( callback in the etas_es58x, hi311x, sun4i_can and
mcba_usb driver to prevent buffer overflows.
Stéphane Grosjean's patch for the peak_usb driver fixes a
shift-out-of-bounds issue.
* tag 'linux-can-fixes-for-6.17-20250923' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
can: peak_usb: fix shift-out-of-bounds issue
can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
can: rcar_canfd: Fix controller mode setting
can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled
====================
Link: https://patch.msgid.link/20250923073427.493034-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This contains a simple patch to avoid a warning in the case where the
optional memory-region property is missing.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmjNIXEACgkQ3SOs138+
s6EQzRAAmo1gPlr/w+C5IftwgWJdaeYkuOj+43KWf/9dAoGMazGvxAIk8QF4XdK1
GSRI1sikQDZnJdMMvnmFJNaedsKv/JeQ4Rdlx0jztzdez9iSxB8PgXwZhVC1DY0T
flXyFmMASfrIJqNnDtuFfFOAPaqMKagnlxs1EcoIxAM9sTCZSA1TZQKJfDpj49x/
bzuiaci5LjA6bfT1jocWcgzON6IOWQQxiV4UUjITSEiOlW+hzdhmi8H1oBlE4wTZ
sSIAhVepVnCxjmshSDFMWw26r/5p+MKMdCmklbtMpuRvTZyL4IxO5Lv09CptdaBp
TiZPMnJTlnXVIIWbkuS68G/77D/9UVWzaxHXaaMK7GQtabfe0+MuvrKLvmn3B5ex
OvX7SaWMW3kF+lnEZ5UkEubDBfhnSZHvptbUo91leAYOGN7rNB+c0uIZfe+LHzAa
mipV3SPLl1dJbiNwvnblNTspW60mqlM8P/n8etkVzTD/IJGDq5QoruDvfZWBndHc
pfocgl2kxw+wpRf3T69ywI/zDEcR3AgdvxBLHrlv2Xe3aDkM9EVfu2rts5YWSRTn
dX1zCMe0owNfEMhuBlHyy61/XGodTRKeA9hl1hxVQRrT5Zg3FAbEcZyOBSABWpwa
AydhLY1qJlJatoZQ1NMwyLEINMwi0xoOKZVkrMYprX4BZzgwErM=
=nx7Q
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmjTBF8ACgkQmmx57+YA
GNmBihAAsc8cz/+GgFJVljYQJBkSW2r970J2yZ018KHDbKJ/6iSDp0vIkLq17oDM
UkByIGi3ZgxNhKYz6JBuqo6PP53G2IoZAaeqXcxzCsrdX7b8VK1SzAF4UDw3t950
K8ZN4Pl9vGNj9HymqeCQxENqYMHbLoV9HF+zz8piwVyTK26LidJY9/5OXMG38KXo
31ObixUpn2ViHtaxKD3fUA0krF67pNySoNb1LL1Lg7nIqR1Fr3lbqlVX1oZG2KOS
8rt3viPz5swx/4rZqVSZBkPwOz14WZNspw6jEOY55bXWRvTgqvSRa9vY1oYDt5EM
TVwCgGzLlqzVpq3u9jY5AJA1N0YsVFh4R+W6S52b2FZsNJ0ditsiBPURV6RdtqRF
/BqMhRH1aL/L8HvlfmByl17YNsxxR4znefQeTNqRss8n+xz1sjLZIihkcpQ2xdSX
qO9QF32qSNqXoBaZ2TxBDBzDtzuNXdHOpZdnkmruCIdXYTIpJyRSSMOjDIYoN+O8
PUj+BNpX1sauIaXaa43HgJeFmVsxHw+tZAHet2ViZCrEY1jPgE2b3VxQ8MQSvdtj
IXtbjAQCvIjSCcRMLdajhXff3HXXi2eeHsk0jXh/MWh9MJv+LIw1uizATMN8LKqD
Q8OGJtiZtTrMbTWId9hDQspTNakUUDLzXj00lAeq38wU+Q+Ruis=
=veO/
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-6.17-firmware-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
firmware: tegra: Fixes for v6.17
This contains a simple patch to avoid a warning in the case where the
optional memory-region property is missing.
* tag 'tegra-for-6.17-firmware-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: Do not warn on missing memory-region property
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmjMiVUQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgcRXB/994AOVcP5KR5Xtl9De+9IcQBAaGouGIHG7
w7DDB0yRo4YFNK2bE1u7q3ap/jpbQAezv85xkGkh4+RwxolYDW7KI7FjYyuNEC0n
C6dqgzPV/zb0xuBbuAV8z9UYqb/Fu7tWXp/cGr4TmUpSzJdXByOuuefnJjuu0vOR
wAeOLfplI+s8aEMaLaB1d5Huz0IlRS27eyOAjE07NKHsuVtDqZ0voO8S+QTd/7W+
cUZo0BTAuitRWItAKRq1Bxv12jEnkvkGnw8l+iDbQwS2nRJ2NuPJ+/GQUFn53qPP
ZjGFnOMiduJ20WbxXUHSmZfKOH7O8Dz+UQEWYfBfyLcQZ73M3ffB
=cBeN
-----END PGP SIGNATURE-----
Merge tag 'v6.17-rockchip-dtsfixes2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Another missing supply and a wrong headphone gpio level.
* tag 'v6.17-rockchip-dtsfixes2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Fix the headphone detection on the orangepi 5
arm64: dts: rockchip: Add vcc supply for SPI Flash on NanoPC-T6
Just a single commit that drops Alyssa from MAINTAINERS at her own wish
and adds here to .get_maintainer.ignore
Signed-off-by: Sven Peter <sven@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS3vz815OHsEaWy0u9EEX0kKnUe6QUCaMxbiAAKCRBEEX0kKnUe
6fOnAQCawd2qReWEUKhZS3TgzGMDe+eTDKgD0hrxmNIO4fAt2wD/dUrCGu47oBcb
+ZyFX4MvanPwcQ6uYbqBHJJjvkUHeQ4=
=qCvY
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmjTA7EACgkQmmx57+YA
GNnVOg//bXQ0kr4hSHHSTvugSua48nMrBnGC0bWuV5cgl/Y6Q54brxD3YkmgVqr0
E+kbGOzO11O4qOk6K0cMVVxA7vKJhS3i+ymQsIXiJuDtOOSQebzjoSzUmHemuTk9
XBRXxRl871s40KggiRCVcVhl8A2bXjeHvBrh7ZG4uteoQf5emLnVkxszlKpY4YZ9
F41sWHmoEiDcXpLI2sTKDKVfUGvUKAFxO2dJwg9dKSWPiNfgMTQTu+8YM7xKtLam
8P385BSjW2q7WHcnuRW4WMd09QBK/Eko7FoQVsenLbRiQ2R1pwSCswKU0vcMsKAb
Kkvgf6crv5/4UOc3yT0F3NN60lQ6yEEmraQzegvPtHeyiJu6H4K6+oYDfUwX0NtD
ktddC5MONEx5BPgLJLHtIYNhRM5mV+rG1x6PIXsFef/XJueePHHno94K4UmuQY9v
6iQg23tJ1AEaU4AU70WMVVrM8eH5h2ez0yaBSCwtxi9o2i41/w/sgWeQQeAHQOg8
+ThRO796/uLsWQ4gtZlyKAoV/hdRNGRAViJMUYUtrnj75BTAqBxYbGwVsDFZ6Wwu
FTYF+DxRDTwNaXhuwyXbwK2hIyZMGj8087lW059taUQ6YGMY9AJsj2eKgMcNwAPz
aZk2MV5KOqDtyS2Nf19IayL+iwEcNIL1XBXNrU5GyQDgZ4NLI08=
=uZPz
-----END PGP SIGNATURE-----
Merge tag 'apple-soc-fixes-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into arm/fixes
Apple SoC fixes for 6.17
Just a single commit that drops Alyssa from MAINTAINERS at her own wish
and adds here to .get_maintainer.ignore
Signed-off-by: Sven Peter <sven@kernel.org>
* tag 'apple-soc-fixes-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux:
MAINTAINERS: remove Alyssa Rosenzweig
Link: https://lore.kernel.org/r/20250918192241.29374-1-sven@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Extend the K1 I2C properties by including generic i2c-controller schema.
and this will enable it to do the DT validation check later.
Signed-off-by: Yixun Lan <dlan@gentoo.org>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Tested-by: Alex Elder <elder@riscstar.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
The MR1.CKS field is 3 bits wide and all the possible values (from 0 to
7) are valid. This is true for all the SoCs currently integrated in
upstream Linux. Take into account CKS=7 which allows setting bus
frequencies lower than 50KHz. This may be useful at least for debugging.
Fixes: d982d66514 ("i2c: riic: remove clock and frequency restrictions")
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
My address is going to bounce soon and I won't have access to the
Synopsys datasheets so I'm going step down being a maintainer for this
driver.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Remove this flag as the driver stopped managing it individually since
commit a4056c2a63 ("drm/amd/display: use HW hdr mult for brightness
boost"). After some back and forth it was reintroduced as a condition to
`set_output_transfer_func()` in [1]. Without direct management, this
flag only changes value when all surface update flags are set true on
UPDATE_TYPE_FULL with no output TF status meaning.
Fixes: bb622e0c00 ("drm/amd/display: program output tf when required") [1]
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 752e6f283e)
[Why]
We did not initialize dc clocks with boot-time hw values during init.
This lead to incorrect clock values in dc, causing `dcn35_update_clocks`
to make incorrect updates.
[How]
Correctly initialize DC with pre-os clk values from HW.
s/dump/save/ as that accurately reflects the purpose of the functions.
Fixes: 8774029f76 ("drm/amd/display: Add DCN35 CLK_MGR")
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit d43cc4ea1f)
[Description]
Modifications in per asic capability means mpc.preblend flag should be used
to indicate preblend. Update relevant paths to use this flag.
Fixes: 3992305061 ("drm/amd/display: Clear DPP 3DLUT Cap")
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9e5d4a5e27)
Cc: stable@vger.kernel.org
On clients that utilize AMD_PRIVATE_COLOR properties for HDR support,
brightness sliders can include a hardware controlled portion and a
gamma-based portion. This is the case on the Steam Deck OLED when using
gamescope with Steam as a client.
When a user sets a brightness level while HDR is active, the gamma-based
portion and/or hardware portion are adjusted to achieve the desired
brightness. However, when a modeset takes place while the gamma-based
portion is in-use, restoring the hardware brightness level overrides the
user's overall brightness level and results in a mismatch between what
the slider reports and the display's current brightness.
To avoid overriding gamma-based brightness, only restore HW backlight
level after boot or resume. This ensures that the backlight level is
set correctly after the DC layer resets it while avoiding interference
with subsequent modesets.
Fixes: 7875afafba ("drm/amd/display: Fix brightness level not retained over reboot")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4551
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a490c8d77d)
Cc: stable@vger.kernel.org
Since dynamic_events interface on tracefs is compatible with
kprobe_events and uprobe_events, it should also check the lockdown
status and reject if it is set.
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/175824455687.45175.3734166065458520748.stgit@devnote2
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
When config osnoise cpus by write() syscall, the following KASAN splat may
be observed:
BUG: KASAN: slab-out-of-bounds in _parse_integer_limit+0x103/0x130
Read of size 1 at addr ffff88810121e3a1 by task test/447
CPU: 1 UID: 0 PID: 447 Comm: test Not tainted 6.17.0-rc6-dirty #288 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x55/0x70
print_report+0xcb/0x610
kasan_report+0xb8/0xf0
_parse_integer_limit+0x103/0x130
bitmap_parselist+0x16d/0x6f0
osnoise_cpus_write+0x116/0x2d0
vfs_write+0x21e/0xcc0
ksys_write+0xee/0x1c0
do_syscall_64+0xa8/0x2a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
This issue can be reproduced by below code:
const char *cpulist = "1";
int fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY);
write(fd, cpulist, strlen(cpulist));
Function bitmap_parselist() was called to parse cpulist, it require that
the parameter 'buf' must be terminated with a '\0' or '\n'. Fix this issue
by adding a '\0' to 'buf' in osnoise_cpus_write().
Cc: <mhiramat@kernel.org>
Cc: <mathieu.desnoyers@efficios.com>
Cc: <tglozar@redhat.com>
Link: https://lore.kernel.org/20250916063948.3154627-1-wangliang74@huawei.com
Fixes: 17f89102fe ("tracing/osnoise: Allow arbitrarily long CPU string")
Signed-off-by: Wang Liang <wangliang74@huawei.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
In MT8195 power domain data array, set the KEEP_DEFAULT_OFF and
ACTIVE_WAKEUP flags for the AUDIO power domain entry to avoid
having this domain being on during boot sequence when unneeded.
Fixes: 0e789b491b ("pmdomain: core: Leave powered-on genpds on until sync_state")
Fixes: 13a4b7fb62 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit 1a194e6c8e ("fbcon: fix integer overflow in fbcon_do_set_font")
introduced an out-of-bounds access by storing data and allocation sizes
in the same variable. Restore the old size calculation and use the new
variable 'alloc_size' for the allocation.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 1a194e6c8e ("fbcon: fix integer overflow in fbcon_do_set_font")
Reported-by: Jani Nikula <jani.nikula@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15020
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6201
Cc: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: George Kennedy <george.kennedy@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Qianqiang Liu <qianqiang.liu@163.com>
Cc: Shixiong Ou <oushixiong@kylinos.cn>
Cc: Kees Cook <kees@kernel.org>
Cc: <stable@vger.kernel.org> # v5.9+
Cc: Zsolt Kajtar <soci@c64.rulez.org>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Qianqiang Liu <qianqiang.liu@163.com>
Link: https://lore.kernel.org/r/20250922134619.257684-1-tzimmermann@suse.de
Previously BTRFS did not look at a device's reported max_open_zones limit,
but starting with commit 04147d8394 ("btrfs: zoned: limit active zones
to max_open_zones"), zoned BTRFS limited the number of concurrently used
block-groups to the number of max_open_zones a device reported, if it
hadn't already reported a number of max_active_zones.
Starting with commit 04147d8394 the number of open zones is treated the
same way as active zones. But this leads to mount failures on filesystems
which have been used before 04147d8394 because too many zones are in an
open state.
Ignore the new limitations on these filesystems, so zones can be finished
or evacuated.
Reported-by: Yuwei Han <hrx@bupt.moe>
Link: https://lore.kernel.org/all/2F48A90AF7DDF380+1790bcfd-cb6f-456b-870d-7982f21b5eae@bupt.moe/
Fixes: 04147d8394 ("btrfs: zoned: limit active zones to max_open_zones")
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
After a reboot, if the user changes the thermal setting in the BIOS, the
BIOS applies this change. However, the current `dell-pc` driver does not
recognize the updated USTT value, resulting in inconsistent thermal
profiles between Windows and Linux.
To ensure alignment with Windows behavior, read the current USTT settings
during driver initialization and update the dell-pc USTT profile
accordingly whenever a change is detected.
Cc: Yijun Shen <Yijun.Shen@Dell.com>
Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Reviewed-by: Lyndon Sanche <lsanche@lyndeno.ca>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tested-By: Yijun Shen <Yijun.Shen@Dell.com>
Link: https://patch.msgid.link/20250916115142.188535-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Currently we check if the encoder is INVALID or -1 and throw a
WARN_ON but we still end up writing the temp value which will
overflow and corrupt the whole programmed value.
--v2
-Assign a bogus transcoder to master in case we get a INVALID
TRANSCODER [Jani]
Fixes: 6671c367a9 ("drm/i915/tgl: Select master transcoder for MST stream")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250908042208.1011144-1-suraj.kandpal@intel.com
(cherry picked from commit c8e8e9ab14)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Without O_LARGEFILE, file->f_op->write_iter calls
generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
causing -EFBIG on large writes.
In shmem_pwrite(), this error is later masked as -EIO due to the error
handling order, leading to igt failures like gen9_exec_parse(bb-large).
Set O_LARGEFILE in __create_shmem() to prevent -EFBIG on large writes.
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202508081029.343192ec-lkp@intel.com
Fixes: 048832a3f4 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")
Signed-off-by: Taotao Chen <chentaotao@didiglobal.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250822030651.28099-1-chentaotao@didiglobal.com
(cherry picked from commit e296a2266c)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
destination values to the source address field (saddr) when
processing pedit offsets within the destination address range.
This patch corrects the assignment to use daddr instead of saddr,
ensuring that pedit operations on IPv6 destination addresses are
applied correctly.
Fixes: 9b9eb518e3 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Link: https://patch.msgid.link/20250920121157.351921-1-alok.a.tiwari@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH7ZpcWbFyOOp6OJbrB3Eaf9PW7cFAmjQ9iUACgkQrB3Eaf9P
W7d6YRAAmuvXOc5oJQys4gBz0ha/Nq9gHTXEwRp73cB8lle3Lq1OS4PiTqkSlTmC
i30n5jW6p5T9cBC6gngXBSxA7Onljz77MFqXox9REkYR3Zd0ulJ6JjRGo/jBnFcw
pJRVnFsES1iFHO8Rs2Wop2Y1DnusWIM6UqSjGrQloaT52BI++Fy6LdsHfMFU+CSo
vPW2msvd00QHeOZmm8N7eUC556Zpw2rJu7sHD+LkImQjDQUbvAlqq6GnAngh8JLw
nUgZroas1MvBwbk4Et3nxqvZImf6MvWvEzShEmntbs4EvfMOBFCWy5k2AONnaFRE
NjhH46V2NwjeH1JC7TN6TOS17ryfM05V36oFjFMwjmkEJWZ4LFL8ink+Loh2oREH
FDvSxzSapZOu7ki/Ac6wdblJw2qumktegg4Zdtvvew15u1c0InpJiUrli01OnRwf
uF5bj3lGH797Xpiiq+bD79YVQSFUJ8nwJOO3PnvUsdeYrHmn08aJLvYTL3HZ3/V7
9kZJKDNeJR11Pz+dcltXvIL+AHADtb60dZ93X7vjsPPPMrKk383l7Mi6nzlVG6Cc
27QQzvW/WXZ5dCScMv/YPzyDU91cxCYjoO2HBNtKVlntR1UiOMLuP35zAsvf8Oy0
J5LjWVvOA2fR4G3QfaDO02emkIy3RiQOSsfLMcmBe/tqNXiS6Dc=
=hVxI
-----END PGP SIGNATURE-----
Merge tag 'ipsec-2025-09-22' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec
Steffen Klassert says:
====================
pull request (net): ipsec 2025-09-22
1) Fix 0 assignment for SPIs. 0 is not a valid SPI,
it means no SPI assigned.
2) Fix offloading for inter address family tunnels.
* tag 'ipsec-2025-09-22' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
xfrm: fix offloading of cross-family tunnels
xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
====================
Link: https://patch.msgid.link/20250922073512.62703-1-steffen.klassert@secunet.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says:
====================
i40e: virtchnl improvements
Przemek Kitszel says:
Improvements hardening PF-VF communication for i40e driver.
This patchset targets several issues that can cause undefined behavior
or be exploited in some other way.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
i40e: improve VF MAC filters accounting
i40e: add mask to apply valid bits for itr_idx
i40e: add max boundary check for VF filters
i40e: fix validation of VF state in get resources
i40e: fix input validation logic for action_meta
i40e: fix idx validation in config queues msg
i40e: fix idx validation in i40e_validate_queue_map
i40e: add validation for ring_len param
====================
Link: https://patch.msgid.link/20250919184959.656681-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Christian reported that commit a430c11f40 ("intel_idle: Rescan "dead" SMT
siblings during initialization") broke the use case in which both 'nosmt'
and 'maxcpus' are on the kernel command line because it onlines primary
threads, which were offline due to the maxcpus limit.
The initially proposed fix to skip primary threads in the loop is
inconsistent. While it prevents the primary thread to be onlined, it then
onlines the corresponding hyperthread(s), which does not really make sense.
The CPU iterator in cpuhp_smt_enable() contains a check which excludes all
threads of a core, when the primary thread is offline. The default
implementation is a NOOP and therefore not effective on x86.
Implement topology_is_core_online() on x86 to address this issue. This
makes the behaviour consistent between x86 and PowerPC.
Fixes: a430c11f40 ("intel_idle: Rescan "dead" SMT siblings during initialization")
Fixes: f694481b1d ("ACPI: processor: Rescan "dead" SMT siblings during initialization")
Closes: https://lore.kernel.org/linux-pm/724616a2-6374-4ba3-8ce3-ea9c45e2ae3b@arm.com/
Reported-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Tested-by: Christian Loehle <christian.loehle@arm.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/12740505.O9o76ZdvQC@rafael.j.wysocki
Jacob Keller says:
====================
broadcom: report the supported flags for ancillary features
James Clark reported off list that the broadcom PHY PTP driver was
incorrectly handling PTP_EXTTS_REQUEST and PTP_PEROUT_REQUEST ioctls since
the conversion to the .supported_*_flags fields. This series fixes the
driver to correctly report its flags through the .supported_perout_flags
and .supported_extts_flags fields. It also contains an update to comment
the behavior of the PTP_STRICT_FLAGS being always enabled for
PTP_EXTTS_REQUEST2.
I plan to follow up this series with some improvements to the PTP
documentation better explaining each flag and the expectation of the driver
APIs.
====================
Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-0-747b60407c9c@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 6138e687c7 ("ptp: Introduce strict checking of external time stamp
options.") added the PTP_STRICT_FLAGS to the set of flags supported for the
external timestamp request ioctl.
It is only supported by PTP_EXTTS_REQUEST2, as it was introduced the
introduction of the new ioctls. Further, the kernel has always set this
flag for PTP_EXTTS_REQUEST2 regardless of whether or not the user requested
the behavior.
This effectively means that the flag is not useful for userspace. If the
user issues a PTP_EXTTS_REQUEST ioctl, the flag is ignored due to not being
supported on the old ioctl. If the user issues a PTP_EXTTS_REQUEST2 ioctl,
the flag will be set by the kernel regardless of whether the user set the
flag in their structure.
Add a comment documenting this behavior in the uAPI header file.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Tested-by: James Clark <jjc@jclark.com>
Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-3-747b60407c9c@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 7c571ac57d ("net: ptp: introduce .supported_extts_flags to
ptp_clock_info") modified the PTP core kernel logic to validate the
supported flags for the PTP_EXTTS_REQUEST ioctls, rather than relying on
each individual driver correctly checking its flags.
The bcm_ptp_enable() function implements support for PTP_CLK_REQ_EXTTS, but
does not check the flags, and does not forward the request structure into
bcm_ptp_extts_locked().
When originally converting the bcm-phy-ptp.c code, it was unclear what
edges the hardware actually timestamped. Thus, no flags were initialized in
the .supported_extts_flags field. This results in the kernel automatically
rejecting all userspace requests for the PTP_EXTTS_REQUEST2 ioctl.
This occurs because the PTP_STRICT_FLAGS is always assumed when operating
under PTP_EXTTS_REQUEST2. This has been the case since the flags
introduction by commit 6138e687c7 ("ptp: Introduce strict checking of
external time stamp options.").
The bcm-phy-ptp.c logic never properly supported strict flag validation,
as it previously ignored all flags including both PTP_STRICT_FLAGS and the
PTP_FALLING_EDGE and PTP_RISING_EDGE flags.
Reports from users in the field prove that the hardware timestamps the
rising edge. Encode this in the .supported_extts_flags field. This
re-enables support for the PTP_EXTTS_REQUEST2 ioctl.
Reported-by: James Clark <jjc@jclark.com>
Fixes: 7c571ac57d ("net: ptp: introduce .supported_extts_flags to ptp_clock_info")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Tested-by: James Clark <jjc@jclark.com>
Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-2-747b60407c9c@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The bcm_ptp_perout_locked() function has support for handling
PTP_PEROUT_DUTY_CYCLE, but its not listed in the supported_perout_flags.
Attempts to use the duty cycle support will be rejected since commit
d9f3e9ecc4 ("net: ptp: introduce .supported_perout_flags to
ptp_clock_info"), as this flag accidentally missed while doing the
conversion.
Drop the unnecessary supported flags check from the bcm_ptp_perout_locked()
function and correctly set the supported_perout_flags. This fixes use of
the PTP_PEROUT_DUTY_CYCLE support for the broadcom driver.
Reported-by: James Clark <jjc@jclark.com>
Fixes: d9f3e9ecc4 ("net: ptp: introduce .supported_perout_flags to ptp_clock_info")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Tested-by: James Clark <jjc@jclark.com>
Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-1-747b60407c9c@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This contains a fix for sched_ext idle CPU selection that likely fixes
a substantial performance regression.
The scx_bpf_select_cpu_dfl/and() kfuncs were incorrectly detecting all
tasks as migration-disabled when called outside ops.select_cpu(), causing
them to always return -EBUSY instead of finding idle CPUs. The fix properly
distinguishes between genuinely migration-disabled tasks vs. the current
task whose migration is temporarily disabled by BPF execution.
-----BEGIN PGP SIGNATURE-----
iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCaNF8hQ4cdGpAa2VybmVs
Lm9yZwAKCRCxYfJx3gVYGYhsAPwNeMGqniyewfciL6q+9Yjnxudn+bCzntvTidY/
EbV3vgD9GPily3kjKhuPBGIq5hnyiV1DsmmCTIu8vaj7RB4uYw8=
=k2RU
-----END PGP SIGNATURE-----
Merge tag 'sched_ext-for-6.17-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext
Pull sched_ext fix from jun Heo:
"This contains a fix for sched_ext idle CPU selection that likely fixes
a substantial performance regression.
The scx_bpf_select_cpu_dfl/and() kfuncs were incorrectly detecting all
tasks as migration-disabled when called outside ops.select_cpu(),
causing them to always return -EBUSY instead of finding idle CPUs.
The fix properly distinguishes between genuinely migration-disabled
tasks vs. the current task whose migration is temporarily disabled by
BPF execution"
* tag 'sched_ext-for-6.17-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext:
sched_ext: idle: Handle migration-disabled tasks in BPF code
Two user triggerable UAFs:
- Possible race UAF setting up mmaps
- Syzkaller found UAF when erroring an file descriptor creation ioctl due
to the fput() work queue.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCaNFXCgAKCRCFwuHvBreF
YXoFAP9xzBDOVp64CJBY8cD/URaQc8t55b8uJCYgxbDesQa4iAEAxTX9gdZ7Lr6Z
THwdY00LI040gBHUxIZOaXNeOhuPIg8=
=DQIy
-----END PGP SIGNATURE-----
Merge tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd
Pull iommufd fixes from Jason Gunthorpe:
"Fix two user triggerable use-after-free issues:
- Possible race UAF setting up mmaps
- Syzkaller found UAF when erroring an file descriptor creation ioctl
due to the fput() work queue"
* tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd:
iommufd/selftest: Update the fail_nth limit
iommufd: WARN if an object is aborted with an elevated refcount
iommufd: Fix race during abort for file descriptors
iommufd: Fix refcounting race during mmap
- Fix mlx5 devx event delivery to userspace for certain kinds of SRQs
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCaNFT/AAKCRCFwuHvBreF
YcafAP9bA38Qg5N2FZVUdKHRFx1diKVmh2Icp2zDqFmR/mhpSAD/enXPK3FLnQrx
hwB/2b/xn5yWjOllWAokjwaFoZ49zgA=
=dG5k
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fix from Jason Gunthorpe:
"Just a one line change, was expecting more rc stuff, but it has been
quiet.
- Fix mlx5 devx event delivery to userspace for certain kinds of SRQs"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEL65usyKPHcrRDEicpmLzj2vtYEkFAmjREAsACgkQpmLzj2vt
YEk3cQ/9EJXVKCOlENyjAVd/Lu1tG8iRL181l4nlnkXkUKWG1//Qq+5g9qU1ycpy
V21mYHzgriJ6fA1lH/UKgw2Ayq2QA2Rqe3TDCdzdwi8bRvPEvGxH+zmaickuZHpl
Zi+LT17xW3SZtNRXKMDp5/Feb85quOQSuo+HXrql14jl3sF5nAF9BfOwvTb/UHel
YzL3mAtwyDF90Ijhl/uLQaSeblHG3LOnCy3OPE7XyyOOXW3VQvXuEp5mA9Cac18J
A0zcIYlR+wUj3yobjLe7xU27HKUe01a3WMGt3FfrStQK4HQFl1Rg6I66piBbqd4/
oroP78A8tfVJf1ruGadcvj7IuRg9tSTHZVowRDx+5TeRywWFBBGIrmBfy3WiMmGA
M/78ADQvcExOOY0kZBCXD3aJShpoS7gL0f35fKoC8yKhgyHC+GKOQwQz1kX2ub2Z
oRdnb1GItQ4wDvLH8yyJahMYWhuVv/R7ITABAs8Nb68yMO0yS5aMVFeW2kzZ0eM2
5yM0XtTzKWNSMi525+CEZDy53cNkrThhgC72UhSHmgnEtlcfgYZ0Gd9j6tSF2KEJ
FVIUu0o4DV303IJmx5euLOrwY/vHgr3Qw4bH2qIxw32CocgPabYcn6IAd5aynCrB
MmRqpMu/SOAPStBFYNSUk/CJvLlGImUAGe5m99daGTZxWjHRZ30=
=Jiyj
-----END PGP SIGNATURE-----
Merge tag 'hid-for-linus-2025092201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
- work data memory corruption fix in amd_sfh (Basavaraj Natikar)
- fix for regression in cp2112 where setting a GPIO value would always
fail (Sébastien Szymanski)
- fix for regression in hid-lenovo causing driver to fail on non-ACPI
systems (Janne Grunau)
- a couple device ID additions and tiny device-specific quirks
* tag 'hid-for-linus-2025092201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: amd_sfh: Add sync across amd sfh work functions
HID: asus: add support for missing PX series fn keys
HID: cp2112: fix setter callbacks return value
HID: lenovo: Use KEY_PERFORMANCE instead of ACPI's platform_profile
HID: intel-thc-hid: intel-quickspi: Add WCL Device IDs
HID: intel-thc-hid: intel-quicki2c: Add WCL Device IDs
These are two small driver fixes for the Airhoa driver.
- Correct a PHY LED mux value so the PHY LED will
blink as it should.
- Fix the MDIO function bitmasks, working around a
HW bug to force-enable the MDIO pins.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmjRBrkACgkQQRCzN7AZ
XXOK9Q//WYo/Jm6KETEwWAlEEKOTr3h+FnUox6giOOItXbJhJ1iqLzTLIhMsJHK5
2uEEFxtHAuNu01cNPYUkIfgqCpYEyA1xK7/gtRV+IWeFt4IiVDCMtyCCiUMzKV4k
OgeMO7Scqvm61qrvOu/+WF1kc+lsGZ3dJPoBLq1C6Dn67Y0SNegICCJh6YPPis4J
lEpx4PqZiqDYOMuy/r9tuAKFqOlP4Q9BhsXzLH+hC1V2kd7/7/hqWx3i+WFADDNP
1Q+GQYqqqR1yLhZq+tsJ2TcdAP04cx9mWuxeclIQrqQPxyeoFz4ua2K8s1TFUDu6
f3Gw7UAtCLJjx3O1G/Ji0MccrpUBr8IWdJloKHsiREuogzk4zdRT/6czBEZywM/G
HJ0EHrWNZa7RExxmfGG05/21YBHAAavfxF4klboxpfTcECXbCuJqJPq8IUe7EKwx
rXdkWTFxJhEMX3VL2BlTccIXZ4BjX9IokuLT3FYIaww4AXAOMhz8Jx2G8PnlfOeg
xVGDyVbmUzaO4SKcFfR7VvCXIxlk9F4keouG9cmxrNFbjgSSt24sab5QLdNujzdT
gTaFswHZ6P2rtqctcCbQN2XeK9qvPBOWvZv6ea9rxvMvsO5+7wC5Us/z4VFCmPvB
NFqNL+lNZ6HJgrlAtqkQPiqYRNdePUud7OsomPxIO5QnM2TEIkc=
=nbM0
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Two small driver fixes for the Airhoa driver:
- Correct a PHY LED mux value so the PHY LED will blink as it should
- Fix the MDIO function bitmasks, working around a HW bug to
force-enable the MDIO pins"
* tag 'pinctrl-v6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: airoha: fix wrong MDIO function bitmaks
pinctrl: airoha: fix wrong PHY LED mux value for LED1 GPIO46
When scx_bpf_select_cpu_dfl()/and() kfuncs are invoked outside of
ops.select_cpu() we can't rely on @p->migration_disabled to determine if
migration is disabled for the task @p.
In fact, migration is always disabled for the current task while running
BPF code: __bpf_prog_enter() disables migration and __bpf_prog_exit()
re-enables it.
To handle this, when @p->migration_disabled == 1, check whether @p is
the current task. If so, migration was not disabled before entering the
callback, otherwise migration was disabled.
This ensures correct idle CPU selection in all cases. The behavior of
ops.select_cpu() remains unchanged, because this callback is never
invoked for the current task and migration-disabled tasks are always
excluded.
Example: without this change scx_bpf_select_cpu_and() called from
ops.enqueue() always returns -EBUSY; with this change applied, it
correctly returns idle CPUs.
Fixes: 06efc9fe0b ("sched_ext: idle: Handle migration-disabled tasks in idle selection")
Cc: stable@vger.kernel.org # v6.16+
Signed-off-by: Andrea Righi <arighi@nvidia.com>
Acked-by: Changwoo Min <changwoo@igalia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We were copying the bo content the bos on the list
"xe->pinned.late.kernel_bo_present" twice on suspend.
Presumingly the intent is to copy the pinned external bos on
the first pass.
This is harmless since we (currently) should have no pinned
external bos needing copy since
a) exernal system bos don't have compressed content,
b) We do not (yet) allow pinning of VRAM bos.
Still, fix this up so that we copy pinned external bos on
the first pass. We're about to allow bos pinned in VRAM.
Fixes: c6a4d46ec1 ("drm/xe: evict user memory in PM notifier")
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v6.16+
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://lore.kernel.org/r/20250918092207.54472-2-thomas.hellstrom@linux.intel.com
(cherry picked from commit 9e69bafece)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
When building with CONFIG_MODULES=n, the __exit functions are dropped.
However our init functions may call them for error handling, so they are
not good candidates for the exit sections.
Fix this error reported by 0day:
ld.lld: error: relocation refers to a symbol in a discarded section: xe_configfs_exit
>>> defined in vmlinux.a(drivers/gpu/drm/xe/xe_configfs.o)
>>> referenced by xe_module.c
>>> drivers/gpu/drm/xe/xe_module.o:(init_funcs) in archive vmlinux.a
This is the only exit function using __exit. Drop it to fix the build.
Cc: Riana Tauro <riana.tauro@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506092221.1FmUQmI8-lkp@intel.com/
Fixes: 16280ded45 ("drm/xe: Add configfs to enable survivability mode")
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://lore.kernel.org/r/20250912-fix-nomodule-build-v1-1-d11b70a92516@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit d9b2623319)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
VFs can't read BMG_PCIE_CAP(0x138340) register nor access PCODE
(already guarded by the info.skip_pcode flag) so we shouldn't
expose attributes that require any of them to avoid errors like:
[] xe 0000:03:00.1: [drm] Tile0: GT0: VF is trying to read an \
inaccessible register 0x138340+0x0
[] RIP: 0010:xe_gt_sriov_vf_read32+0x6c2/0x9a0 [xe]
[] Call Trace:
[] xe_mmio_read32+0x110/0x280 [xe]
[] auto_link_downgrade_capable_show+0x2e/0x70 [xe]
[] dev_attr_show+0x1a/0x70
[] sysfs_kf_seq_show+0xaa/0x120
[] kernfs_seq_show+0x41/0x60
Fixes: 0e414bf7ad ("drm/xe: Expose PCIe link downgrade attributes")
Fixes: cdc36b66cd ("drm/xe: Expose fan control and voltage regulator version")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250916170029.3313-2-michal.wajdeczko@intel.com
(cherry picked from commit a2d6223d22)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
A recent commit skipped dumping the usual "attempt to access beyond end
of device" message if the device size is 0 sectors, as that's a common
pattern for devices that have been hot removed. But while it stopped
that message, it also prevented returning -EIO for that condition.
Reinstate the -EIO return, while retaining the quiet operation for
triggering EOD for a device with 0 sectors.
Reported-by: syzbot+4b12286339fe4c2700c1@syzkaller.appspotmail.com
Reported-by: Sahil Chandna <chandna.linuxkernel@gmail.com>
Fixes: d0a2b527d8 ("block: tone down bio_check_eod")
Tested-by: Sahil Chandna <chandna.linuxkernel@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The gpio_regmap structure is leaked on the error path. Fix this by
jumping to the appropriate kfree instead of returning directly.
Fixes: db30516188 ("gpio: regmap: Allow ngpio to be read from the property")
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Suggested-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20250922142427.3310221-7-ioana.ciornei@nxp.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When a software-node gets added to a device which already has another
fwnode as primary node it will become the secondary fwnode for that
device.
Currently if a software-node with GPIO properties ends up as the secondary
fwnode then gpiod_find_by_fwnode() will fail to find the GPIOs.
Add a new gpiod_fwnode_lookup() helper which falls back to calling
gpiod_find_by_fwnode() with the secondary fwnode if the GPIO was not
found in the primary fwnode.
Fixes: e7f9ff5dc9 ("gpiolib: add support for software nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20250920200955.20403-1-hansg@kernel.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The commit
f9aad62200 ("mm: rename GENERIC_PTDUMP and PTDUMP_CORE")
has broken PTDUMP and the Kconfig options that use it on ARCH=i386, including
CONFIG_DEBUG_WX.
CONFIG_GENERIC_PTDUMP was renamed into CONFIG_ARCH_HAS_PTDUMP, but it was
mistakenly moved from "config X86" to "config X86_64". That made PTDUMP
unavailable for i386.
Move CONFIG_ARCH_HAS_PTDUMP back to "config X86" to fix it.
[ bp: Massage commit message. ]
Fixes: f9aad62200 ("mm: rename GENERIC_PTDUMP and PTDUMP_CORE")
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
If the cached contents of the CHCONF register doesn't have the FORCE bit
set, the setup() function failed to set the relevant idle state of the
SPI_CLK pin. In such case, the SPI_CLK's idle state is reached later with
set_cs(), but it's too late for the first SPI transfer which fails since
the CS is asserted before the clock reaching its idle state.
Add a first write in setup() that always sets the FORCE bit.
Keep the current write afterwards to ensure the FORCE bit won't stay in
the cached contents of the CHCONF register unless it's intended.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20250912-omap-spi-fix-v1-1-f925b0d27ede@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
