Even among the ksz8 family, there are big differences in the MTU change
procedure between KSZ87xx and KSZ88xx (KSZ8463 is like KSZ88xx here).
Since we have 3 separate dsa_switch_ops for what constitutes "KSZ8", we
can split those procedures into separate functions.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-1-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Mike Rapoport says:
====================
drivers/net/ethernet: replace __get_free_pages() with kmalloc()
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
Also in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/drivers-net-ethernet
[1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/
[2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/
====================
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-0-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
efx_mcdi_init() allocates a logging buffer for MCDI firmware
communication diagnostics.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-4-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
efx_siena_mcdi_init() allocates a logging buffer for MCDI firmware
communication diagnostics.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-3-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ice_gnss_read() uses get_zeroed_page() to allocate a staging buffer for
reading GNSS module data via I2C bus.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of get_zeroed_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-2-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
bnx2x_mcast_enqueue_cmd() allocates memory for mac filtering list using
__get_free_pages().
This memory can be allocated with kzalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-1-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rtla started to only link parts of the tools library. It now misses the
ctype information used by all the related string operations. Just add
another single file to make it build again.
Signed-off-by: Bastian Blank <waldi@debian.org>
Fixes: 48209d763c ("rtla: Add libsubcmd dependency")
Link: https://lore.kernel.org/r/ako2S4mzIqWwYuas@steamhammer.waldi.eu.org
[ remove duplicated spaces in commit message ]
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
Background:
==========
Currently lockdep does not print out the held locks of non-current
tasks that are running on some other CPU, due to the fact that
the held locks array is in flux and may be unreliable to print.
Syzkaller on the other hand found it that the analysis of locking
bugs is easier if we print this information too, because the
more locking information the merrier. In particular races are
bound to have multiple tasks running on different CPUs, and
the exclusion of their held locks information is unnecessarily
limiting.
So while it's still true that printing out their held locks
array is racy, it's not as bad as it seems.
There's 16 internal callers to lockdep_print_held_locks():
- 14 callers call it with the current task, which should be
safe out of box.
- 1 caller, debug_show_all_locks(), calls it with RCU held,
which should guarantee that 'p' cannot go away under us.
- 1 caller, debug_show_held_locks(), exposes the internal API
with the constraint that it should only be called by drivers
or platform code if the task isn't actively running - we can
assume that if it nevertheless does, it will be Their Problem™.
As for held locks being changed from under debug_show_held_locks(),
while the task cannot go away, so the held-locks array itself is
safe (although potentially non-stable), AFAICS the worst-case race
can be garbage printed out by print_lock(), not any actual crashes.
In particular:
unsigned int class_idx = hlock->class_idx;
may be stale (belong to a lock that already got released on another
CPU), but it should still be a valid class index bound by
MAX_LOCKDEP_KEYS, and thus the lock_classes_in_use bitmap use
should be safe.
The other two accesses are ::acquire_ip and ::instance:
printk(KERN_CONT "%px", hlock->instance);
print_lock_name(hlock, lock);
printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip);
But both are printed out as pointers, so no risk of dereference
of a dangling pointer. We may print a garbage pointer.
Also note that the check itself doesn't protect debug_show_held_locks()
from printing garbage, as there's nothing that keeps a task from
becoming runnable a nanosecond after we've run the task_is_running()
check. In fact I'd argue that it's better to make this function
*more* racy, for the simple robustness reason that we absolutely
do not want it to crash even in the racy case.
TL;DR: it should be fine to print the held locks of running
tasks too, as long as we print out the information as well
that a task is running, so that users are aware of any
racy output.
Implementation:
==============
Implement that change.
Also re-flow the function and streamline the printout into
a single statement for all cases, which changes
the 'no locks held by' / '%d lock[s] held by' phrasing that had a
dependency on English spelling of plurals, to a uniform:
locks held by bash/1234: %d
Which spells correctly for 0, 1 and higher values, and should also
be easier to parse both for humans and for scripts.
Finally, print out the last CPU a task has ran on. This is very
useful information for races and for locking bugs in particular.
This basically extends the 'on CPU#%d' message we print for
running tasks to all tasks we print.
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Suggested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Boqun Feng <boqun@kernel.org>
Cc: Gary Guo <gary@garyguo.net>
Cc: Mark Brown <broonie@kernel.org>
Cc: Theodore Tso <tytso@mit.edu>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Waiman Long <longman@redhat.com>
Link: https://patch.msgid.link/akoeSIQGwqd9cZwd@gmail.com
rmnet_get_endpoint() is shared by packet receive paths and
RTNL-protected control paths. The receive paths already run under RCU/BH
context through the RX handler, while the control paths reach
rmnet_get_endpoint() after obtaining the rmnet port with
rmnet_get_port_rtnl().
The helper walks port->muxed_ep[] with hlist_for_each_entry_rcu(). Pass
lockdep_rtnl_is_held() as the non-RCU protection condition so
CONFIG_PROVE_RCU_LIST can see the RTNL-protected control-path calls
while preserving the existing RCU-reader behavior for data paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change endpoint
lifetime or hash updates.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Subash Abhinov Kasiviswanathan <subash.a.kasiviswanathan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701124017.3205729-1-runyu.xiao@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
multi_lrc_create_parent() returns ERR_PTR(0) when there are not enough
engines in the class to create a parallel context. ERR_PTR(0) evaluates
to NULL, and the only caller already treats NULL as the non-error
"not enough engines" case.
Return NULL directly to make the non-error path explicit.
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260706071412.559909-1-lilinmao@kylinos.cn
Correct spaces or mix of tabs+spaces into proper tab-indented lines.
No functional impact (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Add a matching sysctl to go with CONFIG_SYSCALL_USER_DISPATCH.
kernel.syscall_user_dispatch (default 1 - allow) controls whether
userspace may arm syscall user dispatch (both via prctl and ptrace).
Disarming is always permitted - same semantics as comparable knobs.
Disabling while a task has armed syscall user dispatch does not
cause it to become inactive - instead it remains active until the
user attempts to disable/re-enable via prctl or ptrace. On the
next attempt to re-enable, the prctl/ptrace call fails gracefully.
The alternative would cause programs translating non-linux syscalls
to interpret those syscalls as linux syscalls, resulting in undefined
userland behavior.
Signed-off-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260706140020.873735-3-gourry@gourry.net
Syscall User Dispatch is presently built under CONFIG_GENERIC_SYSCALL and
cannot be disabled independently.
Add CONFIG_SYSCALL_USER_DISPATCH to make it an optional feature.
Signed-off-by: Gregory Price <gourry@gourry.net>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260706140020.873735-2-gourry@gourry.net
The GTP PDP lookup helpers are shared by RCU-protected data and report
paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The
helpers walk RCU hlists, but they do not currently pass the RTNL
condition for the control-path lookups.
Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing
RCU-reader callers remain valid because the RCU-list macros also accept
an active RCU read-side section; the added condition only documents the
non-RCU protection already used by RTNL control paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change PDP lifetime or
hash updates.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260701123925.3193089-1-runyu.xiao@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently each build with resolve_btfids enabled unnecessarily prints
the line 'INSTALL libsubcmd_headers' from libsubcmd.
Use the libcmd headers from source tree instead, without installation.
The same was done for objtool in commit ac99992677 ("objtool: Include
libsubcmd headers directly from source tree"), albeit for a different
reason.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Link: https://patch.msgid.link/20260702-libsubcmd-spam-v1-1-300ec142a62f@linutronix.de
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
REGMAP_MMIO is a hidden (non-user-visible) tristate symbol. Using
depends on it is incorrect because there is no way for the user to
enable it directly. Change to select, which is the convention used
by every other driver in the tree that needs REGMAP_MMIO.
Fixes: 8057cbb833 ("net: mdio: mscc-miim: Add depend of REGMAP_MMIO on MDIO_MSCC_MIIM")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260702032653.1580616-1-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test
verifies truncation limits in four steps: reject trunc(1) and
trunc(13) which are below ETH_HLEN, confirm normal forwarding works,
apply trunc(14) which truncates packets to the Ethernet header and
verify ping fails, then restore normal forwarding and verify recovery.
The kernel requires max_len >= ETH_HLEN (14 bytes). trunc(14) sets
OVS_CB(skb)->cutlen so pskb_trim strips the IP payload at output
time; the receiver drops the runt frame and no echo reply is
generated.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260702074926.1174810-1-houminxi@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit c7f92042d3 ("selftests: gpio: Add gpio-cdev-uaf tests") added
the gpio-cdev-uaf binary to TEST_GEN_PROGS_EXTENDED but never added it
to .gitignore. Building it with:
make -C tools/testing/selftests/gpio TARGETS=gpio
leaves gpio-cdev-uaf as an untracked file.
Fixes: c7f92042d3 ("selftests: gpio: Add gpio-cdev-uaf tests")
Signed-off-by: Cihan Karadag <cihan.cihan@gmail.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260707235707.1349969-1-cihan.cihan@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Add a TCP congestion-control struct_ops load test for a write through a
BTF pointer produced by bpf_rdonly_cast().
The test expects the verifier to reject the program before the TCP CA
btf_struct_access callback can whitelist the tcp_sock field write.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Reviewed-by: Amery Hung <ameryhung@gmail.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
check_ptr_to_btf_access() lets program-type btf_struct_access callbacks
validate writes before the default BTF access path rejects non-read
accesses. That bypasses the read-only policy for untrusted BTF pointers
created by helpers such as bpf_rdonly_cast().
Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the
common entry point, before the callback branch to handle all cases.
Fixes: 282de143ea ("bpf: Introduce allocated objects support")
Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Reviewed-by: Amery Hung <ameryhung@gmail.com>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
RISCV_HWPROBE_EXT_ZICFISS and RISCV_HWPROBE_EXT_ZICFILP are defined in
the hwprobe uAPI but are not documented in
Documentation/arch/riscv/hwprobe.rst. Add documentation for them.
Link: 302a2d45c2
Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-3-2c61f94a695a@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
A handful of vendor-extension entries indent continuation lines with a
tab character, while the rest of hwprobe.rst uses spaces. In addition,
many list items align their continuation lines under the 'm' of
':c:macro:' (column 7) rather than under the item text (column 4), so
the file mixes several indentation styles.
Replace the tabs with spaces and align every list item's continuation
lines under the item text, giving the whole file one consistent style.
Whitespace-only change, no functional change.
[Guodong: extend from tabs->spaces to normalizing all continuation-line
indentation across the file]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-2-2c61f94a695a@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The multi-letter extension enum is documented as being sorted
alphanumerically (see the "multi-letter extensions, sorted
alphanumerically" comment), but several Z entries have drifted out of
order.
Reorder the affected entries so the multi-letter Z list is sorted
alphanumerically again.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-1-2c61f94a695a@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
If the tail data can be inlined into the inode meta block, it should
be converted into a regular tail pcluster.
In principle, it should be converted into an uncompressed pcluster if
there is not enough gain to use compression (map->m_llen < map->m_plen);
but since there are various shipped images, relax the condition for
ztailpacking tail pcluster fallback instead of reporting corruption
incorrectly.
Reported-and-tested-by: Yifan Zhao <zhaoyifan28@huawei.com>
Reported-by: Alberto Salvia Novella <es20490446e@gmail.com>
Closes: https://github.com/erofs/erofs-utils/issues/51
Fixes: a5242d37c8 ("erofs: error out obviously illegal extents in advance")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Unlike the in-kernel trace_seq which uses a statically allocated buffer,
the userspace traceevent library's trace_seq uses a dynamically allocated
one. Therefore, every trace_seq_init() call must be paired with a
trace_seq_destroy(), otherwise it produces a memory leak.
In process_sample_event(), a trace_seq is initialized for each field when
formatting tracepoint raw_data, but the matching trace_seq_destroy() is
never called, leaking memory for every field of every sample processed.
Add the missing trace_seq_destroy() after using the trace_seq buffer to
properly free the allocated memory.
Detected with Valgrind on a perf.data file with 2,729 tracepoint samples:
Before: definitely lost: 55,537,664 bytes in 13,559 blocks
After: definitely lost: 0 bytes in 0 blocks
Fixes: 9d895e4684 ("perf data: Add tracepoint fields when converting to JSON")
Signed-off-by: Tanushree Shah <tshah@linux.ibm.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
When `perf record` samples a multi-threaded process and one of the
target threads exits during the session, perf itself may start burning
100% CPU (up to 200% across two cores) until the session ends. A
single dead fd is sufficient to trigger this; it can be reproduced with
15 pthreads in a compute loop where one thread exits halfway through.
The root cause is two independent instances of the same defect: dead
perf_event ring-buffer fds are left in a pollfd array. When a monitored
thread exits, the kernel closes its ring-buffer fd, which then returns
POLLHUP. POSIX specifies that poll() always reports POLLHUP and POLLERR
regardless of the events mask, so any dead fd left in the array makes
poll() return immediately every time, spinning in a tight loop:
3 seconds: 256,600 poll() calls, 0 context switches, only 21 write()
Woken up count goes from ~0 to 1,300,000+
There are two affected poll paths, fixed together here:
1. Record main loop, via fdarray__filter() (tools/lib/api/fd/array.c).
Since commit 59b4412f27 ("libperf: Avoid internal moving of
fdarray fds") it only zeroes events/revents without setting fd to
-1, so poll() keeps reporting POLLHUP for the entry. Setting
fd = -1 makes poll() skip it, matching the pattern already used in
the control-fd path at tools/perf/builtin-record.c:1673.
2. BPF sideband thread, perf_evlist__poll_thread()
(tools/perf/util/sideband_evlist.c). This thread polls for
PERF_RECORD_BPF_EVENT but, unlike the main record loop, never calls
fdarray__filter() at all, so dead fds accumulate forever and it
spins at 100% CPU:
Before fix: dJiffies=101, wchan=0 (running)
After fix: dJiffies=0, wchan=do_sys_poll (blocking)
Fixed by calling the existing evlist__filter_pollfd() helper after
evlist__poll(), mirroring the main record loop. <poll.h> is
included for the POLLERR/POLLHUP macros (previously unused there).
The two fixes compose: fix 1 makes poll() ignore dead fds (fd=-1); fix
2 ensures the sideband thread actually performs the filtering. Both
paths are affected in all kernels from v5.1/v5.9 to the current master
(7.2-rc1); the source of both functions is byte-identical across them.
BPF event recording is preserved: after the fix, perf.data still
contains PERF_RECORD_BPF_EVENT records and bpf_prog_info entries.
Verified on perf 6.1.76, 6.6.143 and 7.2-rc1 with a minimal reproducer
(Woken up 1,300,000 -> 3, CPU 100% -> 0%) and an A/B orthogonal test:
keeping the unpatched binary but preventing the target thread from
exiting also makes the storm disappear, confirming the trigger.
Fixes: 59b4412f27 ("libperf: Avoid internal moving of fdarray fds")
Fixes: 657ee55319 ("perf evlist: Introduce side band thread")
Signed-off-by: Jiawei Sun <abyssmystery@gmail.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The use of GEN_EVT_CODE macro to generate event enum label names is applied
inconsistently and is confusing, it also makes it harder to make use of
tools such as clangd when looking up symbols.
Replace them with writing the enum labels directly and adopting
new capitalized names instead of the current camel case ones.
Signed-off-by: Aiman Najjar <aiman.najjar@hurranet.com>
Link: https://patch.msgid.link/20260707-rtl8723bs-code-style-v2-2-df50f0eead17@hurranet.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The use of GEN_CMD_CODE macro to generate cmd enum label names is applied
inconsistently and is confusing, it also makes it harder to make use of
tools such as clangd when looking up symbols.
Replace them with writing the enum labels directly and adopting
new capitalized names instead of the current camel case ones.
Also clean up unused alias macros in rtw_cmd.h
Signed-off-by: Aiman Najjar <aiman.najjar@hurranet.com>
Link: https://patch.msgid.link/20260707-rtl8723bs-code-style-v2-1-df50f0eead17@hurranet.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Align the second argument of wait_event_interruptible() with the
open parenthesis to fix a checkpatch warning.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
Link: https://patch.msgid.link/20260707182038.37405-1-harimishal1@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 91842ed844 ("ata: libata-core: Set capacity to zero for a
security locked drive") introduced setting the device capacity (n_sectors)
to zero in ata_dev_configure() if the drive is security locked.
However, during runtime revalidation, ata_dev_revalidate() compares the
new capacity (now 0) with the old capacity (>0) and detects a mismatch.
Since it does not consider the locked status, it returns -ENODEV.
This revalidation failure can occur when doing a reset of the PHY (e.g.
hard reset) for a controller that has I/Os in flight. The timed out
I/Os trigger the SCSI Error Handling (EH) path, which in turn invokes
libata device revalidation. If the drive is locked at runtime (e.g.
it lost power during reset and relocked), revalidation sees the capacity
transition to zero and fails, eventually disabling the device.
Fix this by allowing the capacity transition to zero in
ata_dev_revalidate() if the drive is reported as security locked by
ata_id_is_locked().
Fixes: 91842ed844 ("ata: libata-core: Set capacity to zero for a security locked drive")
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Terrence Adams <tadamsjr@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Skip HPA resize in ata_hpa_resize() if the drive is security locked.
If the drive is locked, the command to read the native max address
fails with -EACCES, which currently causes the sticky quirk
ATA_QUIRK_BROKEN_HPA to be set on the device.
Setting this sticky quirk causes subsequent revalidations (after the
drive is unlocked) to bypass HPA checks, preventing the unlocked drive
from exposing its full native capacity without a reboot or device removal.
Cc: stable@vger.kernel.org
Signed-off-by: Terrence Adams <tadamsjr@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Closing a BO handle clears abo->client, while the underlying GEM object
may remain alive due to internal kernel references. As a result, code
executed after the BO handle is closed may dereference a NULL abo->client
pointer.
Remove accesses to abo->client from code paths that may execute after the
BO handle has been closed.
Fixes: d76856beb4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260707201556.562191-1-lizhi.hou@amd.com
The return value of init_srcu_struct() is currently ignored. If
initialization fails, subsequent use of hwctx_srcu may result in invalid
memory accesses.
Check the return value of init_srcu_struct() and propagate the error to
the caller.
Fixes: aac243092b ("accel/amdxdna: Add command execution")
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260707172323.539721-1-lizhi.hou@amd.com
drmm_mutex_init() may fail and return an error. Check the return value
and abort initialization if mutex creation fails.
Fixes: 8c9ff1b181 ("accel/amdxdna: Add a new driver for AMD AI Engine")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260707172307.539676-1-lizhi.hou@amd.com
The USB subsystem does not expect to lose its state on suspend:
xhci-hcd xhci-hcd.1.auto: xHC error in resume, USBSTS 0x401, Reinit
usb usb1: root hub lost power or was reset
To maintain state during suspend, the relevant GDSCs need to stay in
retention mode, like they do on other similar SoCs. Change the mode to
PWRSTS_RET_ON to fix.
Fixes: 95eeb2ffce ("clk: qcom: Add support for Global Clock Controller on QCS8300")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-2-b601d8a2f2f8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
As the PCIe host controller driver does not yet support dealing with the
loss of state during suspend, use retention for relevant GDSCs.
Fix the PCIe link not surviving upon resume, and GDSC error:
gcc_pcie_0_gdsc status stuck at 'off'
Fixes: 95eeb2ffce ("clk: qcom: Add support for Global Clock Controller on QCS8300")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-1-b601d8a2f2f8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
When building bpf selftest with latest bpf-next, I got the following failure:
In file included from /home/yhs/work/bpf-next/tools/testing/selftests/bpf/libarena/selftests/test_parallel_bitmap.bpf.c:8:
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/bitmap.h:11:8: error: redefinition of
'bitmap'
11 | struct bitmap {
| ^
/home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:51320:8: note: previous definition is here
51320 | struct bitmap {
| ^
The vmlinux.h struct bitmap comes from drivers/md/md-bitmap.c:
struct bitmap {
struct bitmap_counts { ... }
...
}
To fix the issue, I renamed libarena struct bitmap to arena_bitmap to avoid the conflict.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260707220136.910374-1-yonghong.song@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Introduce a passive polling delay to ensure more than one
"passive" thermal point is considered when throttling the GPU
thermal zone.
Signed-off-by: Haritha S K <haritha.k@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260505-qcs615_gpu_cooling-v2-1-1ba42260b29d@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Initial device tree for Microsoft Surface Pro 12in
Currently supported:
- UFS
- Touchscreen
- Pen
- USB 3.2 x2 (DP Alt Mode)
- Audio
- Wifi
- Bluetooth
- CDSP
- ADSP
- GPU
Not currently supported:
- Accelerometer
- Front, Back and IR cameras
- IRIS video decoder
Tested on Surface_Pro_12in_1st_Ed_with_Snapdragon_2110
Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260609145906.40854-2-harrison.vanderbyl@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
monaco-arduino-monza.dts includes monaco-monza-som.dtsi, which aleady
includes monaco.dtsi and monaco-pmics.dtsi. Remove the duplicates.
The resulting DTB file is identical.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260617-topic-monza_includes-v1-1-fcef9ce489fb@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Xiaomi 12 Lite 5G is a handset released in 2022
This commit has the following features working:
- Display (with simple fb)
- Touchscreen
- UFS
- Power and volume buttons
- Pinctrl
- RPM Regulators
- Remoteprocs - wifi, bluetooth
- USB (Device Mode)
Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260608143329.252033-3-zstaseg@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Xiaomi 12 Lite 5G (xiaomi,taoyao) is a smartphone based on the SM7325
SoC.
Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20260608143329.252033-2-zstaseg@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Enable GPU for talos-evk-som platform and provide path for zap
shader.
Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260427-talos-evt-gpu-v1-1-d40b6dffa108@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
reserved-memory region overlaps with firmware allocations (UEFI/EFI
runtime). The kernel then reports failure to reserve the region and
subsequent EFI runtime activity may trigger aborts.
The remote heap node was described as a fixed "no-map" region, which
turns it into a hard carveout. Replace it with a "shared-dma-pool"
reserved memory region with reusable CMA-backed allocation, specifying
alignment and size.
This avoids hard carveouts and reduces the chance of conflicting with
firmware memory maps while keeping an explicit pool for ADSP remote
heap usage.
Fixes: 90a58ffa9c ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
Cc: stable@kernel.org
Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260429073443.2027-1-jianping.li@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
SD card is detected as SDHS instead of UHS-I because sdhc_2 was
configured with vreg_s4a as vqmmc-supply, which cannot switch
between 1.8V and 3.3V.
Switch vqmmc-supply to vreg_l2a and update its voltage range to
1800000-2960000 uV to enable proper UHS-I signaling.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522105020.3588377-1-mchunara@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Describe and wire up the power supplies for the eDP panel and its
backlight. Previously, this was only working because of settings
inherited from the bootloader.
Fixes: 20dea72a39 ("arm64: dts: qcom: sc8180x: Introduce Lenovo Flex 5G")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-4-167785993231@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Align with the contemporary way of naming regulator nodes (regulator-
prefix) in preparation for adding more of them.
Reorder the renamed entries to match the expectations of the DT coding
style doc.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-3-167785993231@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
