Hi Zqiang,
kernel test robot noticed the following build warnings:
[auto build test WARNING on paulmck-rcu/dev]
[also build test WARNING on linus/master v6.10-rc2 next-20240604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
From: Zqiang
This commit allows rcutorture to test double-call_srcu() when the
CONFIG_DEBUG_OBJECTS_RCU_HEAD Kconfig option is enabled. The non-raw
sdp structure's ->spinlock will be acquired in call_srcu(), hence this
commit also removes the current IRQ and preemption disabling so as to
avoid l
This commit adds a tools/rcu/rcu-updaters.sh script that uses bpftrace
to print a histogram of the RCU update-side primitives invoked during
the specified time interval, or until manually terminated if no interval
is specified.
Sample output on an idle laptop:
@counts[poll_state_synchronize_rcu]:
From: Jeff Johnson
Fix the following 'make W=1' warnings:
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/rcu/rcutorture.o
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/rcu/rcuscale.o
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/rcu/refscale.o
Signed-off-by: Jeff
On powerpc systems, spinlock acquisition does not order prior stores
against later loads. This means that this statement:
rfcp->rfc_next = NULL;
Can be reordered to follow this statement:
WRITE_ONCE(*rfcpp, rfcp);
Which is then a data race with rcu_torture_fwd_prog_cr(), specif
Hello!
This series contains RCU torture-test updates:
1. Make rcutorture support srcu double call test, courtesy of Zqiang.
2. Fix rcu_torture_fwd_cb_cr() data race.
3. Add missing MODULE_DESCRIPTION() macros, courtesy of Jeff Johnson.
4. Add rcu-updaters.sh script.
From: Frederic Weisbecker
This reverts commit 28319d6dc5e2ffefa452c2377dd0f71621b5bff0. The race
it fixed was subject to conditions that don't exist anymore since:
1612160b9127 ("rcu-tasks: Eliminate deadlocks involving do_exit() and
RCU tasks")
This latter commit removes the use of SR
From: Frederic Weisbecker
When RCU-TASKS-TRACE pre-gp takes a snapshot of the current task running
on all online CPUs, no explicit ordering synchronizes properly with a
context switch. This lack of ordering can permit the new task to miss
pre-grace-period update-side accesses. The following dia
Hello!
This series provides fixes for RCU Tasks:
1. Revert "rcu-tasks: Fix synchronize_rcu_tasks() VS
zap_pid_ns_processes()", courtesy of Frederic Weisbecker.
2. Fix stale task snaphot for Tasks Trace, courtesy of Frederic
Weisbecker.
From: Frederic Weisbecker
The parts explaining the bypass lifecycle in (de-)offloading are out
of date and/or wrong. Bypass is simply enabled whenever SEGCBLIST_RCU_CORE
flag is off.
Fix the comments accordingly.
Signed-off-by: Frederic Weisbecker
Signed-off-by: Paul E. McKenney
---
include/
From: Frederic Weisbecker
The bypass lock contention mitigation assumes there can be at most
2 contenders on the bypass lock, following this scheme:
1) One kthread takes the bypass lock
2) Another one spins on it and increment the contended counter
3) A third one (a bypass enqueuer) sees the con
From: Frederic Weisbecker
The (de-)offloading process used to take care about the NOCB timer when
it depended on the per-rdp NOCB locking. However this isn't the case
anymore for a long while. It can now safely be armed and run during the
(de-)offloading process, which doesn't care about it anymo
From: Frederic Weisbecker
Upon NOCB deoffloading, the rcuo kthread must be forced to sleep
until the corresponding rdp is ever offloaded again. The deoffloader
clears the SEGCBLIST_OFFLOADED flag, wakes up the rcuo kthread which
then notices that change and clears in turn its SEGCBLIST_KTHREAD_CB
Hello!
The following series updates RCU's callback offloading:
1. Fix segcblist state machine comments about bypass,
courtesy of Frederic Weisbecker.
2. Fix segcblist state machine stale comments about timers,
courtesy of Frederic Weisbecker.
3. Use kthread parkin
From: Frederic Weisbecker
When the grace period kthread checks the extended quiescent state
counter of a CPU, full ordering is necessary to ensure that either:
* If the GP kthread observes the remote target in an extended quiescent
state, then that target must observe all accesses prior to the
From: Frederic Weisbecker
RCU stall printout fetches the EQS state of a CPU with a preceding full
memory barrier. However there is nothing to order this read against at
this debugging stage. It is inherently racy when performed remotely.
Do a plain read instead.
This was the last user of rcu_dy
From: Frederic Weisbecker
When the boot CPU initializes the per-CPU data on behalf of all possible
CPUs, a sanity check is performed on each of them to make sure none is
initialized in an extended quiescent state.
This check involves a full memory barrier which is useless at this early
boot stag
From: Frederic Weisbecker
A full memory barrier is necessary at the end of the expedited grace
period to order:
1) The grace period completion (pictured by the GP sequence
number) with all preceding accesses. This pairs with rcu_seq_end()
performed by the concurrent kworker.
2) The grace
From: Frederic Weisbecker
When the grace period kthread checks the extended quiescent state
counter of a CPU, full ordering is necessary to ensure that either:
* If the GP kthread observes the remote target in an extended quiescent
state, then that target must observe all accesses prior to the
From: Frederic Weisbecker
When the grace period kthread checks the extended quiescent state
counter of a CPU, full ordering is necessary to ensure that either:
* If the GP kthread observes the remote target in an extended quiescent
state, then that target must observe all accesses prior to the
Hello!
This series removes redundant memory barriers from the grace-period
code paths:
1. Remove full ordering on second EQS snapshot, courtesy of Frederic
Weisbecker.
2. Remove superfluous full memory barrier upon first EQS snapshot,
courtesy of Frederic Weisbecker.
3
From: Frederic Weisbecker
When rcu_barrier() calls rcu_rdp_cpu_online() and observes a CPU off
rnp->qsmaskinitnext, it means that all accesses from the offline CPU
preceding the CPUHP_TEARDOWN_CPU are visible to RCU barrier, including
callbacks expiration and counter updates.
However interrupts
From: Oleg Nesterov
The rcu_sync structure's ->gp_count field is always accessed under the
protection of that same structure's ->rss_lock field, with the exception
of a pair of WARN_ON_ONCE() calls just prior to acquiring that lock in
functions rcu_sync_exit() and rcu_sync_dtor(). These lockless
If a CPU is running either a userspace application or a guest OS in
nohz_full mode, it is possible for a system call to occur just as an
RCU grace period is starting. If that CPU also has the scheduling-clock
tick enabled for any reason (such as a second runnable task), and if the
system was boote
Interrupts are enabled in srcu_gp_end(), so this commit switches from
spin_lock_irqsave_rcu_node() and spin_unlock_irqrestore_rcu_node()
to spin_lock_irq_rcu_node() and spin_unlock_irq_rcu_node().
Link:
https://lore.kernel.org/all/febb13ab-a4bb-48b4-8e97-7e9f7749e6da@moroto.mountain/
Reported-by
Signed-off-by: Paul E. McKenney
Cc: Uladzislau Rezki
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d6c90161c7bfe..3f2047082073f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18868,6 +18868,7 @@ M: Neeraj Upadhyay
(kernel/rcu/tasks.h)
There is no direct RCU counterpart to lockdep_assert_irqs_disabled()
and friends. Although it is possible to construct them, it would
be more convenient to have the following lockdep assertions:
lockdep_assert_in_rcu_read_lock()
lockdep_assert_in_rcu_read_lock_bh()
lockdep_assert_in_rcu_read_lock
From: "Joel Fernandes (Google)"
In the synchronize_rcu() common case, we will have less than
SR_MAX_USERS_WAKE_FROM_GP number of users per GP. Waking up the kworker
is pointless just to free the last injected wait head since at that point,
all the users have already been awakened.
Introduce a ne
Interrupts are enabled in rcu_gp_init(), so this commit switches from
local_irq_save() and local_irq_restore() to local_irq_disable() and
local_irq_enable().
Link:
https://lore.kernel.org/all/febb13ab-a4bb-48b4-8e97-7e9f7749e6da@moroto.mountain/
Reported-by: Dan Carpenter
Signed-off-by: Paul E.
From: Neeraj Upadhyay
When all wait heads are in use, which can happen when
rcu_sr_normal_gp_cleanup_work()'s callback processing
is slow, any new synchronize_rcu() user's rcu_synchronize
node's processing is deferred to future GP periods. This
can result in long list of synchronize_rcu() invocat
Hello!
This series provides miscellaneous fixes:
1. Add lockdep_assert_in_rcu_read_lock() and friends.
2. Reduce synchronize_rcu() delays when all wait heads are in use,
courtesy of Neeraj Upadhyay.
3. rcu/tree: Reduce wake up for synchronize_rcu() common case,
co
This commit expands on the ordering properties of rcu_assign_pointer()
and rcu_dereference(), outlining their constraints on CPUs and compilers.
Reported-by: Rao Shoaib
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/whatisRCU.rst | 30 +++---
1 file changed, 19 in
This commit adds more detail to the Tasks RCU and Tasks Rude RCU
descriptions in Requirements.rst. While in the area, add Tasks Trace
RCU to the Tasks-RCU table of contents.
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Paul E. McKenney
---
.../RCU/Design/Requirements/Requirements.rst
Hello!
This series provides documentation updates:
1. Update Tasks RCU and Tasks Rude RCU description in
Requirements.rst.
2. Clarify rcu_assign_pointer() and rcu_dereference() ordering.
Thanx, Paul
-
From: Jeff Johnson
Fix the 'make C=1' warning:
kernel/scftorture.c:71:6: warning: symbol 'torture_type' was not declared.
Should it be static?
Signed-off-by: Jeff Johnson
Signed-off-by: Paul E. McKenney
---
kernel/scftorture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Jeff Johnson
Fix the 'make W=1' warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/locking/locktorture.o
Signed-off-by: Jeff Johnson
Signed-off-by: Paul E. McKenney
---
kernel/locking/locktorture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/locking/locktor
From: Jeff Johnson
Fix the 'make W=1' warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/torture.o
Signed-off-by: Jeff Johnson
Signed-off-by: Paul E. McKenney
---
kernel/torture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/torture.c b/kernel/torture.c
index c72
From: Jeff Johnson
Fix the 'make W=1' warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/scftorture.o
Signed-off-by: Jeff Johnson
Signed-off-by: Paul E. McKenney
---
kernel/scftorture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/scftorture.c b/kernel/scftorture.
Hello!
This series provides non-RCU torture-testing updates:
1. Add MODULE_DESCRIPTION(), courtesy of Jeff Johnson.
2. Add MODULE_DESCRIPTION(), courtesy of Jeff Johnson.
3. Add MODULE_DESCRIPTION(), courtesy of Jeff Johnson.
4. Make torture_type static, courtesy of Jeff Jo
On Tue, Jun 04, 2024 at 01:13:25PM +0200, Frederic Weisbecker wrote:
> Le Mon, Jun 03, 2024 at 05:10:54PM -0700, Paul E. McKenney a écrit :
> > On Wed, May 15, 2024 at 02:53:31PM +0200, Frederic Weisbecker wrote:
> > > RCU stall printout fetches the EQS state of a CPU with a preceding full
> > > me
On Fri, May 31, 2024 at 06:02:01PM +0200, Julia Lawall wrote:
> Here are the changes proposed by Coccinelle.
>
> I didn't succeed to compile the powerpc code, but the rest has been
> compile tested.
>
> julia
>
> commit 1881f31fe3ad693d07ecff45985dd0e87534923f
> Author: Julia Lawall
> Date: W
Le Mon, Jun 03, 2024 at 05:10:54PM -0700, Paul E. McKenney a écrit :
> On Wed, May 15, 2024 at 02:53:31PM +0200, Frederic Weisbecker wrote:
> > RCU stall printout fetches the EQS state of a CPU with a preceding full
> > memory barrier. However there is nothing to order this read against at
> > this
For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is
defined as NR_CPUS instead of the number of possible cpus, this
will cause the following system panic:
[0.015349][T0] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
...
[0.021342][T0] setup_percpu: NR_CPUS:512 nr_cpumask_bi
43 matches
Mail list logo
