Tianyi Gao says:
====================
veth: fix peer NETDEV_XDP_ACT_NDO_XMIT after GRO is toggled while down
Toggling GRO on a veth device while it is down leaves its peer's
NETDEV_XDP_ACT_NDO_XMIT flag stale once the device comes up. XDP
redirects into the peer are then rejected with -EOPNOTSUPP, or, if GRO
was turned off, accepted and then dropped with -ENXIO. Patch 1 refreshes
the peer's flags in veth_open().
Patch 2 extends veth.sh to check the peer's flag after GRO is toggled
while the device is down, in both directions.
====================
Link: https://patch.msgid.link/20261006173241.65945-1-tianyi@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test that toggling GRO on a veth device while it is down updates the
peer's ndo-xmit XDP feature once the device comes up, for both GRO on
and GRO off.
xdp-features is only visible through netlink, so read it with the ynl
CLI, as double_udp_encap.sh does. Skip the checks if the CLI is not
found, as in an installed kselftest tree.
Signed-off-by: Tianyi Gao <tianyi@cloudflare.com>
Link: https://patch.msgid.link/20261006173241.65945-3-tianyi@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A veth device advertises NETDEV_XDP_ACT_NDO_XMIT only if its peer has an
XDP program attached or GRO enabled, that is, only if the peer will have
NAPI to receive the frames.
veth_set_features() updates the peer's flag when GRO is toggled, but
returns early if the device is down, and veth_open() only refreshes the
flags of the device being opened. Toggling GRO while the device is down
therefore leaves the peer's flag stale after the device comes up.
If GRO was enabled while down, the device comes up with NAPI but the
peer does not advertise NDO_XMIT, and devmap rejects redirects to the
peer with -EOPNOTSUPP. If GRO was disabled while down, the device comes
up without NAPI but the peer still advertises NDO_XMIT, so redirects are
accepted and then dropped in veth_xdp_xmit() with -ENXIO.
Commit 7a6102aa6d ("veth: Update XDP feature set when bringing up
device") made veth_open() refresh the device's own flags. Refresh the
peer's flags there too. The peer's flag depends on this device's XDP
program and GRO setting, not on whether the peer is up, so it is
correct to set it even if the peer is down.
Fixes: 8267fc71ab ("veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features flag")
Signed-off-by: Tianyi Gao <tianyi@cloudflare.com>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Link: https://patch.msgid.link/20261006173241.65945-2-tianyi@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 730ff06d3f ("net: mana: Use page pool fragments for RX buffers
instead of full pages to improve memory efficiency.") started handing
out RX buffers with zero headroom so that two buffers fit into one page
at the default MTU.
The MANA TX path, however, stores the per scatter-gather entry DMA
mappings in `struct mana_skb_head` at skb->head, and mana_start_xmit()
therefore calls skb_cow_head(skb, MANA_HEADROOM). The port advertises
this requirement as ndev->needed_headroom = MANA_HEADROOM.
As a result every packet that is received and then forwarded out of a
MANA port fails the skb_cow() in ip_forward() and gets reallocated and
copied by pskb_expand_head(). This is invisible to a plain RX or TX
workload, but it puts a full skb reallocation plus memcpy on the hot
path of every single forwarded packet, which is exactly what a
router/NVA workload does.
Restore the headroom. Note that reserving MANA_HEADROOM (232) is not
enough: ip_forward() asks for LL_RESERVED_SPACE(dev), which rounds
hard_header_len + needed_headroom up to HH_DATA_MOD and is 256 bytes on
ethernet. Use LL_RESERVED_SPACE() directly so the value keeps tracking
both constants. Also, since LL_RESERVED_SPACE() tracks MANA_HEADROOM,
it grows with MAX_SKB_FRAGS and for MAX_SKB_FRAGS >= 19 it is greater
than 256, so we have to account for that by using the headroom the RX
queue actually uses (instead of assuming XDP_PACKET_HEADROOM) and
turning MANA_XDP_MTU_MAX into MANA_XDP_MTU_MAX(ndev) (note that at the
default CONFIG_MAX_SKB_FRAGS=17 they are equivalent).
At the default MTU on a 4K page this means a buffer no longer fits twice
into a page (SKB_DATA_ALIGN(1500 + MANA_RXBUF_PAD + 256) = 2112), so the
frag-vs-single decision is now made by computing the real buffer size
instead of comparing the MTU against PAGE_SIZE / 2. The page_pool
fragment path is still used wherever at least two buffers genuinely fit,
e.g. on 16K and 64K page sizes.
Measured on an Azure VM with a MANA NIC acting as a forwarding NVA (UDP,
1400 byte payload, 4 streams, 8 Gbps offered, only the forwarding
node's kernel differs), 8 runs each, median:
forwarded pps throughput
before 272,830 3.06 Gbps
after 390,560 4.37 Gbps (+43%)
perf on the forwarding node, same workload:
memset_orig __pi_memcpy pskb_expand_head
before 10.07% 3.96% present
after 0.94% 0.64% gone
Cc: stable@vger.kernel.org
Fixes: 730ff06d3f ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261003013647.2051416-1-hamzamahfooz@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
drm/i915 fixes for v7.3-rc7:
- Fix a GT park race that could trigger spurious RPM wakelock warnings
- Fix execbuffer relocation cleanup to avoid out-of-bounds free
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/49ac4a9f496e1dadbf71740eb0d1f443598b2632@intel.com
removed in 2028.
Also designate the primary branch that Sashiko and other tools use to
find the primary development branch in the ext4 tree.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEK2m5VNv+CHkogTfJ8vlZVpUNgaMFAmrHtq4ACgkQ8vlZVpUN
gaMFZAf/eACeBhy6Tm9s6MDAewS84BDeNd/WuUrIn+Jpt1jwpL83sNPY3rgleR7s
spPpg7fJQJfFbRiyOj4YUNbwShCOJ61cOw/BrLBYD5HlkCNuexBNWEOEVB7HWAVv
f+J7FLF8k/6lgzuXI4CNzC4NIpKiWLUi3zbGbjxZgtdsr1j7zThVn83WwuHqnJic
dLlW5Twcwox0j2UDKRmERL1x8QBeghJPSX9u1xNEtx8/gEkAKGJ601MrbVmZPDDy
FuXZUdOuyctLuiFMjvB20jVXMVCO0SMj5DiJ8vwGYV/OHVYcLxx7WP7KxJ/IKmK8
lk748C174vVDTLTSzBDIAnqctfkUxQ==
=zILx
-----END PGP SIGNATURE-----
Merge tag 'ext4_for_linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 fixes from Ted Ts'o:
"Mark the ext4 data=journal feature as being deprecated and will be
removed in 2028.
Also designate the primary branch that Sashiko and other tools use to
find the primary development branch in the ext4 tree"
* tag 'ext4_for_linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: mark data=journal as deprecated and will be removed in January 2028.
MAINTAINERS: name the ext4 dev branch
The ext4 T: entry names the repository without a branch, so tools that
default to the repository's HEAD select master, which still points at a
merge from October 2020 (96485e4462). Development happens on dev,
which is also the branch linux-next merges. Name it.
The Sashiko review bot, for one, falls back to HEAD this way and has
been reviewing ext4 patches against that tree. Its review of an EA
inode refcount fix reported a Critical double decrement and an
undefined function after applying the patch to that stale baseline;
neither holds on dev.
Link: https://lore.kernel.org/all/20260916072420.316321F000FF@smtp.kernel.org/
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
Acked-by: Jan Kara <jack@suse.cz>
Link: https://patch.msgid.link/20260923101749.3505886-1-matthias.goergens@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
- fix intr_target_width in several qualcomm pinctrl drivers
- make direction changes exclusive in pinctrl-spmi-gpio
- fix function issues in pinctrl-ipq5018
- add missing OF module alias to pinctrl-ipq5210
- split QUP1 SE2/SE3 into lane-pair functions
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmrHXMIACgkQBZ0uy/82
hMN6ZQ/+LQi2B9W9kqtSq047/MRUOKgKDPl5AiZjlP7k9lmV3FKDgi6NtUnFJURY
xIx7z00/9mffqqnLlXkBP8bZq4N6wgUiqVE//0F+K+8MfYfXDQsZdHgHet6GvQak
kpVrwLG+G9brGpfDvoOZxPMQsYUoLvOnUgdG8L3kuPloaquk/3lv9HXHi2J7QFqo
J64t1ZPYgfszhwpbMtrDT5s1xn8KeahQmi3ZOB6dJq65F1FF3/BvjjeI8UaMcH+6
M1NCgqs2Q6Lwiqa8y8pFXzgcOkPKlRd1PSdKzFfsKt9FuPTx33xtwJ/kGl7P0P2E
PHxr9YtYaWw1n498skbA+I850GHUeE4Fj66rSIdwktTfcz7VDR5WfHUAsJ9WZY/x
iErOCazqVSu8fAY44HhX3s1fc/mb91JrMX0GdxpsfKHVpI93Yb9pNZE70aoqSOC/
iMCwqQy6sX1LazUlELyheHFB/flftykaieeBp0VpUOEaN6WsmcdpAiRMQIWEldWg
+AmeFK59hqUdwoQLieN4Dk/SCXt2zW0KRiz4rGSySfY/c0qCGh6hU/Pcko/G7L04
CfvAGPHD52lnMVq8J1DxbQ5exYw2wby2m77mJnALRI9tGJ1rcAJXMgXOZZPGqdxi
cR0eOKlYmt9l/tD8vW1QhXBfrQWTboVCkBaWHrkPOef4dowdv8I=
=fFv6
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-qcom-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes
Qualcomm pin control fixes for v7.3-rc7
- fix intr_target_width in several qualcomm pinctrl drivers
- make direction changes exclusive in pinctrl-spmi-gpio
- fix function issues in pinctrl-ipq5018
- add missing OF module alias to pinctrl-ipq5210
- split QUP1 SE2/SE3 into lane-pair functions
Signed-off-by: Linus Walleij <linusw@kernel.org>
- add missing PCI device IDs for Thinkpad T14s gen6 which should have
been part of commit a39ac4651e ("power: sequencing: pcie-m2: Match WCN6855
and WCN7851 UART BT variants by subdevice ID") in pwrseq-pcie-m2
- fix memory leak in pwrseq-pcie-m2 (leaking the array returned by
of_regulator_bulk_get_all())
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmrHWzQACgkQBZ0uy/82
hMM9ZA//SnO7W4g12J5vANwr9bUYdhWsgwm8r0zH3EGaj1Jc8VkxBqzHy9DzCgJy
8UKAPJB+X94Mw6XYihWrvXfr9ZFbbzI5abi+x1g/ZPy3i9MKKQBL1r8N1GQpd4p9
+vIljNfNuzQRg+W1cPOKFsH9xZWrO18KNN2rM6LznMemuwqbQAzklMsqw4jmrU27
eItmxJpmBv3K+XiaXrBwhXLfWoNB5ANWEBTl6Fkzv1tb+yw99zD6z8GPQ0xZpQBf
Mlp8/J3dBcp3OHbGjHHjv3xF/vN2ENv9pxshsJsX+MLpRWCZNC2fmTohbfaMsQp7
j0AHgzjxAJU7w0X6Ujju5Nu29lkuetqfNPpb/1Xt17CALSpI0z83gURGsdTziWmr
uFIKPn6Autjv/B4VbcE7bK92FgwHcOFiQw91pj7bymY3J2OHZCWJZqbcJNxXIm3Y
qTg5YzjJLMP8yiMxeFNAgFPQbFsBC/nu0icyLlWmz1lQwdULpDIr/eHxbrvPDRHi
KbpXYUFLoKq4ZMST+cGIzaBxxT3PBEpGroFqnygqDvKHML1W6Uy+t/BTPt3SKF//
X/DgOJN3rUD509LyoQcjHjZ7x+jAJ2KL9dTeybnEDA11m/uQS21ViywNfYkspLCW
47mn2NsWj2iDAXxWAs1n9BtHFTbHKqX9r3VxEeHoI55iFEG0iRU=
=Pvvd
-----END PGP SIGNATURE-----
Merge tag 'pwrseq-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fixes from Bartosz Golaszewski:
- add missing PCI device IDs for Thinkpad T14s gen6 which should have
been part of commit a39ac4651e ("power: sequencing: pcie-m2: Match
WCN6855 and WCN7851 UART BT variants by subdevice ID") in
pwrseq-pcie-m2
- fix memory leak in pwrseq-pcie-m2 (leaking the array returned by
of_regulator_bulk_get_all())
* tag 'pwrseq-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: pcie-m2: Fix leaking array from of_regulator_bulk_get_all()
power: sequencing: pcie-m2: Add Lenovo ThinkPad T14s gen6 WCN7850 subsystem PCI ids
- fix runtime PM leak in error path in gpio-xilinx
- fix race when arming the IRQ poll worker in gpio-mpsse
- fix devres cleanup path on probe error in gpio-exar
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmrHWhAACgkQBZ0uy/82
hMOkgg/+LFRYaG+Y+ql27JO4LUuzqIdLyqhlGVCcXt74p21kxGTbohF9LgeqcmTi
1vV6CztX2puAnsZYwC9m8bHZrn5mJVu1on1u3gIsKQyooeTSoucZLWTCLl28SjNu
HAH5DRUZe2ma/eMEfZaydANziJHjaniblq+E+wq7tS4F4djDJsgNzb34k2r4vldS
VsxYo3KOcbXU0efGB4x002u0SQgYjcHEgRVg3Qi9lXDtMdUNYLMCAaOAlBNWvD/K
CaQrUIM3XvOoVfnpg2JKd/IKg4d0ouUqQkmagTnS+Zbsj5G5vWYt6sL+PcME8cI0
jSGMH7NZhFHk7veChCLJA3jkvF2UKaroQKegs5KI239kG55eYrwhm0lSkkZIeaHC
qLBEsrchAHjii1Mn27O9hK5oNpc/g2HRPEaoSvZGp4V7Q8UD37KsLgjr6jB/3Uy3
yCpREip+uTEZS/wcIRiR2HP03KIfJi9a0y8Ur8uDo/4WcQo5M5GGm+t3zQn4r74t
bxrtYOqWEeZ/xXutTS34DqADaZpdGCAGRDjGBJhRNsO2RMrU2uoGCGPd5H/LLN6y
Ss7/QWcm9EJuXp3waMdr25V49NUWZNo6zg0ywmGrxK7AZMyyD4sFI1btWOf1Z771
q7sAQuPoZ93pWpcKrSFxjGl2YHTS7x+yCEbO4fVOdmDupBW5xMw=
=qEj0
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix runtime PM leak in error path in gpio-xilinx
- fix race when arming the IRQ poll worker in gpio-mpsse
- fix devres cleanup path on probe error in gpio-exar
* tag 'gpio-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: mpsse: fix race when arming the IRQ poll worker
gpio: exar: initialize the ID before registering its cleanup
gpio: xilinx: fix runtime PM leak on request error path
- Update .mailmap entries for Andy Yan and John Garry.
- Fix read-only MAP_SHARED /dev/zero mappings so they retain shared-file
semantics instead of being treated as anonymous memory, also avoiding a
CONFIG_DEBUG_VM assertion.
- Fix 32-bit build warnings in the hugetlb-mmap selftest caused by using the
wrong printf format for size_t values.
- Fix a boot-time crash when early function tracing causes CPA to free kernel
page tables before the workqueues used for deferred freeing are available.
- Fix two MREMAP_DONTUNMAP locked_vm accounting leaks: one caused by an
mlock-on-fault VMA self-merging, and one caused by partially remapping a
locked VMA.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCascg4wAKCRDdBJ7gKXxA
jjLCAP4ygLUaOZmgJVAmD8loFAa/AB0CE1V+LZwBUyzqCogY6wD/Sp+JbhE+mZDS
vjp7soYnDoqv7Gi872WTUx2rnjaLxAg=
=qjI7
-----END PGP SIGNATURE-----
Merge tag 'mm-hotfixes-stable-2026-10-07-21-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull MM fixes from Andrew Morton:
- Update .mailmap entries for Andy Yan and John Garry
- Fix read-only MAP_SHARED /dev/zero mappings so they retain
shared-file semantics instead of being treated as anonymous memory,
also avoiding a CONFIG_DEBUG_VM assertion
- Fix 32-bit build warnings in the hugetlb-mmap selftest caused by
using the wrong printf format for size_t values
- Fix a boot-time crash when early function tracing causes CPA to free
kernel page tables before the workqueues used for deferred freeing
are available
- Fix two MREMAP_DONTUNMAP locked_vm accounting leaks: one caused by
an mlock-on-fault VMA self-merging, and one caused by partially
remapping a locked VMA
* tag 'mm-hotfixes-stable-2026-10-07-21-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
mailmap: update entry for Andy Yan
drivers/char/mem: mmap readonly MAP_SHARED-/dev/zero correctly
selftests/mm: cleanup -Wformat issues in hugetlb-mmap
mm: don't schedule deferred kernel page table freeing while booting
mailmap: update addresses for John Garry
mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP
mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge
Commit ad96ce3252 ("swiotlb: determine potential physical address
limit") changed default_swiotlb_limit() to return the maximum physical
address that could ever be used by dynamically allocated pools, so that
the value stays constant when CONFIG_SWIOTLB_DYNAMIC=y. However,
io_tlb_default_mem.phys_limit is returned even when the default pool
cannot grow, e.g. when swiotlb_init_remap() is called with a remap
callback.
This breaks Xen dom0 on x86: pci_xen_swiotlb_init() passes SWIOTLB_ANY
and xen_swiotlb_fixup(), so phys_limit is set to the top of dom0 memory,
although xen_swiotlb_fixup() makes the default pool below the 32-bit
boundary. xen_swiotlb_dma_supported() then rejects 32-bit DMA masks,
even though the bounce buffer is perfectly usable by such devices.
Return phys_limit only if the default pool can actually grow, otherwise
report the real end of the default pool, like in the
!CONFIG_SWIOTLB_DYNAMIC case.
Reported-by: Andreas Greve <andreas.greve@a-greve.de>
Reported-by: James Dingwall <james@dingwall.me.uk>
Fixes: ad96ce3252 ("swiotlb: determine potential physical address limit")
Closes: https://lore.kernel.org/xen-devel/f74668db-52fd-4575-8372-7bfdf10d62ac@a-greve.de/
Cc: stable@vger.kernel.org
Assisted-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Tested-by: James Dingwall <james@dingwall.me.uk>
Link: https://lore.kernel.org/all/20261005070518.1590097-1-m.szyprowski@samsung.com/
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Protect IPC RX and FW state handler list unregister/dispatch paths with
client_event_handler_mutex to match list registration and locking
comments.
Fixes: 5c19da34df ("ASoC: SOF: Use guard()/scoped_guard() for mutex locks where it makes sense")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20261008090143.15158-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When ch_count is smaller than blob->alh_cfg.device_count (e.g. a mono
capture stream, such as a SmartMic, aggregated across multiple SDW
links), step = ch_count / blob->alh_cfg.device_count truncates to 0.
The subsequent GENMASK(step - 1, 0) then underflows step - 1 (u32) to
UINT_MAX, causing GENMASK()'s internal shift to use an out-of-bounds
exponent:
UBSAN: shift-out-of-bounds in sound/soc/sof/ipc4-topology.c:2363:13
shift exponent 18446744069414584384 is too large for 64-bit type 'long unsigned int'
Treat ch_count < device_count the same way as the existing "channels
equal to output reference channels" case: apply the same ch_mask to
every aggregated device instead of trying to split channels that
can't be evenly divided.
Fixes: 0390a102cc ("ASoC: SOF: ipc4-topology: use different channel mask for each sdw amp feedback")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20261008090130.15135-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 0a8224058a ("drm/imagination: Fix page count for page table for
map() interface") passed the device address to
pvr_mmu_op_context_create(), but the preallocation is still sized from
device_addr + sgt_offset with an exclusive end. The offset into the
object's pages has no place in a device-virtual range, and the exclusive
end allocates one table too many when the range ends on a table
boundary.
Count the tables from device_addr and the inclusive end of the range.
The new calculation does not take page table indices into account. This
fixes another issue with the previous implementation, where the
difference between start and end indices could underflow when a mapping
crossed a page table boundary. This would lead to the driver
preallocating a huge number of MMU pages, exhausting system memory and
triggering an out of memory panic.
Fixes: 0a8224058a ("drm/imagination: Fix page count for page table for map() interface")
Fixes: ff5f643de0 ("drm/imagination: Add GEM and VM related code")
Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Reviewed-by: Alessio Belle <alessio.belle@imgtec.com>
Cc: stable@vger.kernel.org
[Alessio: add paragraph to point out OOM bug being fixed, cc stable]
Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-2-f58254e5dfb8@gmail.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap()
splits the mapping into prev/next parts covering what the request did
not take, instead of creating something new. It gets two things wrong.
- A GEM reference is taken for each part but it's never needed and never
dropped, so it leaks one reference per split (remap-next-in-2m in
tests/imagination/pvr_vm_map.c):
CRITICAL: 33558528 bytes of shmem still held after close
- The parts still belong to the original object being split, but
pvr_vm_gpuva_remap() links them to ctx->gpuvm_bo, the new object's
vm_bo:
prev_va --obj--> BO_A BO_B <--obj-- vm_bo (ctx->gpuvm_bo)
\___________link___________/ (mismatch: BO_A != BO_B)
drm_gpuva_link() catches the mismatch:
WARNING: drivers/gpu/drm/drm_gpuvm.c:2108 at drm_gpuva_link+0x2ec/0x310
drm_WARN_ON(obj != vm_bo->obj)
Call trace:
drm_gpuva_link
pvr_vm_gpuva_remap
__drm_gpuvm_sm_map
pvr_vm_map
pvr_ioctl_vm_map
Link them to op->remap.unmap->va->vm_bo instead.
The locking of the GPUVA lists of the other objects touched by a split is
not addressed here; it is handled by switching the GPUVM to immediate
mode.
Fixes: ff5f643de0 ("drm/imagination: Add GEM and VM related code")
Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
Link: https://patch.msgid.link/20261001-pvr-fixes-a-v2-1-f58254e5dfb8@gmail.com
Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
A fairly small collection of fixes and a few device quirks, nothing
especially remarkable unless you have the affected system.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmrHUbsACgkQJNaLcl1U
h9AKvAf9FWjI/sqtKtjWdYXzI1Mbj+lYnIgv6s4O4IIkcYFg+s5+H5M0SN+ZQhL1
xF9FXRGpWLCrOpYAjQBrmBZMZ/OkcSksW8gIyvbk6xRKv1rZ264vC/zM0Xz0IUNs
Sn1bkFn6fmmDBbd4qWy1cP5cNnCrK7giBYE9T8AjNNXPs1xMqb30bkizMC/0p42A
mldCvQ7yyGQ4GcO62n6qgAxc86YFNMBaZazsOzomQegGShhqabJaFFBNGJZIvLwN
FiAoyHeNhsIGMiNeUut9/SHCfIfSML3rfD3ioih+Qn8TZ8hFCSVjsS5EvvROrvht
aN/UqkcBaVxgRLbsYb9gjL2gYsPeew==
=aLJX
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.3-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.3
A fairly small collection of fixes and a few device quirks, nothing
especially remarkable unless you have the affected system.
Add the compatible for the Synaptics SL2610 SoC SPI controllers, which
are compatible with the Synopsys DesignWare APB SSI.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20261008010058.28382-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There are fixes in three ares this time:
- Four distinct issues in TEE firmware, all fairly minor
- Five devicetree mistakes on NXP i.MX8, lx2160a and Qualcomm
based machines, one of these may cause file system corruption
from an incorrect SD card supply voltage
- Five fixes for clk drivers on new Qualcomm platforms,
addressing issues with incorrect enable states
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmrBd1cACgkQmmx57+YA
GNlYxBAAhJs6mulHyhGSKOHYbvPHHHsCPFcWT6gLZRRy4lA50GwzptT8SAk6TmlS
C6wm81nVG27hdju5TMiExDUfjiTFd3sxpT8xDP1DVNAgZD6+s2LyFrFbAqRs0zxS
SoaZgzsu7q2pD4wBQpQgOM38YODl05CdzwY4YZqiFoomYHSQzI4xlTVGY6/fcJcm
79fRV63LUznRVtsy+ETMg9TdBcJjPY6huuH/C8JifXvl4Q6P99FGXvZp2rpiFqU0
Y3GXA58XtDqUyrwjbUXFrosmqAqsEU5x+iCA1EV2Y1P460rG4jyhXFAYHimJl9UH
Pnfq5Sb2r+JeK1li4HgHX8g3wDr6KUO/biuInNCUAUEFxQ6W7l+NRZTgjisB9m2W
O6Ju0WMXLMvDsm4OMxYyepxcV3fmxzYMvzs36EmJo67OAhETrTCRmU1M8l5N2s50
84wlGoGdLXYoYCKOzLKZBj77Y1zjoYcxBEDx5PLZR2kMWjxtW+zLkKK1NME39691
nDU+NfMAxbMl+28NCtP91ceaVvb+8Zf9vGDcf7RBz6fTZpwUtW9Z9L7x8MVl873a
88oZNHQrGXO+J6VcwskOIhlR5bDCPfpRQm2y2Y+wY6iz/Ie4Jh5n7J8prpzabs43
AuoGpNqHAVrkfklsr66cDzT43XX1KK59+QQwJiOXe5sDetk5m64=
=Mq24
-----END PGP SIGNATURE-----
Merge tag 'soc-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
- Four distinct issues in TEE firmware, all fairly minor
- Five devicetree mistakes on NXP i.MX8, lx2160a and Qualcomm
based machines, one of these may cause file system corruption
from an incorrect SD card supply voltage
- Five fixes for clk drivers on new Qualcomm platforms,
addressing issues with incorrect enable states
* tag 'soc-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
MAINTAINERS: update my email address
tee: optee: ffa: support shared memory offsets on large-page kernels
optee: register TEE devices only once fully initialized
tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper()
arm64: dts: imx8mp-var-dart-sonata: Fix Sonata SD I/O supply
arm64: dts: lx2160a: fix the iic5 spi3 pinmux offset and value
arm64: dts: lx2160a: fix IIC1 pinmux submask rejected by pinctrl-single
arm64: dts: lx2160a: fix incorrect pinmux
clk: qcom: gpucc-kaanapali: Mark the GPU CX GDSC as votable
clk: qcom: gpucc-glymur: Mark the GPU CX GDSC as votable
clk: qcom: gcc-kaanapali: Fix always-enabling PCIE_RSCC clocks
clk: qcom: gcc-hawi: Fix always-enabling PCIE_RSCC clocks
clk: qcom: gcc-eliza: Fix always-enabling PCIE_RSCC clocks
arm64: dts: qcom: x1-denali: Fix microphone distortion
tee: qcomtee: fix kernel-doc warnings
This splat is reporting a double-dereference that can result in garbage
traces being dumped due to the possibility of the TP_printk() being
executed without the benefit of main memory being present. The fix is to
move the extra dereference from TP_printk() time to TP_fast_assign() time.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEbK7UrM+RBIrCoViJnr8S83LZ+4wFAmrFPjETHHBhdWxtY2tA
a2VybmVsLm9yZwAKCRCevxLzctn7jFa3D/4yDuCA4eVlyw8Ldqh0bCjbZCPAz421
TUXA+KU7jQaUy3mVWNyLDpFdOe6cChXskdxnEpzwXeze+05bK1nbu0jEXACU2edO
xhbbS20KirhgZcZvS4XdgF2d7RFiHG79ajbsLwy2e1JlO3EtCklVfISLcjB4Xi9S
wASHI6loJ4ev6YD6InFsPQVgN19m9SuuVGQRPgtHnzuPrlWxv6KuQg2DMwiJyLI1
13/bOSiLNwVlHynMvtmv/o7Qi1XszhIjG7qotdc8TJPjcjL0grP6qSOr7/QrZxfQ
nUsdyVJ+WDarAArQ/Femk4IDRiqYMnLFxN65Ol1CGUlpTkQluU8deqgj5qvEQFVX
SopYFDqj4fL7prdfhtOML3DCXtJZ6BAWAA24HUCL7zJ2+pYT57USk6OiSNsIUS8Y
khCsW+1pzEInb8PRI7h9dvUu6jRn407PTytKZ4GNt6PnLzDWb8wvRpy+Jjzsr6LS
NLyjkNlAVYMBItsfg+Y/9Lt6uqhpioz42+/3J5bsxTqksM4BNSRSZ+paJs/fNgFk
drMxMuo5gsI8zQsKaVL6QlIKEChJPKzRzEIOJYKUDx3uhpwbtHO2551KGlQZIRNL
ZbXZEDfgAHfGJ3ho3QZ/AyLzFiB+WUbT5+gw6mYNzjiUFObMlgU6p6Z/rS/eMNPi
1qR4UHl0fRvu1Q==
=MAuw
-----END PGP SIGNATURE-----
Merge tag 'usb-mtu3.2026.10.06a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull tracing fix from Paul McKenney:
"Fix a double-dereference splat in TP_printk in usb mtu3. This was a
pre-existing bug that can corrupt tracing output, but which was
exposed this cycle by additional checking that was added to the
tracing subsystem.
This splat is reporting a double-dereference that can result in
garbage traces being dumped due to the possibility of the TP_printk()
being executed without the benefit of main memory being present.
The fix is to move the extra dereference from TP_printk() time to
TP_fast_assign() time"
* tag 'usb-mtu3.2026.10.06a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
usb: mtu3: Fix double dereference in TP_printk
This issue was introduced during the recent merge window:
78a38cbf6f ("srcu: Queue sdp->work when the delay timer is successfully deleted")
Enough people are hitting this that I am sending it now rather than
waiting for the next merge window. Especially given that it is a
simple one-liner.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEbK7UrM+RBIrCoViJnr8S83LZ+4wFAmrAGcUTHHBhdWxtY2tA
a2VybmVsLm9yZwAKCRCevxLzctn7jEqAD/4pwYiV6hn+i79v16TURcSpUwqAKwT1
lTX9OsnUvN2HkXBvrGXPlom9ZiyucpfzgZ95FasEezyLKvcuW/vOs7M4dZ7K8jmK
89grMnktxzDIrzqBXIvLINQdTzDQAn5cH88QXcqmQDKLaEaKo20fWyXq5AKhva3a
lvSXAA195s1AZkRRabY/TybsE57IMWrJ4PiG7h9xxuQi6rjtpEF3B0XQKn62hywx
BnYy5WHEnhufAQ4ubKdxQws7nQM+UGmShtcweQq/zeRiaVd1X3nnaR1L+28kVI3y
y1pQkjjo7vPMmge31qIXerwK3hx0x0XfN+CW9roOtAIKGDlItaLFn8j1KO7m7xx7
Lz+H28j8RNET+E/3ADuhZv/z8hL9iat5cGFzZqixDAmvbd44p8LVwMhXpJaiIXvH
0ca9OaN3U7AiKPotAdGJP8i2GdbkDeObKZ23WG39zguXPzrrbB2lTphY9VZNpXTp
FEqwojNRzeO3beC650Vjc2VPpGiSCUznOoOl6z+mfyywXxgRNOJ4m8+WBVps+Rfc
YWX7NeK6VWo67U5c5YS4WgUS+J2RWu0ca8E37yyhylEzgT1rHxz5AlB3dnw2PcOw
NitOFoyVTpvvxY6pfOiktd5nvX2Saz+6DMvkYcn4gwL8DhHwBEvCiH8YtQBK6cgJ
XV0vcx8+eQieOA==
=a4pP
-----END PGP SIGNATURE-----
Merge tag 'urgent.2026.10.01a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux
Pull RCU fix from Paul McKenney:
"Fix spurious WARN_ON() for rcu_segcblist_n_cbs() in
cleanup_srcu_struct()
This issue was introduced by 78a38cbf6f ("srcu: Queue
sdp->work when the delay timer is successfully deleted")
during this merge window.
Enough people are hitting this that I am sending it now
rather than waiting for the next merge window. Especially
given that it is a simple one-liner"
* tag 'urgent.2026.10.01a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux:
srcu: Fix WARN_ON() for rcu_segcblist_n_cbs() in cleanup_srcu_struct()
The fixup for load_unaligned_zeropad() runs when REG_L crosses into an
unmapped page. REG_L is lw on RV32 and ld on RV64, but the fixup assumes
an 8-byte load: it rounds the address down to 8 bytes and derives the
shift from three address bits.
On RV32, a load starting in the last three bytes of a mapped page selects
the word four bytes earlier and shifts it by 40, 48, or 56 bits, more than
the register width. The caller gets earlier bytes instead of the string
tail followed by zeroes. This affects RV32 MMU kernels built with
RISCV_EFFICIENT_UNALIGNED_ACCESS=y, which selects DCACHE_WORD_ACCESS
and lets dcache name hashing and comparison and strscpy() use this
path.
Derive the alignment and offset masks from sizeof(data) instead of a fixed
8. This makes RV32 use the correct source word. RV64 code is unchanged: the
complete extable.o is byte-for-byte identical before and after.
Fixes: d0fdc20b04 ("riscv: select DCACHE_WORD_ACCESS for efficient unaligned access HW")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20260907190750.26303-1-kmehltretter@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust
cached offsets for options that follow them.
For example, with a valid 10-byte CIPSO option followed by a seven-byte
RR option, parsing records rr at offset 30. Removing CIPSO moves RR to
offset 20, while the cached offset remains 30. Consumers such as
ip_forward_options() and __ip_options_echo() then access the wrong bytes;
the latter may interpret packet data as the option length and copy it into
fixed-size option storage.
Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and
router_alert offsets when they follow CIPSO. cipso_len is the distance
the first memmove() shifts those options. The later header move and
network-header reset relocate the bytes and their offset base together.
Fixes: 89aa3619d1 ("cipso: make cipso_v4_skbuff_delattr() fully remove the CIPSO options")
Cc: stable@vger.kernel.org
Reviewed-by: Ondrej Mosnáček <omosnacek@gmail.com>
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Link: https://patch.msgid.link/20261006035108.3101440-1-4ncienth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bareudp_xmit_skb() sets the inner protocol of the skb to the configured
ethertype, and bareudp6_xmit_skb() does not set it at all. The inner
protocol is used by skb_udp_tunnel_segment() to segment the inner packet
when GSO has to be done in software, for instance when the lower device
does not offload the checksum.
With multiproto, an IPv4 device also carries IPv6, so the IPv6 header
is parsed as an IPv4 one. With IPv6 underlay, the inner protocol is
whatever the skb had before. In both cases segmentation fails and the
packets are dropped. With veth tx checksum offload disabled, iperf3 TCP
over bareudp gets about 10 Mbit/s with thousands of retransmits instead
of about 700 Mbit/s for IPv6 over IPv4 and for both families over IPv6,
while IPv4 over IPv4 works.
At this point skb->protocol is the protocol of the inner packet, which
bareudp_xmit() has already checked against the configuration, so use it
on both paths.
Fixes: 571912c69f ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
Fixes: 4b5f67232d ("net: Special handling for IP & MPLS.")
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20261002153039.462663-1-yanhaishuang@cmss.chinamobile.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Javier reports seeing packet loss issues related to the re-enablement
of K1; disabling it makes the issues go away. Add the reported system
to have K1 disabled by default.
Reproduction steps (from the Link):
Plug the cable and ping the default gateway on the LAN. No suspend/resume
involved, machine freshly booted and on AC power. Nothing e1000e-related in
dmesg apart from the link up/down messages; no "Hardware Unit Hang".
Default (K1 enabled):
$ ping -c 30 192.168.10.1
--- 192.168.10.1 ping statistics ---
30 packets transmitted, 18 received, 40% packet loss, time 29734ms
rtt min/avg/max/mdev = 0.211/0.315/0.384/0.046 ms
The lost packets are spread over the run (seq 6, 8, 9, 11, 13, 14, 16, 19,
20, 24, 25, 30), not a single burst. DHCP on this link also takes 1-2
minutes to get a lease, consistent with incoming packets being dropped.
With K1 disabled at runtime:
# ethtool --set-priv-flags enp0s31f6 disable-k1 on
$ ethtool --show-priv-flags enp0s31f6
Private flags for enp0s31f6:
s0ix-enabled: on
disable-k1 : on
$ ping -c 30 192.168.10.1
--- 192.168.10.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29713ms
rtt min/avg/max/mdev = 0.169/0.251/0.468/0.054 ms
$ ping -c 30 192.168.10.1
--- 192.168.10.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29677ms
rtt min/avg/max/mdev = 0.101/0.222/0.360/0.064 ms
I have only compile tested this, but Javier has tested that disabling K1
on his system (Lenovo ThinkPad P14s Gen 5 (Intel), I219-LM [8086:550a])
resolves his issues.
Cc: stable@vger.kernel.org
Fixes: 578294b8b6 ("e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor Lake")
Reported-by: Javier Herrera <javier.herrera@afronta.com>
Link: https://lore.kernel.org/intel-wired-lan/CAKRuCQLWEcci9hPgNUmvq44Bd2H30T5_vP=exMjsknXMN5Yh9A@mail.gmail.com/
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20261001222443.3500206-7-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel
shadow call stack pointer (gp) only when the trap came from userspace.
It made that decision with scs_load_current_if_task_changed, which
compares the trap-time tp (read back from sscratch into s5) against the
current tp:
beq \prev, tp, _skip_scs
scs_load_current
_skip_scs:
tp is a user-writable register. A user task that sets tp to the
linear-map address of its own task_struct (¤t) before trapping
makes the comparison succeed (can achieve by brute force with KASLR
enable under our test), so the kernel skips scs_load_current and
keeps running with the gp that userspace left in place. Under
CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and
load_global_pointer is a no-op, so the compiler-emitted
"sd ra, -8(gp)" / "ld ra, -8(gp)" in every non-leaf function then write
to, and return through, an attacker-controlled address -- an
unprivileged kernel arbitrary-write and control-flow-hijack primitive.
The poisoned gp is saved to task_struct.scs_sp on return, so the reload
is skipped on every subsequent entry as well.
Decide "came from userspace" from the hardware sstatus.SPP bit (already
in s1 at this point) instead of from tp, mirroring the check that
ret_from_exception already uses a few instructions later. SPP is
written by hardware on trap entry and cannot be forged from U-mode.
Legitimate behaviour is unchanged: user entries (SPP=0) reload the task
shadow call stack, nested kernel entries (SPP=1) skip it.
Fixes: d1584d791a ("riscv: Implement Shadow Call Stack")
Signed-off-by: Ziyi Guo <guoziyi114@gmail.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://patch.msgid.link/20261001135711.934152-1-guoziyi114@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Paul Walmsley <pjw@kernel.org>
bpf_flow_dissect() sanitizes the offsets returned by the BPF program
with clamp_t(u16, ..., hlen).
If hlen is bigger than 65535, the upper bound is truncated before
the comparison. For instance, with hlen == 65536, both nhoff and
thoff are forced to zero, even if the program returned sane values.
This is the same class of bug as the one fixed in commit 99bda1ecbd
("flow_dissector: avoid u16 truncation of skb->len when computing
thoff"). That fix does not cover the BPF path, because
__skb_flow_dissect() returns early when a BPF flow dissector
handles the packet.
struct bpf_flow_keys stores nhoff and thoff as u16, so cap hlen
to U16_MAX before clamping.
Found by sashiko while reviewing the commit above.
Fixes: d58e468b11 ("flow_dissector: implements flow dissector BPF hook")
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20261007045616.445596-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412
NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces:
DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000
[fault reason 0x06] PTE Read access is not set
bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001
...
NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out
The fault address (0xfc499000) is on an exact 4KB page boundary,
pointing to a DMA read buffer overrun.
In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes),
such as 42-byte untagged ARP frames, are padded:
if (length < BNXT_MIN_PKT_SIZE) {
pad = BNXT_MIN_PKT_SIZE - length;
if (skb_pad(skb, pad))
goto tx_kick_pending;
length = BNXT_MIN_PKT_SIZE;
}
mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE);
...
dma_unmap_len_set(tx_buf, len, len);
However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes)
and is left unadjusted after padding. Consequently, dma_map_single() and
dma_unmap_len_set() map and track only 42 bytes.
Later, the hardware TX buffer descriptor is programmed with the padded length:
txbd->tx_bd_len_flags_type =
cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags |
TX_BD_FLAGS_PACKET_END);
The NIC DMA engine is thus instructed to read 52 bytes from a region where
only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB
page (within 'pad' bytes of the next page), the hardware DMA read overruns
into the unmapped adjacent page, triggering an IOMMU fault.
This issue was exposed after commit 447cbe95eb ("vlan: fix skb_under_panic
and races when toggling HW VLAN offload") because reserving extra VLAN
headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes, shifting skb->data
offsets and potentially causing small frames to land right against page
boundaries.
Fix this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in
bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags is sampled,
because padding might linearize the skb.
This ensures skb->len and skb_headlen(skb) reflect the padded size so
that dma_map_single() maps the full buffer and the descriptor length is
consistent. This also removes the temporary 'pad' variable and masking logic.
The padding is done after the SW USO branch, otherwise
bnxt_sw_udp_gso_xmit() would account the padding as UDP payload
and send it in extra segments.
Note that SW USO segments are still not padded: with IPv4, a segment
carrying less than 10 bytes of UDP payload (small gso_size, or a short
last segment) is sent as a frame shorter than BNXT_MIN_PKT_SIZE.
This is a separate issue, left for a followup patch.
Fixes: c0c050c58d ("bnxt_en: New Broadcom ethernet driver.")
Cc: stable@vger.kernel.org
Reported-by: Stefan Fleischmann <sfle@kth.se>
Closes: https://lore.kernel.org/netdev/20261004122616.56714cbd@nargothrond/
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Link: https://patch.msgid.link/20261007051747.455273-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michael Chan says:
====================
bnxt_en: PCIe FLR/AER fixes
This patchset is split from the earlier 9-patch series to limit the
fixes to the PCIe FLR/AER issues only (patches 7 to 9). The other
fixes (patches 1 to 6) will be sent to net-next separately.
The 1st patch is unchanged since v1. It refactors a bnxt_clear_bars()
helper needed by patch 2 and 3. Patch 2 fixes an issue during driver
init. in the kdump kernel on a Dell system with a smart PCIe switch
upstream from the NIC. Patch 3 fixes an issue in the AER code path for
non-fatal errors found by a partner.
These patches have been regression tested on Broadcom 5750X and 5760X
NICs running 237.x.x.x production FW.
====================
Link: https://patch.msgid.link/20261005204246.3822563-1-michael.chan@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently the driver zeroes the BARs only when fatal PCIe errors
are reported so that pci_restore_state() restores it. However
firmware handles both fatal and non-fatal errors the same way when
it sees the slot reset resulting from the PCI_ERS_RESULT_NEED_RESET
return code from the driver. This means that we must re-write the
BARs post recovery even during non-fatal errors. Otherwise we will
see that every MMIO access returns all-ones and the firmware appears
dead.
Zero-out the BARs during PCIe error recovery regardless of type of
PCIe error, and make the wait after the hot reset unconditional.
Disable memory decode and bus mastering before rewriting the BARs so
the device doesn't decode a half-updated address, bailing out if
config space is still inaccessible. Defer pci_enable_device() until
after the BAR rewrite and restore, so the device isn't re-enabled
while its BARs are still being rewritten, then re-enable the device
and re-assert bus mastering. Guard the same Command register cleanup
on the re-enable failure path against an inaccessible device.
Skip re-enabling the device in bnxt_io_slot_reset() if it is already
enabled, so enable_cnt does not go unbalanced. A concurrent
bnxt_fw_reset_task() can also be re-enabling the same device in its
ENABLE_DEV state, so guard that call the same way.
Fixes: f75d9a0aa9 ("bnxt_en: Re-write PCI BARs after PCI fatal error.")
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20261005204246.3822563-4-michael.chan@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix and strengthen the FLR sequence when initializing in the kdump
kernel. If the NIC is behind a PCIe switch in synthetic (smart)
mode, the switch may need to see that the BARs have been initialized
before it will pass mem read/write TLPs to the NIC.
On a Dell system with a PEX89144 PCIe switch, echo c > /proc/sysrq-trigger
will trigger fatal AER without this patch:
bnxt_en 0000:67:00.0: enabling device (0000 -> 0002)
[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5
[Hardware Error]: event severity: recoverable
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section_type: PCIe error
[Hardware Error]: port_type: 5, upstream switch port
...
Add a new bnxt_kdump_reset() to do the expanded FLR sequence in the
kdump kernel. We now disable bus master and memory, save the PCI
state, do the FLR, clear the BARs, and restore the PCI state. The
BARs have to be cleared to ensure that they get re-initialized and
visible to the PCIe switch.
Since it is the kdump kernel, we make every effort to continue in
the best possible way even if pci_save_state() or pcie_flr() returns
error. After FLR, we poll for an additional 5 seconds before
aborting in case the device is not properly returning CRS. This is
similar to the 5-second wait in bnxt_io_slot_reset().
Fixes: 8743db4a9a ("bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs.")
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20261005204246.3822563-3-michael.chan@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In bnxt_io_slot_reset(), we clear the 6 BAR registers. Add a helper
function to do that. The helper will be used again in the next patch.
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20261005204246.3822563-2-michael.chan@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 4ce62d5b2f ("net: usb: ax88179_178a: stop lying about
skb->truesize") replaced skb_clone() with a copy into a new skb for
every packet of a bulk-in transfer except the last one. The copy skips
the 2-byte IP alignment pseudo header but still copies pkt_len bytes,
and pkt_len includes that header. Each of these frames is therefore
delivered with two extra trailing bytes: the 0xeeee pseudo header of
the next slot when the frame ends on an 8-byte boundary, or slot
padding otherwise. The last packet is still trimmed to pkt_len - 2.
IPv4 and IPv6 trim the extra bytes, so most traffic is unaffected.
Anything that relies on the frame length is not. MACsec takes the ICV
from the last 16 bytes and drops every such frame as InPktsNotValid. In
our setup that was 0.2-1.2% of received MACsec frames, depending on how
many frames shared a transfer, including service discovery multicast.
Allocate and copy pkt_len - 2 bytes, like the last-packet path.
Fixes: 4ce62d5b2f ("net: usb: ax88179_178a: stop lying about skb->truesize")
Cc: stable@vger.kernel.org
Signed-off-by: Fredrik Nyberg <fredrik.nyberg@volvocars.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261002-ax88179-rx-len-v1-1-f01a2a295079@volvocars.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This reverts commit 13ff543e0b.
The 'goto free' just made things worse, causing a spinlock
to be handled incorrectly. Revert this for now.
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org
Fixes: 13ff543e0b ("wifi: libertas: reject short monitor TX frames")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
current_is_workqueue_mem_reclaim() uses current_wq_worker() to decide
whether %current is a workqueue worker and then checks the current
workqueue flags. However, current_wq_worker() only implies that %current
is a kworker; it does not imply that the worker is currently executing a
work item.
worker->current_pwq is set while process_one_work() runs the work
function and cleared afterwards. A kworker outside work-item execution can
therefore have PF_WQ_WORKER set with current_pwq cleared.
Guard the flag check with worker->current_pwq. Without a current_pwq, the
worker is not executing on a WQ_MEM_RECLAIM workqueue, so the helper
should return false.
Fixes: da729ddd4a ("NFS/localio: issue IO inline when not in a memory-reclaim context")
Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Rather than adding a case of every chip where this is seen
just check if the FB is at 0 and the ssid is apple. This
should cover all chips which fall into this case.
Tested-by: Ayhan Çiçek <ayhancicek@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c54e4d1050)
Cc: stable@vger.kernel.org
When kzalloc fails for metadata_buffer in
amdgpu_amdkfd_get_dmabuf_info(), the function returns -ENOMEM directly
without calling dma_buf_put(), leaking the dma_buf reference obtained
earlier via dma_buf_get().
Fix both issues by:
- Adding an error check after the first amdgpu_bo_get_metadata() call
- Replacing the direct return with r = -ENOMEM and goto out_put to
ensure dma_buf_put() is called on all error paths
Fixes: f54ce9e8cb ("drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl")
Signed-off-by: Haojie Li <lihaojie@kylinos.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ffa6995533)
Cc: stable@vger.kernel.org
decide_crtc_timing_for_drm_display_mode() copies the native mode's CRTC
timing into the requested mode when clock, htotal and vtotal match.
That is meant for the modes amdgpu inserts itself:
amdgpu_dm_create_common_mode() duplicates the native mode and changes
only hdisplay and vdisplay, so those are sent with the native timing
and scaled.
A sink can also offer a real mode with the same clock and totals as
its native mode. CTA-861 VIC 102 (4096x2160@60) and VIC 97
(3840x2160@60) both use 594 MHz and 4400x2250. With 3840x2160@60 as
the preferred mode, a 4096x2160@60 request goes out with the 3840x2160
timing and the framebuffer scaled into it (dst 3840x2025 at y=67),
while the AVI InfoFrame still carries VIC 102. A JVC projector then
reports 3840x2160 and shows a corrupted right edge. 4096x2160@24,
whose totals differ, is sent and displayed correctly.
Inserted modes keep the native sync positions; a real mode with its
own active width does not. Compare those too, so only inserted modes
are patched.
Fixes: 4562236b3b ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Adrian Betschart <adrian.betschart@cinemaone.ch>
Assisted-by: Claude-Code:claude-opus-5-5
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 22f9a2da10)
Cc: stable@vger.kernel.org
On GC 9.4.3, 9.4.4 and 9.5.0, doorbell writes issued from shaders are
routed to an SDMA engine at 32-byte (4 doorbell index) granularity.
SDMA engine doorbell ranges are 10 indices apart, so the range of every
odd engine starts 2 indices into a 4-index block that begins in the
previous engine's range. A shader ringing the doorbell of a queue on an
odd engine therefore rings the previous engine instead. The intended
queue never sees the doorbell, so its work stalls and the application
hangs.
Align the per-engine doorbell base up to a 4-index boundary on these
ASICs. Each engine only uses 4 of its 10 indices, so the aligned base
plus the queue offset stays within the engine's range. Even engines are
already aligned, so only the doorbell IDs of odd-engine queues change.
Only doorbells rung by the device itself are routed this way. Doorbell
writes from the host, including the kernel's own SDMA rings, are not
affected.
The doorbell ID of an SDMA queue is saved in CRIU checkpoints and
checked again on restore. A checkpoint taken before this change that
contains an SDMA queue on an odd engine will fail to restore with
-EINVAL. This is intentional: the restored process still holds the old
doorbell address, so accepting the stale ID would bring back the same
stall.
Tested on MI300X with a shader-rung SDMA doorbell test: queues on odd
engines hung before this change and complete with it.
v2: use u32 instead of uint32_t for the new locals (checkpatch)
v3: name the routing granularity, use dev->node_id, document the
layout invariants, describe impact
v4: express the granularity in doorbell indices, drop unrelated
cleanups, explain the CRIU restore behavior, add test note
Fixes: 6df442a03d ("drm/amdgpu: add new doorbell assignment table for aqua_vanjaram")
Signed-off-by: Saleel Kudchadker <Saleel.Kudchadker@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ee1379e6d7)
Cc: stable@vger.kernel.org
Reading or writing a register through the amdgpu_regs2 debugfs file
with GRBM bank selection, which umr does for every banked access (a
single "umr -b x x x -r <reg>" is enough, as is the wave dump with
"-O halt_waves"), makes lockdep report a circular locking dependency,
after which lockdep stays off until reboot:
WARNING: possible circular locking dependency detected
umr/63306 is trying to acquire lock:
ffff8882cf4b8350 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x9b/0x140
but task is already holding lock:
ffff8881aec010d0 (&amdgpu_grbm_lock_key){+.+.}-{4:4}, at: amdgpu_debugfs_regs2_op.isra.0+0x20d/0xd00 [amdgpu]
...
Chain exists of:
&mm->mmap_lock --> &amdgpu_srbm_lock_key --> &amdgpu_grbm_lock_key
...
__might_fault+0xc5/0x140
amdgpu_debugfs_regs2_op.isra.0+0x441/0xd00 [amdgpu]
full_proxy_write+0x10e/0x1d0
vfs_write+0x1d0/0xf50
ksys_write+0x116/0x250
amdgpu_debugfs_regs2_op() and amdgpu_debugfs_process_reg_op() call
get_user()/put_user() for every dword while holding grbm_idx_mutex or
srbm_mutex, and pm.mutex if requested, so a fault there takes mmap_lock
inside those locks. The lock hierarchy in amdgpu_lockdep.c puts
srbm_mutex and grbm_idx_mutex below notifier_lock, which
amdgpu_cs_submit() takes with the BO reservations held, and
dma_resv_lockdep() orders the reservations inside mmap_lock. So
mmap_lock is outside grbm_idx_mutex and srbm_mutex, and these two
debugfs paths nest it the other way round. The copies under the locks
are as old as the bank selection in both files; commit 1d0f5838b1
("drm/amdgpu: Add lockdep annotations for lock ordering validation")
only made them visible to lockdep.
Copy the user buffer in before any of the locks is taken and the result
out after all of them are dropped, as amdgpu_debugfs_wave_read(),
amdgpu_debugfs_gpr_read() and amdgpu_debugfs_gprwave_read() already do.
The buffer is sized by the count passed to read() or write(), so an
access larger than PAGE_SIZE is now rejected with -EINVAL; umr reads and
writes one register at a time. A fault on the user buffer of a write now
fails with -EFAULT before any register is written, instead of after a
partial write.
Fixes: 5662815950 ("drm/amd/amdgpu: Add bank selection for MMIO debugfs (v3)")
Fixes: 37df9560cd ("drm/amd/amdgpu: New debugfs interface for MMIO registers (v5)")
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ccf9e35ed6)
Cc: stable@vger.kernel.org
The vblank counter callback reads display registers and scanout
position without holding reset_domain->sem. During GPU recovery,
display commit work can call the callback while reset owns the
semaphore for writing. The hardware access then triggers the
lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets
TAINT_WARN when lockdep is enabled.
Try to acquire the reset semaphore for reading before accessing the
hardware, and hold it across the counter and scanout-position reads.
If reset is already in progress, return DRM's cached software vblank
count instead. This avoids blocking behind reset and avoids accessing
display hardware while it is being reset.
The cached count is less accurate than the hardware count, but is
used only when reset prevents a safe hardware read. This addresses
the reset-time warning from this vblank path; it does not suppress or
fix unrelated lockdep warnings.
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Sunpeng Li <sunpeng.li@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Sunpeng Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 51a4359f74)
Cc: stable@vger.kernel.org
[Why & How]
Immediate (tearing) flips breaks self refresh state machine assumptions,
so disable PSR/Replay for them.
Tested-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit acbdd213b3)
Cc: stable@vger.kernel.org
mes_userq_mqd_create() returns -ENOMEM when copying the user MQD fails,
even though memdup_user() returns -EFAULT for a bad pointer or -EINTR
when interrupted by a signal. Return PTR_ERR() instead.
While at it drop the error messages. Neither case is a driver error and
userspace shouldn't be able to spam the log with invalid IOCTL
parameters.
v2: drop the error messages (Christian)
Fixes: 2c695d7c07 ("drm/amdgpu: enable compute/gfx usermode queue")
Fixes: 543b614537 ("drm/amdgpu: enable SDMA usermode queues")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 49a443fcb8)
Cc: stable@vger.kernel.org
amdgpu_userq_get_doorbell_index() pins any BO passed as doorbell_handle
into the doorbell domain. For a regular BO, TTM moves it with
ttm_bo_move_null() and its contents are lost. Since an importer on the
same device gets the exporter's GEM object, a client can do this to a
buffer another client shared with it.
Reject BOs that were not created in the doorbell domain.
v2: drop the error message, use a local abo variable (Christian)
Fixes: f09c1e6077 ("drm/amdgpu: generate doorbell index for userqueue")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f7497bbc19)
Cc: stable@vger.kernel.org
[Why]
DM was declaring it's own list of has_alpha DRM formats to check against
for enabling alpha blending, when the format->has_alpha already does
that for us.
The self-declared list missed some has_alpha formats, causing
direct-scanout planes with such formats to appear opaque.
[How]
Drop the self-declared list, instead use the format->has_alpha field
directly.
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9ecdac91ed)
Cc: stable@vger.kernel.org
user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET
request with a short iov_len leaves the rest of the stack buffer
uninitialized. In riscv_vr_set() that garbage is validated and copied
into the target's vstate, and in riscv_cfi_set() it can be stored as
the target's shadow stack pointer. Zero both buffers, as the get path
already does.
Fixes: 9300f00439 ("RISC-V: Add ptrace support for vectors")
Fixes: 2af7c9cf02 ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files")
Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
Link: https://patch.msgid.link/20260826115711.86861-1-min_halo@163.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
riscv_cfi_get() and riscv_cfi_set() do not check whether the Zicfilp
or Zicfiss extensions are present. On systems without them,
PTRACE_GETREGSET on REGSET_CFI still succeeds and returns a zeroed
user_cfi_state, misleading debuggers into believing the register set
is available, and PTRACE_SETREGSET silently accepts writes that have
no effect (e.g. clearing SR_ELP).
Reject the access with -EINVAL when neither branch landing pads nor
shadow stack is available to userspace, using the same availability
helpers as the prctl path.
Fixes: 2af7c9cf02 ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files")
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
Link: https://patch.msgid.link/20260820063233.2567-1-cp0613@linux.alibaba.com
Cc: stable@vger.kernel.org
Signed-off-by: Paul Walmsley <pjw@kernel.org>
rv32_defconfig is built in two stages:
- the generic (64-bit-oriented) "defconfig" target runs first
and resolves a concrete NR_CPUS value using the 64BIT default.
- then 32-bit.config is merged on top via merge_config.sh,
which does not touch NR_CPUS.
The final "make olddefconfig" pass sees NR_CPUS=256 is still within
the "2 512" range therefore never recalculates it against the 32BIT
default of 32, silently keeping the leaked 64-bit-stage value.
The NR_CPUS-scaled regions (percpu areas, ...etc) of the resulting
CONFIG_NR_CPUS=256 on a 32-bit build bloats and does not fit in the
percpu/stack layout for rv32 and hangs early boot on QEMU's virt machine.
Fix this by explicitly specify the range for 32/64 and SBI_V01/!SBI_V01.
Fixes: 0fa7497719 ("riscv: Raise default NR_CPUS for 64BIT to 256")
Signed-off-by: Leo Yu-Chi Liang <leo.liang@sifive.com>
Link: https://patch.msgid.link/20261007045229.36114-1-leo.liang@sifive.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
