This comment is missing a closing parenthesis:
* The in_atomic_preempt_off() check ensures that we come here holding
* the last preempt_count (which will get dropped once we return to
* __rcu_read_unlock().
This commit therefore adds it at the end of the sentence.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
- Keep audio working on Rockchip rk3588 by skipping disabling
unused clks
- Fix SpacemiT USB2 clk data so they actually work and keep the
HDMA bus clk enabled to avoid system hangs
- Avoid clk hangs on Qualcomm Eliza display hardware and revert
a patch that breaks PCIe on some Qualcomm platforms
-----BEGIN PGP SIGNATURE-----
iQJIBAABCAAyFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmp/RRMUHHN3Ym95ZEBj
aHJvbWl1bS5vcmcACgkQrQKIl8bklSUNJw/9H0FynE4W1JnI5G4KMWJ5g3DUI+BH
y8r/Z+RiCtuwSx7rnu7rKI8Exsg6P1pT2s6Gj4CZN+xBtjDbVIC3hXty99d2VhC6
VwEvUW2/fxTYT2B0UwUNCjvxboWtVLP10DrvVrFSYF7AhYZhRNrq1XygqfXpCF5E
/v1duwPQoYsFrjCbV9eC55IL6rka7CNk1Yqm5scmGG+musPy9x/RaP1wdQbotSI/
Q/oFkNsRcM1/jo/QDVYCP4cZDPgbc+bfydj0a0dGqknW/PIueGu7dOZUIT/q+RoA
9GIcM4jEkBUHb6IVbDKPXvJClirF3kFKmjm3sAnD38MCbiA2D/pdUK6I5GFS2ieB
I1//j6qG08chWzq94HLKJ5Xpkn/L+R6btErwNmodHPgJ/+JnKJHkWWrNVmxR+Txm
YfDK2bP9fPp3Lj8bUDFAHFpWZHSbSNoGHsDrlkHyTA4qt076KGR0XxQfNMJWiVkz
oqctmn9pUJAX5bFFSlxQVs/vQAO87wIijTrIdrRLbhyHR1gu6rDBB+TvCKFokkvR
087zTihEeumyl2P/SrQl8UCXiJm98869SrvsCbfJ4Xvf0C5wwTejhjoOLJoIAJwC
UOJ1Pdi5XsLTbGXheFofeZy09UPzBWzGRxsXkYh8KGtLxi0kov2PULAPYuTMfwga
hLo5q75jO3OWxVA=
=Vc/s
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"Fixes for the Qualcomm, Rockchip, and SpacemiT clk drivers:
- Keep audio working on Rockchip rk3588 by skipping disabling unused
clks
- Fix SpacemiT USB2 clk data so they actually work and keep the HDMA
bus clk enabled to avoid system hangs
- Avoid clk hangs on Qualcomm Eliza display hardware and revert a
patch that breaks PCIe on some Qualcomm platforms"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
dt-bindings: clock: Replace bouncing emails
Revert "clk: qcom: regmap-phy-mux: Rework the implementation"
clk: spacemit: k3: set hdma clock as critical
clk: spacemit: k3: fix USB2 bus clock
clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK
clk: rockchip: rk3588: don't disable unused I2S MCLK output gates
The ddsp_vtimelocal_fail and ddsp_bogus_dsq_fail tests skip calling
scx_bpf_dsq_insert_vtime() if scx_bpf_pick_idle_cpu() fails to find an idle
CPU (returns a negative error code). On loaded systems, this results in the
tests skipping the very assertions they are meant to verify.
Eliminate this flakiness by falling back to prev_cpu if no idle CPU is
found, ensuring the illegal dispatch operations are unconditionally
attempted and tested.
Fixes: a5db7817af ("sched_ext: Add selftests")
Signed-off-by: Michal Blaszczyk <michalblk@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
An mmap-able BPF array map (BPF_F_MMAPABLE) has its backing memory
vmalloc'ed up front at map creation time. array_map_mmap() then wired up
the whole mapping eagerly via remap_vmalloc_range(), which calls
vm_insert_page() for every page of the map. For large maps this makes
every mmap() O(number of pages): an 8MiB map inserts 2048 PTEs per
mmap() and tears them all down again on munmap(), even when user space
only touches a few pages (or none at all).
Populate the mapping lazily instead, the same way the arena map already
does. array_map_mmap() now only performs the bounds check and returns,
leaving the PTEs unpopulated; pages are inserted on demand by a new
array_map_mmap_fault() handler. Because the memory is already resident,
the fault handler simply resolves the vmalloc page and hands it to the
fault path. This makes mmap() O(1), and munmap() proportional to the
number of pages that were actually faulted in rather than to the size of
the map.
The handler is reached through a new optional ->map_mmap_fault callback.
Maps that provide it get a vm_operations_struct with a .fault handler;
maps that populate their mapping eagerly keep the one they had. Both
share the same open/close callbacks, so the existing VMA accounting
(VM_MAYWRITE write-active tracking, freeze handling) stays centralized
rather than each map installing its own vm_operations_struct.
Callers that want the pages populated up front can still request that
explicitly with MAP_POPULATE. Kernel-side access to the map (via the
vmalloc address) is unaffected.
Time for one mmap()+munmap() of an 8MiB mmap-able array map:
before after
no MAP_POPULATE, no access 226us 1.1us
no MAP_POPULATE, access all pages 236us 1341us
MAP_POPULATE, no access 312us 493us
MAP_POPULATE, access all pages 318us 519us
Mapping without touching the data, which is what this change targets,
gets ~160x cheaper. Faulting in the whole mapping one page at a time is
more expensive than the eager remap_vmalloc_range() loop, so users that
do touch every page should ask for MAP_POPULATE. Note that MAP_POPULATE
is not free before this change either: it adds ~85us (226us => 312us)
for no benefit, as the mapping is already fully populated.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Song Liu <song@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814155623.111565-1-song@kernel.org
A couple of relatively minor (but as ever important if you're hitting
them) and straightforward driver specific fixes, plus one new device ID
documented in the DT bindings for the DesignWare controller.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmp/Vl4ACgkQJNaLcl1U
h9Af0Af+J2MqcGcVuUFYO6NG9agqkqZkylfW5rPNPeEL63GqPjo2jh1YTaIiOO1X
pOvWxt6Ihf0WQF7MD6WJu7N+wWe2nkVR5AIvLe9HzD5xDBYv8xLd3JQi1O4LsrjL
/8aINGhuhizY+PSVQXf5mps0POGX8sb5vE9Q12bE6FCxmUgFSRMISs/dCend8qQl
p7YWIQkxkpEj5OWX95iG7wz5Yt0d8JGns+1cCdRaibdKKTG6SlfaQNX0vEV7n1Dx
tN3aJyOggSNS4ADed1S/pd1cZyv3663fRvYpya5nL84ynFJFKdHZvElo8AjOuUaO
up15wJ4SPnabI5wepnVlNCleLluK/Q==
=mKW0
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of relatively minor (but as ever important if you're hitting
them) and straightforward driver specific fixes, plus one new device
ID documented in the DT bindings for the DesignWare controller"
* tag 'spi-fix-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: virtio: mark device ready before registering the controller
spi: dw: fix wrong RX_SAMPLE_DLY setting after resume
spi: dt-bindings: snps,dw-apb-ssi: Document Axiado AX3005
A CPU returned by scx_bpf_pick_idle_cpu_node() can be re-advertised as
idle by an idle-to-idle re-pick before the BPF program validates the
selection, and the scx_bpf_pick_any_cpu_node() fallback doesn't claim
the CPU at all. Asserting that the picked CPU is absent from the node's
idle cpumask is therefore inherently racy.
Follow the same approach as commit 12da4723b6 ("selftests/sched_ext:
Make allowed_cpus idle validation race-free") and validate a stable
local invariant instead: a CPU executing ops.select_cpu() in a non-idle
scheduling context must not be advertised as idle in its node's idle
cpumask. Keep the node-membership validation of the picked CPU, which
is stable.
Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
There's one fix here for a data entry error in the voltage mapping in
the fp9931 driver, and a device ID addition for a LDO in the Qualcomm
PM8350b that's just a trivial quirk.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmp/VZAACgkQJNaLcl1U
h9BIiwf+OhrDj0zdVbufHV+m1+Nb8EP+UyfHfluhopSJi3dq1tY1P2Z0patUZdhU
gHMizes0lq0e1xce5H4W0cqSRJGylVR9NEDYmrO+c7sePKzVWmb0lznSIrQBg6MA
fMtaSfRxn1DjR78oms1h2O1qKHxFuHfIF0mKXEKYJKyKa48l3zU782xgXsXIIeXE
xB+4j5DVAW4aPROT/BCsJEmfjCwLw7lwf5o1tsfgtgKO520hdJ7L6wlrHnnmSZFr
g9YZDb4J9CDwHbbsBc9FCCJZw4u8rXm/fNQkVYF4DFCfodWQqPvdrB25JBYZM+Lf
rOabFiJ99+29qn22bhvg80FdFQAwog==
=y4W7
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"There's one fix here for a data entry error in the voltage mapping in
the fp9931 driver, and a device ID addition for a LDO in the Qualcomm
PM8350b that's just a trivial quirk"
* tag 'regulator-fix-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: fp9931: Fix VPOS/VNEG voltage selector table
regulator: qcom-rpmh: Add support for PM8350B
regulator: dt-bindings: qcom,rpmh: Add support for PM8350B
Introduce safe Rust wrappers around struct fwctl_device and struct
fwctl_uctx. This lets Rust drivers register fwctl devices and implement
firmware RPC callbacks through a typed trait interface.
The abstraction keeps lifetime and reference-count handling inside the
wrapper, exposes pinned per-FD user contexts to drivers, and validates the
layout assumptions required by the C fwctl allocation model. Allocation
sizes are padded so the kmalloc-backed C allocations also satisfy Rust
alignment requirements.
Registration owns driver private data with a lifetime tied to the bound
parent device and verifies the parent identity before registration.
Callbacks access that data through a higher-ranked closure, preventing its
erased lifetime from escaping, while Device remains only the refcounted
fwctl object. This avoids requiring Rust drop glue from the fwctl_device
release path after unregister or module teardown.
RPC callbacks receive typed scope information, a mutable request/response
buffer, and the userspace output-buffer size. Response pointer conversion,
length validation, and raw output-length handling remain inside the
abstraction.
Add the Rust sources to the FWCTL MAINTAINERS entry and add myself as the
maintainer for the Rust abstractions.
Link: https://patch.msgid.link/r/20260813152312.1311142-2-zhiw@nvidia.com
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
ringbuf_process_ring() walks the records between the consumer and the
producer with an ordering comparison:
while (cons_pos < prod_pos) {
cons_pos and prod_pos mirror the kernel's ring positions and are
unsigned long here too, so on 32-bit they wrap at 2^32 bytes of traffic.
When producer_pos has wrapped and consumer_pos has not, prod_pos is the
smaller of the two, the loop body never runs and no record is consumed.
Since consumer_pos only advances inside that loop, it never wraps either
and the consumer stops delivering samples for good, with no error
returned to the caller: ring_buffer__poll() keeps reporting zero
records while the kernel side fills up and starts dropping.
Compare the distance instead. The consumer never runs ahead of the
producer, so prod_pos - cons_pos is the amount of unconsumed data and
stays correct across the wrap.
64-bit hosts are unaffected in practice: the counters would need 16 EiB
to wrap. This is the userspace counterpart of the kernel-side walk fixed
in "bpf: Fix pending_pos walk on 32-bit ring position wrap"; a 32-bit
consumer hits whichever of the two comes first.
Signed-off-by: Israel Téllez García <i.tellez@btesa.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814124843.22041-5-i.tellez@btesa.com
In overwrite mode ringbuf_avail_data_sz() picks the newer of the consumer
and overwrite positions before measuring how much data is available:
return prod_pos - max(cons_pos, over_pos);
max() is an ordering comparison, and consumer_pos, producer_pos and
overwrite_pos are unsigned long, i.e. 32-bit on 32-bit architectures,
where Documentation/bpf/ringbuf.rst allows them to wrap. Once one of the
two positions has wrapped and the other has not, max() returns the older
one: the result is then a modular difference close to 2^32, so the
function reports far more available data than the ring can hold. Pollers
using BPF_RB_AVAIL_DATA get a bogus figure, and epoll consumers can be
woken with nothing to read.
Compare distances rather than positions. prod_pos - X is the amount of
data produced since X for either position, wrap or no wrap, so the newer
position is simply the one with the smaller distance, which is also the
value the function wants to return.
64-bit hosts are unaffected in practice: their counters would need
16 EiB to wrap. Found by review of the same class of bug fixed in
"bpf: Fix pending_pos walk on 32-bit ring position wrap".
Signed-off-by: Israel Téllez García <i.tellez@btesa.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814124843.22041-3-i.tellez@btesa.com
The reservation path caches the position of the oldest not-yet-committed
record in rb->pending_pos and advances it past already committed records
on every reservation:
while (pend_pos < prod_pos) {
consumer_pos, producer_pos and pending_pos are unsigned long, i.e.
32-bit on 32-bit architectures, and Documentation/bpf/ringbuf.rst states
that these counters may wrap around there. Every other comparison in the
file is written as a difference, so modular arithmetic keeps them
correct across the wrap. This one is an ordering comparison, and it is
not wrap-safe.
Once producer_pos wraps past 2^32, prod_pos is small while pend_pos
still holds its pre-wrap value, so the loop condition is false and
pending_pos is never advanced again. Reservations keep succeeding for a
while, because bpf_ringbuf_has_space() uses differences, but
new_prod_pos - pend_pos grows as the producer advances, and once it
exceeds rb->mask every subsequent __bpf_ringbuf_reserve() call fails:
the kernel believes a pending record spans the whole buffer. The ring
never recovers, bpf_ringbuf_output() drops every event from then on, and
nothing is logged.
Observed on four armv7 devices (i.MX7 Dual, 6.6.52) running a
tracepoint-based collector with a 512 KiB ring and 160-byte records.
Every one of them stopped delivering after exactly 26846821 records and
4295491360 bytes had passed through the ring, at event rates between 441
and 862 records/s, that is after 8 h to 17 h of uptime: the trigger is
the byte count, not time or load. That figure is 2^32 plus 524064 bytes,
and the excess is one ring's worth of grace period, as expected while
new_prod_pos - pend_pos is still below rb->mask. The last reservation
that fits is the largest record boundary X with X + 160 <= 524287, and
since 2^32 mod 160 = 96 the boundaries after the wrap sit at
X = 64 (mod 160), giving X = 524064. Userspace kept consuming normally
until the producer stopped, then read zero records for good. With this
patch applied, one of the four devices took 10 GiB through the same ring
with no stall, while the three unpatched ones kept wedging at the same
byte count.
64-bit hosts are unaffected in practice: their counters would need
16 EiB to wrap.
Compare the two positions as a difference instead. pending_pos never
runs ahead of producer_pos, so the unsigned difference is the real
distance between them and stays correct across the wrap.
Fixes: cfa1a2329a ("bpf: Fix overrunning reservations in ringbuf")
Signed-off-by: Israel Téllez García <i.tellez@btesa.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814124843.22041-2-i.tellez@btesa.com
The rcu_read_delay() and srcu_read_delay() functions are suppose to
avoid (or at least to minimize) read-side delays during call_rcu()-based
forward-progress testing. Although rcu_read_delay() does account for
this by testing rcu_fwd_cb_nodelay, it only does so in some cases, and
srcu_read_delay() does not bother at all. And rcutorture testing does
occasionally turn up the MIN_FWD_CBS_LAUNDERED failure when running
forward-progress tests on Tree SRCU flavors.
This commit therefore makes both rcu_read_delay() and srcu_read_delay()
take an immediate exit if rcu_fwd_cb_nodelay is set.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Currently, rcu_torture_fwd_prog_cr() announces function entry,
but silently exits if rcu_fwd_emergency_stop is set or if there is no
->call() function available. This could cause confusion, leading people
to believe that rcu_torture_fwd_prog_cr() is on the job when it is not.
This commit therefore also announces the early exits from this function.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
If torture_shuffle_init() successfully allocates shuffle_tmp_mask but
then fails to create the torture_shuffle kthread, the cpumask is never
freed.
Free the cpumask directly on the kthread-creation error path.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Currently __this_cpu_inc() is used to increment elements of both
the rcu_torture_count[] and rcu_torture_batch[] arrays. However,
this can fail when the increments can happen in interrupt handlers,
as recently became possible. This commit therefore upgrades the uses
of __this_cpu_inc() to the interrupt-safe this_cpu_inc().
KCSAN located this issue.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This commit adds the ->get_sp_seq and ->gp_diff fields to the
tasks_tracing_ops structure so that RCU Tasks Trace rcutorture runs will
track Reader Batch.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
An RCU Tasks Trace grace period is supposed to imply an RCU grace period,
and this implication is relied on by BPF. But this is not currently
tested. This commit therefore makes tasks_tracing_torture_read_lock()
sometimes use rcu_read_lock() instead of rcu_read_lock_trace(), thus
testing the required implication.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This commit adds a stall_only module parameter that shuts off all
rcutorture kthreads other than the RCU CPU stall-warning test kthreads.
The purpose of this is to test production applictions' reactions to
CPU stalls, and with minimal additional overhead. Or you can omit the
stall-warning tests as well and get a heavy no-op, your choice!
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Believe it or not, there are people who would like to run rcutorture
without actually torturing RCU. For example, some people would like to
induce various types of stall warnings without placing any unnecessary
additional overhead on their systems running in production. And
rcutorture provides the stall_cpu, stall_cpu_holdoff, stall_no_softlockup,
stall_cpu_irqsoff, stall_cpu_block, and stall_cpu_repeat module parameters
in order to allow the user to force numerous types of stalls. In addition,
rcutorture provides a great number of other module parameters to allow the
user to reduce other overhead.
But unfortunately, there is no way to turn of the rcu_torture_writer()
portion of this torture test, which on my x86 laptop consumes somewhere
between 40% and 45% of a CPU. Although this is quite lightweight for a
torture test, it is not welcome on systems running production workloads.
This commit therefore adds an nwriters module parameter that defaults
to 1 but can be set to 0 in order to disable the rcu_torture_writer()
portion of the torture test, but that cannot be set to any other value
(that is what the fakewriters module parameter is for!). This reduces
the overhead to well under 1% of a CPU, which is much more likely to be
compatible with production workloads.
Reported-by: Breno Leitao <leitao@debian.org>
Reported-by: Puranjay Mohan <puranjay@kernel.org>
Reported-by: Usama Arif <usama.arif@linux.dev>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Use the kernel's standard symbolic task-state representation instead of
printing raw hexadecimal task-state values.
Suggested-by: Zqiang <qiang.zhang@linux.dev>
Co-developed-by: Wang Lian <lianux.mm@gmail.com>
Signed-off-by: Wang Lian <lianux.mm@gmail.com>
Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
The rcu_torture_preempt() function uses cpumask_next(), and if that
returns an out-of-bounds result, re-invokes cpumask_next() on -1.
Which is exactly what cpumask_next_wrap() does. This commit therefore
saves a couple of lines by instead using cpumask_next_wrap().
This was reported by metacode when asked to look for opportunities
to use cpumask_next_wrap() in kernel/rcu.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Although rcutorture has long had the irqreader module parameter, this
parameter results only in RCU readers in softirq handlers, specifically,
timers. This commit therefore uses smp_call_function_single() to test
RCU readers in real hardware interrupt handlers, thus providing the full
effect from the irqreader module parameter.
However, consistency/debug checks must account for the possibility that
the smp_call_function_single() handler function is directly invoked
from the idle loop, in which case, for example, in_hardirq() will
return false. This commit uses a per-CPU variable to record being in
the rcu_torture_irq() smp_call_function_single() handler function.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
A couple more fixes for regmap, this time for the SoundWire MBQ support.
- Several drivers omit the readable_reg callback and it's generally
optional in regmap but the MBQ code had an assumption that one was
present added in one of the APIs, remove that.
- The timeout and retry intervals were swapped in read_poll_timeout()
for soundwire-mbq.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmp/VQkACgkQJNaLcl1U
h9B47Qf7BRh4U/G5/UZqHworvgBB+CUqdc/PdEzPlB7u8VmlEDixRID8tvJv4vX5
oG6dduuNnR/Op9SWD91lU0aicFQgeCPArMKYxsl9A4DRJBcYws70897yJgNdIly+
2sdTxpRhl80bL0FIBaUYOMI9Gg0LD/OuudVaLzEwyYde8M+xfQEBFEjRTPbe68Vr
yg/aAVVsefID3P0fGzbNhuiCLbhUT29K5sXxSM+LDtPk2Bz9Rrt8tBiYGtDmTBxj
J6CGe6wF7kLxLW/PPF4/eNMtnU8oGfq/X2L9G57b9q3QwHV8PcrHFKqH5GuXl1wJ
13QpamimMfyqKmcOUF5GqVbyFG7mww==
=jwlB
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v7.2-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"A couple more fixes for regmap, this time for the SoundWire MBQ
support:
- Several drivers omit the readable_reg callback and it's generally
optional in regmap but the MBQ code had an assumption that one was
present added in one of the APIs, remove that
- The timeout and retry intervals were swapped in read_poll_timeout()
for soundwire-mbq"
* tag 'regmap-fix-v7.2-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: sdw-mbq: don't call an unset readable_reg callback
regmap: sdw-mbq: Fix swap of timeout and retry times
This commit adds a check for failure to have fully deboosted a
multi-segmented RCU reader at the end of the full read-side critical
section. This check only happens for fully task-level readers, because
a a handler might have interrupted an already-boosted task-level RCU
reader, and a reader in that handler could then cause false positives.
The first failed check (due to an RCU reader that was not immediately
deboosted) causes a splat, but only when the disabled-by-default
deboost_timeliness_check module parameter is enabled. Regardless of the
value of this parameter, it produces a list of the segments making up that
RCU reader following a "Slow-deboost rcutorture reader segments" heading.
Subsequent failures fail silently, all in the name of keeping console
output down to a dull roar.
Although most uses of RCU priority boosting serve as debugging aids,
this might change, and in fact might already have changed. And allowing
(for example) RCU priority boosting to persist until the next scheduler
tick could cause an aggressively real-time system to miss sub-millisecond
deadlines. So we do need to find this sort of problem during testing,
and preferably not in the field.
The name and type of the newly added rcu_torture_ops function pointer
(named "->is_task_rcu_boosted()") may need to change should other
end-of-reader checks be needed. But let's start simple.
Oh, and Claude figured out that rcu_is_task_rcu_boosted() could be
lockless. Perhaps there is hope for AI yet! ;-)
[ paulmck: Apply Akira Yokosawa feedback. ]
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
- atmel-mci: Fix use-after-free in atmci_remove due to race condition
- loongson2: Fix sg iteration in data reorder functions
- omap_hsmmc: Fix busy_timeout overflow in ns conversion on 32-bit
- sdhci: Make tuning_err a signed int
- sdhci: Unmap the bounce buffer before device release
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmp/I6EQHHVsZmhAa2Vy
bmVsLm9yZwAKCRD+JoQlc1iMKfYNEAC51HDTsIkN0SWfsxC0YT1jeo/90MViAoSm
j8HIXfdueeiV6iJcb2g9oYUKvfdstxWd4Q7Nx5rM6vRwOJqc/gPY9sTbSW/wnyqR
LdJoGSxV88dwmnk3Pc2r2SlB9pbNhFGcGime+RQ/Ri2G1pNpu5FDiFLLAI1c/Rko
5s2kuGOn8LHeezZZdVr5mPDq5Ya+SYZkUmPbdqfJO2NdxZm/XGFcV7V/vAqYizCX
UlgjbFtsSJ6lxhW7cG6IcmDZro2i8hxMZhbdip6qsnY9sazgeG7EkWqDBcqGfAhF
VbgXwk2v/kXvIbN0ygpsoUxA1LTw+Xg09h4gXx6EisQkhUJWiLpipZBNMCcezbEl
HtdfYq/omUfA3ZhvxXTJPFuaT3OqSimYHJs7FF0fbAYpVqS49ep6JeVp0zYH6tjH
Y5ydsDYj31e4e+nuBCvibIfhL3vusXGk9ehXO4kboFSe8YVd6rCz6iJYcNFYKq+B
Hif9bY6FORI1//5nnhFGCSNzyysdeO6mVtDvv08/+1JfNmtGEFQQJQmsTv4W51r+
crlONm41WfNaPFgWtNh6cEyNHJk+tVd6FlotiQnKu3QSWu6FG7vuXrRyuVyOzHYb
G5YEwFyQR1iIrgRsAm9YH084tR7pZLmFwcjXSt/LxNnTw4tGq9RjtLxGBH2GsRtt
UnyQXxL3bA==
=Ihe4
-----END PGP SIGNATURE-----
Merge tag 'mmc-v7.2-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
- atmel-mci: Fix use-after-free in atmci_remove due to race condition
- loongson2: Fix sg iteration in data reorder functions
- omap_hsmmc: Fix busy_timeout overflow in ns conversion on 32-bit
- sdhci:
- Make tuning_err a signed int
- Unmap the bounce buffer before device release
* tag 'mmc-v7.2-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: loongson2: Fix sg iteration in data reorder functions
mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit
mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition
mmc: sdhci: unmap the bounce buffer before device release
mmc: sdhci: make tuning_err a signed int
- arm: Don't treat performance state 0 as an error
- mediatek: Fix mt8183 hang on boot
- mediatek: Fix potential null pointer dereference
- mediatek: Prevent using uninitialized data
- mediatek: Avoid setting RTFF's CLK_DIS before NRESTORE
- qcom: Add missing MXC and MMCX power domains for Eliza
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmp/IjIQHHVsZmhAa2Vy
bmVsLm9yZwAKCRD+JoQlc1iMKcMiEACePh2D5q9HrQfb1R1oRjTLm5ozqmR4SHNj
bSJ4doCKlqLkAWR8uxeHGqk0RICnXUmeBWg72y3kp1FhymCWu7tr97/jwTtnmgP1
ztWATvb4IxkmjZE6Z+bhGZWnGiMZa2lITvWYnCzC5++dACQkLTTXlo6nBEk824/w
RXw85ph/cnXilaQOH6l3T45uZolCmLJWeq+NqDoKhA5aStUmzO8+zAg53MjRpkR0
vZyemvBtrgO0ojYyI/APA4bUQFicmuZY3sXMjUHzRZNU8BWu4lsH8H8Pe3q2qVbn
hUKCZmEkukKWFLyOeOMRibm3pKnEXvNuABcNL1KmyAMM91kXN1dfNaVbXUxS/3/2
/+0T4anwQfyTw0qrUUf68HtqaPrCBo9Pj/oP2BODKMORj9MsY2J1LUBNbGQvxux9
MHeT6v71eve7OV7LcQ9sZk1aM6X03BySVQsBhr5su8XQ6XuGVQqv3tTr1tLamoqd
N8e0TRjJIjnqa+hu/bDHCcEIOaFDLlvBxFd9c9uLk+NRT1URDIFCzo16W+l01AYn
2XRAKtBpHNqq+2iQVhvnQIVjaijF3pasmkyUr6IsDm6QfKuI9EyJXBeoeqI0ZyQ3
PsuXhaZumFCigvWChvELMkRyScsb8Czyw0fNP2cLlTb77bL1pdXrq8AjfDCoSjp5
S0CskFrnNg==
=oG0O
-----END PGP SIGNATURE-----
Merge tag 'pmdomain-v7.2-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm
Pull pmdomain fixes from Ulf Hansson:
- arm: Don't treat performance state 0 as an error
- mediatek:
- Fix mt8183 hang on boot
- Fix potential null pointer dereference
- Prevent using uninitialized data
- Avoid setting RTFF's CLK_DIS before NRESTORE
- qcom: Add missing MXC and MMCX power domains for Eliza
* tag 'pmdomain-v7.2-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
pmdomain: mediatek: mfg: initialize prev_o in mtk_mfg_attach_dev()
pmdomain: qcom: rpmhpd: Add missing MXC and MMCX power domains for Eliza
pmdomain: arm: Fix -EINVAL from scmi_pd_set_perf_state() on state 0
pmdomain: mediatek: Fix mt8183 hang on boot
pmdomain: mediatek: fix remaining %pOF after of_node_put()
pmdomains: mediatek: Avoid setting RTFF's CLK_DIS before NRESTORE
scx_bpf_dsq_reenq() is registered with KF_IMPLICIT_ARGS and its kernel BTF
prototype omits the trailing bpf_prog_aux argument. The ___compat extern
declares the argument explicitly, so libbpf never matches the prototype and
the weak extern silently stays unresolved on every kernel. The wrapper
always takes the old fallback path, which disables generic reenq users like
scx_qmap's lowpri mechanism and fails non-local reenq with "kernel too old"
even on kernels that have the kfunc.
Drop the explicit aux argument. Also correct the stale v6.20 reference, the
kfunc was added in v7.1.
Fixes: 9c34c5074d ("sched_ext: Introduce scx_bpf_dsq_reenq() for remote local DSQ reenqueue")
Cc: stable@vger.kernel.org # v7.1+
Signed-off-by: Tejun Heo <tj@kernel.org>
Replace explicit NULL comparisons with the boolean form to follow
the kernel coding style:
dev->class != NULL -> dev->class
user_dev == NULL -> !user_dev
No functional changes intended.
Signed-off-by: Kai Kuang <kuangkai@kylinos.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260812060644.210997-1-kuangkai@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When creating new DtsLine object, pass expected indentation depth as
constructor, instead of assigning it immediately after, so the code will
be easier to read and explicit (depth is not supposed to change during
DtsLine lifetime).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260803-n-dts-style-checker-continued-v3-2-6c9776928cea@oss.qualcomm.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the Texas Instruments DA850/AM18x Video Port Interface (VPIF)
device tree binding from text format to YAML dt-schema.
Add power-domains property missing from text.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260813-ti-da850-vpif-v2-1-80ba62ca53d0@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The "{,N}" regex syntax is non-standard, but happens to be supported by
python re module. It is equivalent to "{0,N}" which is more commonly
supported. This fixes using a rust implementation of the DT schema
tools.
Link: https://patch.msgid.link/20260813174037.2263884-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The $ref "arm,gic.yaml#/properties/#interrupt-cells" doesn't work when
used with another json-schema implementation (rust). The issue is it not
a valid URI due to the 2nd "#" character in the JSON pointer. Though a
"#" is supposed to be valid within a JSON pointer. A possible solution
is to encode the "#" as "%23" instead, but the dtschema tools don't
handle that.
Just avoid all these issues as the $ref only resolves to a "const: 3"
schema and specify it directly.
Link: https://patch.msgid.link/20260813145453.1919998-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The original 'offsetof()' + offset is equal to the new 'offsetof()'. Use
the new 'offsetof()' instead.
Rename two variables btw:
* offsetof_num -> num_off
* percpu_data_sum -> sum
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814173206.93082-6-leon.hwang@linux.dev
Use array_map_mmap_sz() for PERCPU_ARRAY like ARRAY in bpf_map_mmap_sz().
This lets bpf_map__set_value_size() skip mmap(), memcpy(), and munmap()
when the old and new value sizes occupy the same number of pages.
Fix some typos btw:
* mmapble -> mmapable
* satisified -> satisfied
* relocatin -> relocation
* atach_btf_obj_fd -> attach_btf_obj_fd
* len_secnd -> len_second
* precendence -> precedence
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814173206.93082-3-leon.hwang@linux.dev
I2C clock frequency for HJMC01 is 200MHz, define a new ACPI
HID for it.
Signed-off-by: Xiangyang Yu <hunter.yu@hj-micro.com>
Signed-off-by: Hongnan Li <clarke.li@hj-micro.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260813064025.45242-1-clarke.li@hj-micro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use HZ_PER_MHZ multiplier for fixed_clk_rate values to
improve readability.
Signed-off-by: Hongnan Li <clarke.li@hj-micro.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260813063005.42925-1-clarke.li@hj-micro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For IPv4 ERSPAN:
In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0)
and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags
structure. Since transmit paths can run locklessly and concurrently,
this leads to a data race.
Furthermore, modifying tunnel->parms.o_flags permanently alters the
tunnel configuration. To work around this, erspan_fill_info() (which
reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If
erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly)
race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldn't,
leading to GRE header corruption (injecting a key field into the ERSPAN
GRE header).
Fix this by:
1) Passing flags as an argument to __gre_xmit().
2) Using local stack flags in ipgre_xmit(), gre_tap_xmit(), and erspan_xmit()
to prevent TOCTOU data races with concurrent configuration updates,
and passing them to __gre_xmit().
3) Removing the racy modification of t->parms.o_flags in erspan_fill_info().
4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally
in ipgre_fill_info().
For IPv6 ERSPAN:
ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in
t->parms.o_flags even though it does not use these flags for building
the GRE header (it uses local flags). This permanently corrupts the
configuration and races with ip6gre_fill_info() which reads it.
Remove the redundant and racy modification.
This should remove false sharing in a fast path.
Add const qualifiers in ipgre_fill_info(), erspan_fill_info()
and ip6gre_fill_info() to clarify that these methods are not
supposed to write any live parameters.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260812142257.21283-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
fcg_cgroup_set_weight() updates cgc->weight and the parent's
child_weight_sum but doesn't bump hweight_gen, so the hweights cached by
cgrp_refresh_hweight() stay stale until some task activation bumps the
generation. For cgroups whose tasks never go through a 0->n runnable
transition (e.g. persistently busy ones), a cpu.weight change never
propagates to scheduling at all.
Bump hweight_gen on weight changes so the next refresh recomputes with
the new weight.
Verified on a flatcg VM: a live cpu.weight 100->800 change on a busy
cgroup leaves HWT update at 0 and the distribution unchanged; with it,
hweight_gen increments and the refresh recomputes.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The acpi_get_first_physical_node() usage in acpi_create_video_bus_device()
is generally unsafe because in theory the device returned by it may be
freed at any time.
Address this issues by using acpi_bus_get_primary_device() instead of
acpi_get_first_physical_node() and dropping the device reference
acquired by it after registering the child.
Fixes: 6ab3532b4c ("ACPI: video: Switch over to auxiliary bus type")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/10906414.nUPlyArG6x@rafael.j.wysocki
The acpi_get_first_physical_node() usage in acpi_platform_fill_resource()
and acpi_create_platform_device() is generally unsafe because in theory
the device returned by it may be freed at any time [1].
It is also inefficient because acpi_get_first_physical_node() is called
multiple times for the same argument which can be avoided.
Address these issues by using acpi_bus_get_primary_device() instead of
acpi_get_first_physical_node() and adjusting the code to call it just
once at the beginning of and acpi_create_platform_device() and drop
the device reference acquired by it upon the return from that function.
Fixes: 3b95bd1605 ("ACPI: introduce a function to find the first physical device")
Fixes: a252d881c5 ("ACPI / platform: Pay attention to parent device's resources")
Link: https://sashiko.dev/#/patchset/12955541.O9o76ZdvQC%40rafael.j.wysocki [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/3436112.aeNJFYEL58@rafael.j.wysocki
The function used for obtaining the first "physical" device for which
the given ACPI one is the ACPI companion, acpi_get_first_physical_node(),
may return a stale device pointer (mostly in theory) because
acpi_unbind_one() may run as a whole after dropping the ACPI device's
physical_node_lock in acpi_get_first_physical_node() and before it
returns. The last reference to the "physical" device may be dropped
then before the pointer to it is returned to the caller.
If that happens and the acpi_get_first_physical_node() caller invokes
get_device() on the pointer obtained from it, which is done by the
majority of its callers, a use-after-free will occur.
To prepare for addressing this problem, introduce a new function for
getting the first "physical" device associated with the given ACPI one
(the "primary physical device") that will also reference count the
device in question before returning a pointer to it.
Make that new function and acpi_get_first_physical_node() share the
physical node list lookup code.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2843318.mvXUDI8C0e@rafael.j.wysocki
When device_add() fails after acpi_device_set_name() has allocated an
instance ID and a new acpi_device_bus_id has been linked into
acpi_bus_id_list, the rollback path only removes wakeup_list and
detaches the ACPI handle data.
That leaves the bus-ID bookkeeping behind and keeps the allocated
instance number consumed.
Move the bus-ID cleanup and wakeup-list removal into a single helper.
Use it from both the normal device teardown path and the device_add()
rollback path. The wakeup list node is initialized before registration,
so it can be deleted without checking whether the device is wakeup-
capable like in the original teardown path.
Fixes: d783156ea3 ("ACPI / scan: Define non-empty device removal handler")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
[ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ]
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/20260808085943.526-1-getshell@seu.edu.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
modpost has a lot of error logging with module name, but the module name
is logged in a plethora of ways. Add struct module * parameter to
modpost_log(), and wrappers mod_warn() and mod_error(), to allow logging
with a unified module name, if provided.
If the module is provided, the messages will be of the format:
(ERROR|WARNING): modpost: (modname.ko|vmlinux): message
Actual conversion is done separately.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/f27bd8810f0ef12fb86068f0190e4e0afa81e0fa.1786120005.git.jani.nikula@intel.com
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
The Kconfig frontend should render options that depend on a
previous option in the submenu of that previous option. But
currently, this breaks for negative dependencies. For example,
option FOO may be rendered in the submenu of option BAR, despite
FOO actually depending on !BAR.
Let's fix this ironic rendering by modifying Kconfig to explicitly
check negative dependencies.
I've only tested locally on x86, but as far as I can tell, this only
changes how 2 options are rendered in the menu:
1. NTFS3_FS, no longer in the NTFS_FS submenu, and
2. MTD_BLOCK_RO, no longer in the MTD_BLOCK submenu.
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: Xi Ruoyao <xry111@xry111.site>
Closes: https://lore.kernel.org/all/cbe95c15d2760f6fce8eaf207c969ce8fd3703aa.camel@xry111.site/
Assisted-by: Claude:claude-4.8-opus
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260801145238.2140291-1-julianbraha@gmail.com
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Tested-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Newer FW reports the SD group size directly in the NIC vport context
via the sd_group_size field, gated by the sd_group_size capability.
Switch sd_init() to source the group size from there and fall back to
the MPIR-based host_buses query only when the cap is absent.
sd_group_size might return 1 in some FW configuration. Add explicit
check to disable SD creation in this case.
While here, rename host_buses to group_size throughout sd.c to follow
the new name on capable FW.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260810093037.3138197-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
