mirror of
https://github.com/torvalds/linux.git
synced 2026-10-16 04:39:02 +02:00
cb86607ada
1465241 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Puranjay Mohan
|
f8f2b567d5 |
bpf: Inline bpf_iter_num_new() kfunc
bpf_for() expands to the bpf_iter_num_{new,next,destroy}() kfuncs, which
the verifier emits as regular calls. They are tiny and only touch the
8-byte on-stack iterator state, so open-code them in bpf_fixup_kfunc_call()
like the other special kfuncs there.
Start with bpf_iter_num_new(): R1 points to the iterator, R2/R3 hold
start/end. The inlined sequence mirrors the kfunc and returns the same
-EINVAL / -E2BIG / 0.
start > end is rejected first, so end - start fits in a u32; range-check
it as u32 on both sides ((u32)(end - start) in the kfunc). A movsx-based
check would emit a cpuv4 instruction that some JITs (x86-32, mips32,
sparc64) decode as a plain move and get wrong.
The emitted instructions are plain BPF, so the interpreter path stays
correct and no jit_required marking is needed.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260804134601.2305303-3-puranjay@kernel.org
|
||
|
Puranjay Mohan
|
8efd87051c |
bpf: Correct the overflow check comment in bpf_iter_num_next()
The comment on the s->cur + 1 >= s->end check claims the (s64) cast is needed to avoid overflow when s->cur == s->end == INT_MAX. It isn't: s->cur + 1 is computed in int and wraps before the cast, so the cast changes nothing (INT_MAX + 1 compares the same either way). The wraparound is the point. bpf_iter_num_new() sets s->cur = start - 1, which wraps to INT_MAX for start == INT_MIN, and the wrapping s->cur + 1 brings it back to start. (s64)s->cur + 1 would instead break iterators starting at INT_MIN. Drop the cast and reword the comment. No functional change; the wrap is well-defined under -fno-strict-overflow. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260804134601.2305303-2-puranjay@kernel.org |
||
|
Linus Torvalds
|
0d83957076 |
SoC fixes for 7.2, part 2
The majority of the fixes this time is for Qualcomm devicetree files, addressing various incorrect settings in chip specific dtsi files that prevent some feature from working correctly. Another three such issues are addressed on the Broadcom bcm5301x and bcm2712 SoC platforms. Two minor issues are addressed in nuvoton and aspeed specific SoC drivers, and the MAINTAINERS file is updated to add Billy Tsai and Ryan Chen as aspeed reviewers as well as clarify the NXP/Freescale entries. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpyTNUACgkQmmx57+YA GNmeThAAttKVEz+dS4P5j3MUPMxISPYg1GL7bePrP2bqXYpy28i6nsyMhgcm3Bf7 SgQEsFG4QCsJa2jkk46LDRGs+sSvtk9zNJOFklQ54KRhUQp/o4txzT7m4t8tY7Sj KodLk6lSj8iw8BrLVbYGs8wSxu2IdKZhi7ILiapZSlmxVTVrRF/+gQf9JFaX5KY3 GJS+hN3rX4+N9jxyrzvlUJP8aK4H2pchZbB1ZqBAAy7SLdXfU2lNKr1NX1oIUyAn VIbonzPnu+mZeSnPjUzZBGzMJHgC+XjUi7ntk5Ab1aBLDLXDC2QPGo3qTo1cIHQi C+/9cMkVvkCdZMXwEyQY12S43FjBQeLPkcFah5HNAO6m5+q4qo2UcHyBXGlaDAoT EGYw4fibd8UjI1shWQrx9Qsq0lHYi+uLtE2iJPsCoQPFiFK7tn3d3MisCbp91r5h XDP5WdAW1MERGpTyHvVqB2pBiqyRt9wFMa98GHEEPk989jV0X1YHuHWSHYr/ZhU1 0wdr4XTDB3qrkIlGaDddwt5hTb8/D2eHHS8RNHHZkYVa+Bi4t8dZB5rSRn5au6Qq YrHPIvkNqJF7RbjzhmQq242vtZaUR3x0d6e6X/VE+WuTmLaUF33+AoHlwGn3TWN4 OUmoBsMJ0ZVskOgiqR/VhlDeLOEDXTXd31DvnXzV/tsU9LGGVaY= =1+QO -----END PGP SIGNATURE----- Merge tag 'soc-fixes-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The majority of the fixes this time is for Qualcomm devicetree files, addressing various incorrect settings in chip specific dtsi files that prevent some feature from working correctly. Another three such issues are addressed on the Broadcom bcm5301x and bcm2712 SoC platforms. Two minor issues are addressed in nuvoton and aspeed specific SoC drivers, and the MAINTAINERS file is updated to add Billy Tsai and Ryan Chen as aspeed reviewers as well as clarify the NXP/Freescale entries" * tag 'soc-fixes-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: MAINTAINERS: add Ryan Chen and Billy Tsai as reviewer for ARM/ASPEED ARM: dts: BCM5301X: EA9200: fix NVRAM size ARM: dts: BCM5301X: fix PCIe controller 2 second interrupt arm64: dts: qcom: eliza: Fix DSI1 phy reference clock rate MAINTAINERS: ARM/FREESCALE: merge Layerscape entry into i.MX entry ARM: npcm: Fix OF node refcount leaks in SMP setup soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer arm64: dts: qcom: sdm850-lenovo-yoga-c630: lower PSCI cluster idle arm64: dts: qcom: sc8280xp: gaokun3: correct EC interrupt pin arm64: dts: qcom: sc8280xp: add several missing pdc map entries arm64: dts: qcom: sm8650: Fix IPA IMEM slice arm64: dts: qcom: monaco: Add default GIC address cells arm64: dts: qcom: purwa: Fix GPU IOMMU property arm64: dts: qcom: glymur: fix QUP serial engine IRQs arm64: dts: qcom: glymur: fix PCIe SMMU interrupts |
||
|
Andy Lutomirski
|
478a1c3abe |
mm: fix incorrect flush address in direct page table reclaim
When zap_pte_range reclaims a page table, it does:
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
and this is unconditionally wrong: if this code executes, addr *always*
points one past the end of the range covered by the table. The addr
parameter is used to flush the TLB (really the paging-structure-cache)
to drop references to the to-be-freed table, and any architecture that
cares about the parameter will flush the wrong address. (But they'll
still free the correct page).
I think it's worth contemplating why the kernel works at all.
If we hit the offending line of code, we will first clear the PMD entry
(line 1954, zap_empty_pte_table), then we will issue pending flushes if
force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the
retry on line 1979 (phew!), and then we will do the offending
pte_free_tlb call. *Or* we will clear the PMD entry immediately before
pte_free_tlb (line 1983, zap_pte_table_if_empty).
If we have any pending flushes (i.e. we actually zapped any last-level
entries) at the time we clear the PMD entry, then the flush really ought
to flush all references to the table (Linus certainly seems to think it
will on all architectures [0]).
The condition under which we have no accumulated flushes at the time of
the clear is very complex (the whole zap_pte_range function has absurdly
complex control flow). If we do hit the bad case, then we will end up
clearing the PMD entry after the last time the range is flushed, and any
CPU is free to cache a reference to the (empty) page table. If this
happens due to an ordinary read or write, it would segfault, so it would
be rare. But the cache could be speculatively filled as well. Then
we'll flush the wrong address and then free and possibly reuse the
table.
On x86, even flushing the wrong address works on non-KPTI Intel systems
because INVLPG flushes *all* paging-structure-caches, not just the ones
for the target address. But INVPCID does not, and flush_tlb_one_user
will use INVPCID if it's available. And then we're toast. AMD systems
are more susceptible: we set the EFER.TCE bit, which makes even INVLPG
only flush the target address.
I think this might fix an issue in ripgrep reported here:
https://github.com/BurntSushi/ripgrep/issues/3494
[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Fixes:
|
||
|
Mark Brown
|
33c5aaf693
|
ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
reg_defaults must be sorted by ascending register address as
regcache_lookup_reg() locates the entries in it with bsearch(), see commit
|
||
|
Peter Ujfalusi
|
e4fe3e0465
|
ASoC: cs4265: sort the register default table
reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit |
||
|
Peter Ujfalusi
|
f39a68ed08
|
ASoC: cs35l45: sort the register default table
reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit |
||
|
Peter Ujfalusi
|
d74aac116c
|
ASoC: cs35l41: sort the register default table
reg_defaults must be sorted by ascending register address, as regcache_lookup_reg() locates entries in it with bsearch(). See commit |
||
|
Zhang Heng
|
1b0e5c7a4d
|
ASoC: amd: yc: Add DMI quirk for MSI Raider A18 HX A7VHG
Add a DMI quirk for the MSI Raider A18 HX A7VHG fixing the issue where the internal microphone was not detected. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221574 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260805091600.318018-2-zhangheng@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org> |
||
|
Zhang Heng
|
bc734d167a
|
ASoC: amd: yc: Add DMI quirk for Xiaomi RedmiBook 16 2025
Add a DMI quirk for the Xiaomi RedmiBook 16 2025 (AMD) fixing the issue where the internal microphone was not detected. Link: https://github.com/thesofproject/linux/issues/5860 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260805091600.318018-1-zhangheng@kylinos.cn Signed-off-by: Mark Brown <broonie@kernel.org> |
||
|
Rafael J. Wysocki
|
ff8da20b6f |
Revert "thermal/drivers/hwmon: Cleanup coding style a bit"
Revert commit
|
||
|
Daniel Borkmann
|
363b15d855
|
selftests/bpf: Add load-acquire test for dst_reg == src_reg from ctx
Add a verifier test that a load-acquire fetching into its own source register (dst_reg == src_reg) from a ctx pointer is rejected. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_load_acquire [...] #614/1 verifier_load_acquire/load-acquire, 8-bit:OK #614/2 verifier_load_acquire/load-acquire, 8-bit @unpriv:OK #614/3 verifier_load_acquire/load-acquire, 16-bit:OK #614/4 verifier_load_acquire/load-acquire, 16-bit @unpriv:OK #614/5 verifier_load_acquire/load-acquire, 32-bit:OK #614/6 verifier_load_acquire/load-acquire, 32-bit @unpriv:OK #614/7 verifier_load_acquire/load-acquire, 64-bit:OK #614/8 verifier_load_acquire/load-acquire, 64-bit @unpriv:OK #614/9 verifier_load_acquire/load-acquire with uninitialized src_reg:OK #614/10 verifier_load_acquire/load-acquire with uninitialized src_reg @unpriv:OK #614/11 verifier_load_acquire/load-acquire with non-pointer src_reg:OK #614/12 verifier_load_acquire/load-acquire with non-pointer src_reg @unpriv:OK #614/13 verifier_load_acquire/misaligned load-acquire:OK #614/14 verifier_load_acquire/misaligned load-acquire @unpriv:OK #614/15 verifier_load_acquire/load-acquire from ctx pointer:OK #614/16 verifier_load_acquire/load-acquire from ctx pointer @unpriv:OK #614/17 verifier_load_acquire/load-acquire from ctx pointer, same dst and src register:OK #614/18 verifier_load_acquire/load-acquire from ctx pointer, same dst and src register @unpriv:OK #614/19 verifier_load_acquire/load-acquire with invalid register R15:OK #614/20 verifier_load_acquire/load-acquire with invalid register R15 @unpriv:OK #614/21 verifier_load_acquire/load-acquire from pkt pointer:OK #614/22 verifier_load_acquire/load-acquire from flow_keys pointer:OK #614/23 verifier_load_acquire/load-acquire from sock pointer:OK #614 verifier_load_acquire:OK Summary: 1/23 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260804201917.253491-2-daniel@iogearbox.net Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> |
||
|
Daniel Borkmann
|
b87803391b
|
bpf: Check load-acquire src ptr type before the load
check_atomic_load() calls check_load_mem() before atomic_ptr_type_ok(). For a load-acquire that fetches into its own source register (dst_reg == src_reg), check_load_mem() overwrites src_reg's type with the type of the loaded value, so the subsequent atomic_ptr_type_ok() no longer sees the source pointer and fails to reject the disallowed types (ctx, pkt, flow_keys, sock). Since bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw access to the underlying kernel object is left in place. The destination type is taken from the ctx access itself, so a load-acquire of the sk field of struct __sk_buff for example leaves the register typed as PTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match either, while it actually holds unconverted struct sk_buff bytes. Once the NULL check has passed this is a type confusion, not just a leak of kernel data. Validate src_reg with check_reg_arg() and check the source pointer type with atomic_ptr_type_ok() before the load again, mirroring check_atomic_rmw(). Out-of-range register numbers are already rejected earlier by check_and_resolve_insns() (commit |
||
|
Baul Lee
|
2ca1eea3cd |
ALSA: usx2y: bound the hwdep mmap fault offset
snd_us428ctls_vm_fault() turns the faulting page offset into a kernel
address with no bound of any kind:
offset = vmf->pgoff << PAGE_SHIFT;
vaddr = (char *)(...)->us428ctls_sharedmem + offset;
page = virt_to_page(vaddr);
get_page(page);
vmf->page = page;
return 0;
snd_us428ctls_mmap() checks only the length of the mapping, never the
offset, and us428ctls_sharedmem is a single page from
alloc_pages_exact(). For a character device file_mmap_size_max()
returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page
offset above zero resolves to a struct page outside the object, and the
handler installs it into the caller's address space read-write; the vma
is not marked read-only.
The caller picks the page frame with a single mmap() argument and gets
read-write access to a page of kernel memory it does not own; an offset
that lands in an unpopulated vmemmap region oopses instead.
A process that can open the hwdep node of an attached US-X2Y reaches
this after loading the FPGA image through the same node; no capability
check is involved.
On 7.2.0-rc5 (arm64), mmap() with a large offset:
Unable to handle kernel paging request at virtual address fffffdffc45d5ac8
pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
Call trace:
snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
__do_fault
__handle_mm_fault
handle_mm_fault
el0_da
Reject any offset outside the shared region. The pcm hwdep handler in
usx2yhwdeppcm.c computes its address the same way and needs the same
bound.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes:
|
||
|
Baul Lee
|
69ee44e1a2 |
ALSA: usb-audio: fix OOB write on Type II inbound URBs
data_ep_set_params() sizes each URB transfer buffer before it adds the
Format Type II transfer delimiter:
u->packets = urb_packs;
u->buffer_size = maxsize * u->packets;
if (fmt->fmt_type == UAC_FORMAT_TYPE_II)
u->packets++; /* for transfer delimiter */
u->urb = usb_alloc_urb(u->packets, GFP_KERNEL);
buffer_size is computed from the pre-increment packet count and never
recomputed, so for a Type II endpoint the buffer is one packet short of
the packet count the URB is built with.
prepare_inbound_urb() then lays out one iso frame per packet and never
consults buffer_size:
offs = 0;
for (i = 0; i < urb_ctx->packets; i++) {
urb->iso_frame_desc[i].offset = offs;
urb->iso_frame_desc[i].length = ep->curpacksize;
offs += ep->curpacksize;
}
urb->transfer_buffer_length = offs;
urb->number_of_packets = urb_ctx->packets;
The last descriptor therefore points one packet past the end of the
transfer buffer, where the host controller writes device data on every
inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound
their fill loops by ctx->buffer_size, so only capture is affected.
fmt_type comes from the device's audio streaming descriptors, so any
device advertising a Type II capture format hits this once userspace sets
hw_params on the stream.
KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report
per inbound transfer:
BUG: KASAN: slab-out-of-bounds in dummy_timer
Write of size 64 at addr ffff0000186171c0 by task cons02/166
__asan_memcpy
dummy_timer
hrtimer_run_softirq
Allocated by task 166:
usb_alloc_coherent
snd_usb_endpoint_set_params
The buggy address is located 0 bytes to the right of
allocated 64-byte region [ffff000018617180, ffff0000186171c0)
Compute buffer_size after the delimiter packet has been accounted for,
and bound the fill loop by buffer_size, as prepare_silent_urb() already
does on the outbound side. This grows every Type II URB allocation by
one maxsize packet.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes:
|
||
|
Qing Luo
|
aa2e13ae8d |
sctp: fix addip_serial increment on ASCONF_ACK allocation failure
In sctp_process_asconf(), when sctp_make_asconf_ack() fails to allocate
the ASCONF_ACK chunk due to memory pressure, the code jumps to the
done label where asoc->peer.addip_serial is unconditionally incremented.
This leaves the peer's ASCONF (serial N) unacknowledged while the local
endpoint now expects serial N+1. When the peer retransmits serial N, it
falls into the serial < addip_serial + 1 branch ,
which attempts to look up a cached ACK for serial N. No cached ACK
exists since the allocation failed, so the retransmission is silently
discarded. The peer eventually times out and ABORTs the association.
Move the addip_serial increment inside the if (asconf_ack) block so that
the serial number is only advanced when the ASCONF_ACK is successfully
created and cached. This way, on allocation failure, the serial number
is unchanged and the peer's retransmitted ASCONF will be correctly
re-processed.
Fixes:
|
||
|
SJ Park
|
1ec0e6b6f7 |
mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD}
Callers of migrate_pages() should adjust NR_MIGRATED_{ANON,FILE} for
isolations and putback of the folios. That for migration succeeded folios
is done by migrate_pages(), in migrate_folio_done(). That for MR_DEMOTION
reason is an exception though.
DAMOS_MIGRATE_{HOT,COLD} call migrate_pages() but mistakenly not doing the
stat adjustment. As a result, use of DAMOS_MIGRATE_{HOT,COLD} could
corrupt the stat. It could confuse too_many_isolated(), make compaction
and reclaim to behave in unexpected ways. The stat corruption can be
reproduced and confirmed using DAMON user-space tool [1] on NUMA systems,
like below.
$ numactl --hardware
available: 2 nodes (0-1)
[...]
$ sudo ./damo start --damos_action migrate_hot 1
$ sudo cat /proc/sys/vm/stat_refresh
$ sudo dmesg
[...]
[ 80.215554] vmstat_refresh: nr_isolated_anon -5578
[ 80.216842] vmstat_refresh: nr_isolated_file -34400
This issue was discovered [2] by Sashiko.
Link: https://lore.kernel.org/20260728140404.94476-1-sj@kernel.org
Link: https://github.com/damonitor/damo [1]
Link: https://lore.kernel.org/20260726164356.87940-1-sj@kernel.org [2]
Fixes:
|
||
|
liyouhong
|
5deb65c34e |
mm/damon/ops-common: putback folios on invalid migrate nid
damon_pa_migrate() and damos_va_migrate() isolate folios into a local list
and then call damon_migrate_pages(). When target_nid is invalid
(including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages()
returns early without putting the folios back to the LRU.
Callers then discard the list head while those folios remain isolated with
an extra reference taken by folio_isolate_lru(). The pages stay off the
LRU for as long as the mapping exists (anon active+inactive counts drop
while RSS does not), and the leftover references can pin the pages after
the mapping is gone.
Put the folios back on the invalid-nid path so ignored migration requests
still return them to the LRU.
Link: https://lore.kernel.org/20260726014815.1280757-1-dayou5941@163.com
Fixes:
|
||
|
Matt Fleming
|
aca1f2d5de |
mm/huge_memory: initialise workingset state before folio split
xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but
__folio_split() leaves the xa_state's xa_lru unset. That lets a live,
memcg-charged xa_node exist without being linked into the mapping's
shadow_nodes list_lru; when reclaim later walks the list_lru it trips
VM_WARN_ON(!css_is_dying()).
Use mapping_set_update() to install both the workingset update callback
and the shadow_nodes list_lru on the xa_state.
Link: https://lore.kernel.org/20260725101419.3938406-1-matt@readmodwrite.com
Fixes:
|
||
|
Zhiling Zou
|
8db4bab826 |
mm/page_table_check: skip special zero mappings
page_table_check_set() and page_table_check_clear() account mappings based
on PageAnon(). Shared zero-page PTEs and huge zero PMDs are special
mappings, but page_table_check can still account them as file-backed
pages.
An unprivileged process can populate enough zero mappings to overflow
file_map_count and hit the existing BUG_ON(). The PTE path can do this
with the shared zero page, and the PMD path can do the same with huge zero
mappings.
Skip special zero mappings in the user page-table accounting paths. Keep
the PTE-side pte_special() check, and identify huge zero PMDs from the
mapped folio instead of pmd_special(). That covers architectures where
pmd_special() is a no-op without adding huge_zero_pfn checks to the
generic counter helpers.
Link: https://lore.kernel.org/cover.1784717203.git.zhilinz@nebusec.ai
Link: https://lore.kernel.org/e94478e4fb7912fb7e8ebebed5ce85d00dc9a69d.1784717203.git.zhilinz@nebusec.ai
Fixes:
|
||
|
SJ Park
|
0f18683103 |
mm/damon/lru_sort: skip damon_call() if ctx has not started
DAMON_LRU_SORT calls damon_call() for commit_inputs parameter user input
if the DAMON context is initialized. The context could be initialized,
but not yet successfully started. In the case, damon_call() could
indefinitely hang. Read the comment on damon_call() for more detail. Fix
the problem by memorizing if the DAMON context has ever successfully
started, and skip damon_call() if it has not.
This issue can easily be reproduced by writing Y to the commit_inputs
parameter file on a system that DAMON_LRU_SORT has not turned on before.
Link: https://lore.kernel.org/20260803134646.16640-3-sj@kernel.org
Fixes:
|
||
|
SJ Park
|
b9b6bad94c |
mm/damon/reclaim: skip damon_call() if ctx has not started
Patch series "mm/damon/{reclaim,lru_sort}: fix commit_inputs infinite
hang".
Writing 'Y' to commit_inputs parameters of DAMON_RECLAIM and
DAMON_LRU_SORT before the modules were ever turned on causes infinite
hang. Fix those.
The issue was discovered [1] by Sashiko.
This patch (of 2):
DAMON_RECLAIM calls damon_call() for commit_inputs parameter user input if
the DAMON context is initialized. The context could be initialized, but
not yet successfully started. In the case, damon_call() could
indefinitely hang. Read the comment on damon_call() for more detail. Fix
the problem by memorizing if the DAMON context has ever successfully
started, and skip damon_call() if it has not.
This issue can easily be reproduced by writing Y to commit_inputs on a
system that DAMON_RECLAIM was not turned on before.
Link: https://lore.kernel.org/20260803134646.16640-1-sj@kernel.org
Link: https://lore.kernel.org/20260803134646.16640-2-sj@kernel.org
Link: https://lore.kernel.org/20260802173021.762-1-sj@kernel.org [1]
Fixes:
|
||
|
SJ Park
|
06befa61c4 |
mm/damon/lru_sort: error out for >10000 active_mem_bp
damos_quota_score() can trigger division by zero if the target value is
zero. DAMON_LRU_SORT lets users set the target value for the hot memory
scheme via active_mem_bp parameter. It avoids setting it as the target
value if the parameter value is zero. However, it also sets the cold
memory scheme with a target value that is calculated as '10000 -
active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold
memory scheme's quota goal target value can be zero. As a result,
division by zero can be triggered. Fix by returning an error when the
user tries to start DAMON with >10000 active_mem_bp parameter value.
It makes no sense to set active_mem_bp with 10002. It also requires
module parameters write permission to reproduce the issue. That said, the
consequence is quite bad.
One reliable way to reproduce the issue is like below:
# cd /sys/module/damon_lru_sort/parameters
# echo 1000 > wmarks_high
# echo 995 > wmarks_mid
# echo 0 > wmarks_low
# echo 10002 > active_mem_bp
# echo Y > enabled
# dmesg -w
[...]
[ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI
[ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480
This issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/20260803134034.15217-3-sj@kernel.org
Link: https://lore.kernel.org/20260801213028.5127-1-sj@kernel.org [1]
Fixes:
|
||
|
SJ Park
|
a16fd3ad9d |
samples/damon/mtier: error out for zero quota goal target values
Patch series "mm/damon: avoid division by zero from damos_quota_score()".
DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division
by zero in damos_quota_score(). Avoid it by adding parameters validation
checks.
This patch (of 2):
damos_quota_score() can trigger division by zero if the target_value is
zero. DAMON_SAMPLE_MTIER lets users set the target_value via
node0_mem_{used,free}_bp parameters. It doesn't guard zero value case,
though. As a result, users can trigger division by zero. Fix the issue
by returning an error when the user tries to start DAMON with zero
node0_mem_{used,free}_bp parameter values.
DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite
bad. Also the zero node0_mem_free_bp parameter might look like a
reasonable setup to some users. Hence, the issue might really happen in
the real world.
One reliable way to reproduce the issue is like below:
# cd /sys/module/damon_sample_mtier/parameters
# echo 4096 > node0_start_addr
# echo 8192 > node0_end_addr
# echo 8192 > node1_start_addr
# echo 81920 > node1_end_addr
# echo 0 > node0_mem_free_bp
# echo Y > enabled
# dmesg -w
[...]
[18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI
[...]
[18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480
[...]
This issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/20260803134034.15217-1-sj@kernel.org
Link: https://lore.kernel.org/20260803134034.15217-2-sj@kernel.org
Link: https://lore.kernel.org/20260801202657.117135-1-sj@kernel.org [1]
Fixes:
|
||
|
Danila Tikhonov
|
4194140a51 |
mailmap: map old addresses to Danila Tikhonov
Map my old jiaxyga.com and ProtonMail addresses to the current mainlining.org address. Link: https://lore.kernel.org/20260801153333.296218-1-danila@mainlining.org Signed-off-by: Danila Tikhonov <danila@mainlining.org> Cc: Jakub Kacinski <kuba@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Lorenzo Stoakes (ARM)
|
98bd3af0bb |
mm/huge_memory: separate out CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic
Rather than mixing the refcounted and non-refcounted
CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic, separate the two out cleanly so
it is clear what happens when this configuration option is set and what
happens when it is not.
Introduce HUGE_ZERO_UNSET_PFN to abstract the ~0UL assignment, only
introduce the refcount, lock and shrinker if
!CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, abstract initialisation and teardown,
abstract the huge zero folio allocation from refcounting.
Also change a BUG_ON() to WARN_ON_ONCE() while we're at it.
No functional change intended.
Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-2-c5d8a41b317f@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Fixes:
|
||
|
Lorenzo Stoakes (ARM)
|
33192a26cd |
mm/huge_memory: fix huge_zero_pfn race
Patch series "mm/huge_memory: fix huge_zero_pfn race", v2.
There is a subtle race in the reference-counted huge_zero_folio
implementation.
The fast path atomic logic fails to account for the fact that the shrinker
(which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn
with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a
racing get_huge_zero_folio() installed a valid value there.
This results in huge_zero_folio being correctly set but huge_zero_pfn
being set incorrectly and thus is_huge_zero_pfn() and consequently
is_huge_zero_pmd() will misidentify the huge zero folio as being an
ordinary THP folio.
This can result in the huge zero folio being split and otherwise treated
incorrectly.
The solution to this is very subtle as there is an atomic fast path, and
thus ordering in weakly ordered architectures has to be treated very
carefully.
The first commit fixes the issue by introducing a spinlock around
huge_zero_[pfn, folio, refcount] write, with careful consideration paid to
load/store ordering in the fast path. It is placed first and kept as
small as possible so that it can be backported on its own.
The second commit is a pure cleanup which reworks the
CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent
logic from the dynamically allocated one.
This patch (of 2):
If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted
by huge_zero_refcount and returned by mm_get_huge_zero_folio().
When the caller is done with the huge zero page, its reference count is
decremented. Only a shrinker can set the reference count to zero.
A race can unfortunately occur between a shrinker decrementing the
reference count to zero and a concurrent page fault.
This is because shrink_huge_zero_folio_scan() might, if very unlucky, be
preempted between setting huge_zero_refcount to zero and writing an
invalid value.
During this time get_huge_zero_folio() could write to huge_zero_pfn before
shrink_huge_zero_folio_scan() resumes.
In this event the huge zero folio will be persistently misidentified
causing the THP code path to be entered inappropriately for the huge zero
folio:
CPU 0 CPU 1
=======================================|=================================
shrink_huge_zero_folio_scan() |
atomic_cmpxchg() sets refcount to 0 |
xchg() sets huge_zero_folio to NULL | get_huge_zero_folio()
| | atomic_inc_not_zero() -> zero
preempted for a long time | Allocate new huge zero folio
| | Write valid huge_zero_folio
v | Write valid huge_zero_pfn
Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite!
This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly
returning false for a huge zero page which could result in issues like the
huge zero folio being incorrectly split.
Note that the issue is with huge_zero_pfn not huge_zero_folio, as
get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL
with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set
huge_zero_folio.
Fix the issue by introducing a spinlock, huge_zero_lock, to prevent
concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount.
There needs to be significant care taken here to ensure correctness:
The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which
is outside of the critical section, and means huge zero allocation is
gated on zero huge_zero_refcount.
The fast path doesn't use huge_zero_lock, so the critical section is
irrelevant to it.
So invariants are required - huge_zero_refcount MUST:
* Only be set in the huge_zero_lock critical section to ensure
serialisation of huge_zero_pfn, huge_zero_folio and huge_zero_refcount
writes.
* Be set non-zero only AFTER huge_zero_[pfn, folio] are set to valid values
so installation of the huge zero folio on read page fault ensures
concurrent is_huge_zero_*() calls correctly identify the huge zero folio.
* Be set zero only BEFORE huge_zero_[pfn, folio] are set to NULL and ~0UL
respectively, and atomically.
Establish these by:
* Only setting huge_zero_refcount to zero or an absolute value in the
huge_zero_lock critical section in get_huge_zero_folio() and
shrink_huge_zero_folio_scan(), and always updating atomically there
and elsewhere.
* Using atomic_set_release(&huge_zero_refcount) in get_huge_zero_folio()
after huge_zero_[pfn, folio] are set. This is paired with
atomic_inc_not_zero() to ensure atomic_inc_not_zero() only observes a
non-zero value if huge_zero_[pfn, folio] are set.
* Using atomic_cmpxchg() in shrink_huge_zero_folio_scan() (as before) to
ensure that it is set zero only when equal to 1 and set atomically.
* atomic_cmpxchg() being fully ordered ensures this is done prior to
huge_zero_[folio, pfn] being set to NULL and ~0UL respectively.
Eliminate the retry loop in get_huge_zero_folio() as the atomic_cmpxchg()
in shrink_huge_zero_folio_scan() is now performed under the lock, and
replace with an equally locked atomic_inc() to set the reference count
should the caller be raced on huge zero folio installation.
folio_put() naturally implies a full memory barrier so its ordering is
maintained correctly.
The huge zero folio also cannot be released except when the shrinker does
so as it is non-LRU and non-rmappable.
Note that only the huge zero shrinker (via shrink_huge_zero_folio_scan())
can actually set huge_zero_refcount to zero, which is the count of mm's
which have at least one huge zero folio installed plus one shrinker pin.
Additionally convert a BUG_ON() to a VM_WARN_ON_ONCE().
Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-0-c5d8a41b317f@kernel.org
Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-1-c5d8a41b317f@kernel.org
Fixes:
|
||
|
Brendan Jackman
|
50124648db |
MAINTAINERS: update address for Brendan Jackman
Switch my entry in MAINTAINERS and .mailmap to my @linux.dev email address Link: https://lore.kernel.org/20260729-email-change-v1-1-666ae7c2b7fc@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Brendan Jackman <brendan.jackman@linux.dev> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Hugh Dickins
|
86da3f7e1e |
mm/filemap: __filemap_add_folio() restore index before retrying
In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is
applied repeatedly: each application modifies xas.xa_index, rounding it
down according to the split_order attempted at that stage: and if all goes
as intended, it eventually (or immediately) converges on an
xas_try_split() to the required folio_order, with xas.xa_index now the
same as index: then xas_store() puts the new folio into the xarray there.
But if a new node was needed, and GFP_NOWAIT allocation did not get one,
the lock is dropped, xas_nomem() used to allocate, and sequence retried.
If (that part of) the xarray is unchanged when the lock is reacquired, no
problem. But what if the conflict was meanwhile resolved by another
thread (perhaps even doing the same thing, inserting a folio at that same
index)? Isn't there a danger of now putting our folio into the xarray at
an intermediate rounded-down index? With !folio_contains() bug to follow,
when CONFIG_DEBUG_VM=y is checking for that.
Fix this with an xas_set_order() to restore the original xas.xa_index at
the bottom of the loop, so the retry does a full re-evaluation after
reacquiring the lock, and cannot reach xas_store() with the wrong index.
Production was suffering from rare SIGILLs and SIGSEGVs, executable text
found a page away from where it belonged, !folio_contains() bug hit when
debug enabled: symptoms not seen since this patch went in.
Link: https://lore.kernel.org/562fbfa6-dd6d-0b6a-2461-ed2ff1173bc8@google.com
Fixes:
|
||
|
Ramin Moussavi
|
c2689266e5 |
microblaze: restore the page alignment of swapper_pg_dir
microblaze handles TLB misses in software, and the handler builds the address of the L1 entry by ORing the index into the page directory base instead of adding it (hw_exception_handler.S): bsrli r5, r3, PGDIR_SHIFT - 2 andi r5, r5, PAGE_SIZE - 4 /* Assume pgdir aligned on 4K boundary, no need for "andi r4,r4,0xfffff003" */ or r4, r4, r5 lwi r4, r4, 0 /* Get L1 entry */ The index is masked to the low 12 bits, so the OR only works if those bits of the base are zero -- which is exactly the assumption the comment states and the reason the masking of the base can be skipped. swapper_pg_dir had no alignment directive of its own. It was aligned because it followed empty_zero_page in head.S, and that one carried the .align 12: .section .data .global empty_zero_page .align 12 empty_zero_page: .space PAGE_SIZE .global swapper_pg_dir swapper_pg_dir: .space PAGE_SIZE Commit |
||
|
Lorenzo Stoakes (ARM)
|
9d3277b2c0 |
arm64: remove redundant concurrent ptdump UAF mitigation
This partially reverts commit |
||
|
Lorenzo Stoakes (ARM)
|
27c32e5538 |
mm/ptdump: always stabilise against page table freeing using init_mm
Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit |
||
|
Lorenzo Stoakes (ARM)
|
26444eb714 |
mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF
Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit |
||
|
Jakub Kicinski
|
6183a645aa |
Merge branch 'bnxt_en-bug-fixes'
Michael Chan says: ==================== bnxt_en: Bug fixes This series include 3 bug fixes: 1. queue start bug fix on the VNIC's default ring. 2 refactoring patches preceed the actual bug fix. 2. Bug fix for TPA data corruption seen on some ARM systems. 3. PTP PPS setting bug fix. ==================== Link: https://patch.msgid.link/20260731190937.807270-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Keegan Freyhof
|
80eaf88efe |
bnxt_en: Fix PTP PPS setting bug
The existing driver logic is always turning on PTP_CLK_REQ_PPS
regardless of the "on" parameter passed to bnxt_ptp_enable().
During shutdown, PTP_CLK_REQ_PPS may be turned off and this
bug will do the opposite and may trigger a PCIe PTM request TLP.
On some systems this can trigger a PCIe AER.
Fix it by properly configuring PTP_CLK_REQ_PPS based on the "on"
parameter.
Fixes:
|
||
|
Michael Chan
|
c3faf548a0 |
bnxt_en: Disable EOP for TPA on all chips to prevent data corruption
EOP (End of frame padding) on the AGG ring may cause overlapping of
zero padding at the end of one segment with the next segment's data.
If Relaxed Ordering (RO) is enabled, the zero padding may overwrite
valid data in the next segment and corrupt the data. Older chips
(P5 and older) do not automatically disable RO when EOP is enabled.
On some ARM systems, data corruption was reported on 57508 (P5)
chips with RO enabled.
Always disable EOP on all chips on the AGG rings when TPA is enabled
to fix the data corruption.
Fixes:
|
||
|
Shravya KN
|
0b137529a8 |
bnxt_en: Refresh VNIC default ring on queue restart if needed
When a queue is restarted, refresh VNIC_CFG for all VNICs whose
default RX ring is the restarted ring. This will eliminate this
possible FW warning caused by a stale default ring in the VNIC:
FW reported unknown error type 10
Fixes:
|
||
|
Shravya KN
|
53f01cd594 |
bnxt_en: Determine and store default RX ring in vnic structure
Each VNIC has a default RX ring. The purpose of the default RX ring is to provide a destination for any packets that cannot be parsed by the RSS logic. Up until now, the default RX ring is always Ring 0. We neglected to take care of this default RX ring when adding the queue restart feature. If ring 0 (default ring) is re-started, it may now have a new FW ring ID after freeing the old one and allocating a new one. The VNIC now may have a stale default ring and it may generate an internal exception. This exception may appear in dmesg: FW reported unknown error type 10 The best way to resolve this issue is to use a more appropriate ring for the default ring instead of always ring 0. Ring 0 may not even be in the RSS table, especially on a new RSS context. This patch adds the logic to determine and store the proper default RX ring for a VNIC. For an RSS VNIC, the default ring is the lowest ring number in the RSS table. The next patch will add proper logic to update the VNIC if the default ring changes after queue restart. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260731190937.807270-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Shravya KN
|
1d0fc6c7ea |
bnxt_en: Move RSS table fill outside __bnxt_hwrm_vnic_set_rss()
This is a refactor patch with no change in behavior. The caller will now fill the RSS table before calling __bnxt_hwrm_vnic_set_rss(). In the next patch, we'll add code to determine the default ring for the VNIC when we fill the RSS table. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260731190937.807270-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Bobby Eshleman
|
e7386770be |
net/mlx5e: fix BQL reset on SQ re-activation
mlx5e_queue_start() deactivates and re-activates all channels but closes
only the queue being restarted. mlx5e_activate_txqsq() then
unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters
of channels that kept their in-flight TX WQEs. The next completion then
over-charges and trips the BUG_ON() in dql_completed():
kernel BUG at lib/dynamic_queue_limits.c:99!
RIP: 0010:dql_completed+0x23d/0x280
Call Trace:
<IRQ>
mlx5e_poll_tx_cq+0x668/0xa60
mlx5e_napi_poll+0x5b/0x7b0
net_rx_action+0x15a/0x580
Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc).
In the case that reset is skipped, the outstanding WQEs will eventually
complete and rebalance the dql. The dql->limit is carried across the
reset.
Fixes:
|
||
|
Zhiling Zou
|
5d1c224dd9 |
net: openvswitch: reallocate update replies for mismatched IDs
ovs_flow_cmd_new() preallocates the optional reply skb before it takes
ovs_mutex and before it knows which existing flow will be updated.
That is normally fine because the skb is sized from the request flow
identifier. That identifier also becomes the inserted flow's identifier.
For updates, however, a request with a UFID may miss the UFID lookup and
then fall back to the flow key lookup. That lookup can legitimately find
an existing key-identified flow. UFIDs are optional and the flow key is
the primary identifier.
For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's
identifier, not the request identifier used for the preallocation. A short
request UFID can therefore leave too little room for the key identifier.
The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the
update path.
Once the update target has been resolved, reallocate the reply skb if the
matched flow needs a larger reply than the request identifier allowed. Do
this before replacing the actions so the request can still fail cleanly if
the rare extra allocation fails.
Fixes:
|
||
|
Laurent Vivier
|
1505b2cb6a |
usbnet: cap max_mtu for drivers without bind callback
usbnet_probe() initializes max_mtu to ETH_MAX_MTU and only caps it
inside the if (info->bind) block. Drivers without a bind callback
never enter this block, so max_mtu stays at ETH_MAX_MTU.
QEMU's usb-net device (0x0525/0xa4a2) is claimed by the cdc_subset
driver which has no bind callback. The guest accepts any MTU from DHCP
(e.g. 65520 from passt), leading to TCP segments that exceed the
device's 2048-byte receive buffer and are silently dropped.
Initialize max_mtu to net->mtu at probe time and update it inside
the bind block.
Fixes:
|
||
|
Alok Tiwari
|
2cbd8a4e5e |
bnge: use int for bnge_fix_rings_count() return value
bnge_fix_rings_count() returns 0 on success or a negative errno on failure
However, bnge_adjust_rings() stores its return value in a u16 variable,
causing negative error codes such as -ENOMEM to be converted to a large
positive value.
Use an int for the return code variable so that error values are
preserved and propagated correctly.
Fixes:
|
||
|
Jakub Kicinski
|
6310aaadbf |
Merge branch 'net-atlantic-fix-two-ring-teardown-leaks'
Yangyu Chen says: ==================== net: atlantic: fix two ring teardown leaks These are the two fixes from the page_pool conversion series [1], resent against net as requested in the review of that series. The page_pool conversion itself stays in net-next and is not part of this posting; it depends on these fixes, but they stand on their own. Both patches are unchanged from [1] apart from the collected Reviewed-by tags, and each carries a Fixes tag and a Cc: stable with the affected range (patch 1: v4.11+, patch 2: v5.2+). They apply and were build- and runtime-tested independently of each other and of the conversion. Patch 1: aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which is capped at AQ_CFG_TX_CLEAN_BUDGET descriptors and stops at hw_head, frozen once the hardware and NAPI have been stopped. Everything beyond that keeps its skb or xdp_frame when the interface goes down and is lost when the buffer ring is freed. Patch 2: aq_ring_rx_deinit() only walks [sw_head, sw_tail). Since the page reuse strategy was added, a cleaned RX buffer keeps its page for reuse and refill is batched, so consumed but not yet reposted slots accumulate in the [sw_tail, sw_head) gap and their pages and DMA mappings are never released. Reproduction logs for both leaks (as page_pool stalled shutdowns, which is how they become visible) are in the notes of the respective patches. [1] https://lore.kernel.org/lkml/tencent_1F173E0FC1606D2AC704DC9C98AF10984607@qq.com/ ==================== Link: https://patch.msgid.link/tencent_29B860317921D68DE77C718242DA418EB608@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Yangyu Chen
|
e8e7471ef6 |
net: atlantic: free RX pages of consumed but not refilled buffers
aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to
hardware. Since the page reuse strategy was added, a cleaned RX buffer
keeps its page (and its DMA mapping) in the ring for reuse, and refill
is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES
slots are free. Slots that were consumed but not yet reposted therefore
sit in the complementary [sw_tail, sw_head) gap with a live page, and
the deinit walk never visits them: up to a refill batch worth of pages
and DMA mappings leak on every interface down.
Walk the whole ring instead and release whatever is still there. Also
bail out if the buffer ring is already gone: a partial
aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so
aq_ptp_ring_deinit() still gets here on the unwind path.
Cc: stable@vger.kernel.org # v5.2+
Fixes:
|
||
|
Yangyu Chen
|
452636ea54 |
net: atlantic: free stranded TX buffers on ring deinit
aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean()
call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and
stops at hw_head, which no longer moves once aq_vec_stop() has stopped
the hardware and NAPI. Completed descriptors beyond the budget and
everything still posted in [hw_head, sw_tail) keep their skb or
xdp_frame when the interface goes down: aq_vec_ring_free() then frees
the buffer ring and the references are lost for good.
Today this is a silent memory leak on every interface down under
TX/XDP_TX load. With the conversion of the RX path to page_pool posted
for net-next it becomes much more visible: XDP_TX frames carry fragment
references on the RX ring's page_pool, so a single stranded frame keeps
the pool's inflight count above zero forever. page_pool_destroy() then
never completes, the pool is leaked together with its pages, and
"page_pool_release_retry() stalled pool shutdown" is warned every 60
seconds from that point on, on every ifdown, XDP detach or ring resize
under XDP_TX load.
Bring back aq_ring_tx_deinit() as it was before the removal and use it
for teardown again, with one extension: TX rings can hold xdp_frames
nowadays, so release those too. They are returned with
xdp_return_frame() since this runs in process context.
Fixes:
|
||
|
Stefan Agner
|
06232cb44b |
net: stmmac: resume PHY before hardware setup when opening the interface
Since the referenced commit, changing the MTU on a running interface no
longer disconnects and reconnects the PHY; __stmmac_release() merely
stops phylink, which also suspends the PHY (BMCR power-down) when WoL
is not enabled. __stmmac_open() then performs the DMA software reset in
stmmac_hw_setup() before phylink_start() resumes the PHY again.
IEEE 802.3 22.2.4.1.5 allows a PHY to stop its receive clock while
powered down, and stmmac requires a running receive clock for the DMA
software reset to complete (the phylink config sets mac_requires_rxc).
On such setups, e.g. the RK3566-based Home Assistant Green with an
RTL8211F-VD PHY in RGMII mode, any runtime MTU change now times out and
leaves the interface dead:
rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma
rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed
rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed
rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change
In the field this is triggered by NetworkManager applying an MTU while
activating the connection, breaking networking entirely. The same
regression has also been reported on i.MX8MP and reproduced on SoCFPGA
based systems.
Resume the PHY in __stmmac_open() before the hardware setup, making it
the counterpart of the phylink_stop() in __stmmac_release(), like
stmmac_resume() already does for the same reason. phylink_start() also
resumes the PHY, but only after stmmac_hw_setup(), and it cannot be
moved before the hardware setup since it may bring the link up
immediately from a workqueue, racing with the initialization (see the
comment in stmmac_resume()). For the regular ndo_open path the PHY has
just been attached and is not suspended, in which case
phylink_prepare_resume() does nothing.
Fixes:
|
||
|
Jakub Kicinski
|
e31420642d |
Included fixes:
* use rcu_dereference_bh() instead of rcu_access_pointer() where the pointer is actually dereferenced * ensure TCP global variables are initialized before they can be accessed via netlink (e.g. when attaching a TCP socket) * actually disable IPv4 redirects on multipeer interfaces (the previous attempt was a no-op and did not survive netns moves) * hash a floated peer by its transport identity only, consistently with the add and lookup paths * zero the sockaddr padding before learning a floated endpoint so it does not leak into the by_transp_addr hash key * ensure the socket is owned by ovpn before dereferencing sk_user_data * rehash a peer in the by_transp_addr table when its remote endpoint is updated via CMD_PEER_SET * avoid re-adding to the hashtables a peer that was concurrently removed (use-after-free) * limit keepalive values to one day to avoid overflowing the delayed-work delay on 32-bit systems * add the missing rtnl_link_ops->get_size callback so link messages account for the nested mode attribute -----BEGIN PGP SIGNATURE----- iJEEABYIADkWIQQr0db7q+Rc7Zog28Fc8QQzwdnOtwUCamsZiRsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQXPEEM8HZzrdjhQD/SJjvWsxHurn7vQJ8VFw9 wb8Q06TpSjdHkd5xXpQzohoA/joMlAYnVhSlYDcDaF3DCzmCAW6fG/bpPoI4bpFj i8UD =Oppi -----END PGP SIGNATURE----- Merge tag 'ovpn-net-20260730' of https://github.com/OpenVPN/ovpn-net-next Antonio Quartulli says: ==================== Included fixes: * use rcu_dereference_bh() instead of rcu_access_pointer() where the pointer is actually dereferenced * ensure TCP global variables are initialized before they can be accessed via netlink (e.g. when attaching a TCP socket) * actually disable IPv4 redirects on multipeer interfaces (the previous attempt was a no-op and did not survive netns moves) * hash a floated peer by its transport identity only, consistently with the add and lookup paths * zero the sockaddr padding before learning a floated endpoint so it does not leak into the by_transp_addr hash key * ensure the socket is owned by ovpn before dereferencing sk_user_data * rehash a peer in the by_transp_addr table when its remote endpoint is updated via CMD_PEER_SET * avoid re-adding to the hashtables a peer that was concurrently removed (use-after-free) * limit keepalive values to one day to avoid overflowing the delayed-work delay on 32-bit systems * add the missing rtnl_link_ops->get_size callback so link messages account for the nested mode attribute * tag 'ovpn-net-20260730' of https://github.com/OpenVPN/ovpn-net-next: ovpn: fix incorrect use of rcu_access_pointer() ovpn: ensure TCP vars are initialized first ovpn: disable IPv4 redirects on MP interfaces ovpn: hash floated peer by transport identity only ovpn: zero-initialize sockaddr before learning a floated endpoint ovpn: ensure socket is owned by ovpn before deref sk_user_data ovpn: rehash peer in by_transp_addr table on CMD_PEER_SET ovpn: skip rehash for peers already removed from by_id ovpn: limit keepalive values to one day ovpn: add missing rtnl_link_ops->get_size callback ==================== Link: https://patch.msgid.link/20260730094624.4102963-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Martin Kaiser
|
6e3abef2a2 |
selftests/ftrace: refactor eprobes test to fix argument checks
The add/remove eprobe test installs an eprobe for the openat syscall and runs ls. It checks the filenames that were opened by ls against a whitelist and a blacklist. Commit |
||
|
Pu Lehui
|
6655c40970 |
bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed
A potential invalid storage access issue can occur after replacing a
cgroup bpf prog.
This occurs in the following scenario:
1. prog1 with storage is attached to a cgroup in multi-attach mode.
2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach
mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or
update_effective_progs).
3. A new prog3 is attached to the cgroup in multi-attach mode.
The reason is that __cgroup_bpf_attach overwrites pl->storage with the
new storage prior to attachment completion. When attachment fails
midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to
free the newly allocated storage, but fails to restore pl->storage back
to old_storage.
Consequently, the still-active prog1 holds invalid or dangling storage
pointers, leading to an invalid memory access when prog1 executes and
calls bpf_get_local_storage. Additionally, original pl->flags and
cgrp->bpf.flags[atype] are left unrestored.
Fix this by saving old_pl_flags, old_storage, and old_flags prior to the
update, and properly restoring all of them in the cleanup path on error.
Fixes:
|