On Fri, May 09, 2025 at 09:18:00AM -0400, Joel Fernandes wrote:
>
>
> On 5/8/2025 7:42 PM, Paul E. McKenney wrote:
> > Hello!
> >
> > This series makes a few small updates to make rcutorture run better
> > on arm64 servers. Remaining issues include TREE07 .con
GP kthread,
> > in which case both ->nocb_cb_kthread and ->nocb_gp_kthread remain
> > NULL.
>
> This is a low probability event, but it is possible, if this happens,
> and we test it with rcutorture configured with parameters
> nocbs_toggle and onoff_interval, it will tr
.
But let's also fix the test while we are at it!
Reported-by: Joel Fernandes
Reported-by: Boqun Feng
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutortu
-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 62f082e24d3b9..2699f47557bf7 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1781,6 +1781,7 @@ rcu_torture_writer(void
d. This suffices because this handler is not a fast path.
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 3c0b686fe..003e549f65141 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -624,10 +624,13 @@ notrace void rcu_p
() to verify that things are going to plan.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 21ff365fca5d9..d94b24f19cf59 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu
-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 0e044afa98d32..21ff365fca5d9 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu
er() after rcu_torture_reader().
5. Print only one rtort_pipe_count splat.
Thanx, Paul
b/kernel/rcu/rcutorture.c | 30
b/too
esses this message when the corresponding
test has been disabled.
Signed-off-by: Paul E. McKenney
---
tools/testing/selftests/rcutorture/bin/torture.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/bin/torture.sh
b/tools/testing
Different architectures capitalize their splats differently. Who knew?
This commit therefore checks for both arm64 "Call trace:" and x86
"Call Trace:".
Reported-by: Joel Fernandes
Closes:
https://lore.kernel.org/all/553c33d8-2b51-4772-8aef-97b0163bc...@nvidia.com/
S
TREE01.
Signed-off-by: Paul E. McKenney
---
tools/testing/selftests/rcutorture/configs/rcu/TREE01 | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE01
b/tools/testing/selftests/rcutorture/configs/rcu/TREE01
index 8ae41d5f81a3e..54b1600c7eb5f
, and eliminates (or at least
greatly reduces) the incidence of RCU CPU stall warnings on arm64.
So this commit therefore sets nr_cpus=17 in TREE01.boot.
Signed-off-by: Paul E. McKenney
---
tools/testing/selftests/rcutorture/configs/rcu/TREE01.boot | 2 +-
1 file changed, 1 insertion(+), 1
7;t let me stand in your way!)
1. Check for "Call trace:" as well as "Call Trace:".
2. Reduce TREE01 CPU overcommit.
3. Remove MAXSMP and CPUMASK_OFFSTACK from TREE01.
cu_organize_nocb_kthreads()).
The rcu_spawn_cpu_nocb_kthread() can fail to spawn the GP kthread,
in which case both ->nocb_cb_kthread and ->nocb_gp_kthread remain
NULL.
If so, LGTM.
Thanx, Paul
> Signed-off-by: Zqiang
> ---
&
ead_lock() in the case where
there was either local_bh_disable() or rcu_read_lock_bh() in effect.
So I would expect that the CONFIG_PREEMPT_RT=y version of both
local_bh_disable() and rcu_read_lock_bh() would contain rcu_read_lock().
And in fact, rcu_read_lock_bh() invokes local_bh_disable(),
On Thu, Apr 24, 2025 at 11:30:39AM +0200, Benjamin Berg wrote:
> On Thu, 2025-04-24 at 11:05 +0200, Sebastian Andrzej Siewior wrote:
> > On 2025-04-23 11:16:49 [-0700], Paul E. McKenney wrote:
> > > On Wed, Apr 23, 2025 at 05:17:31PM +0200, Benjamin Berg wrote:
> > > &g
kernel
with CONFIG_PREEMPT_NONE=y. Not so good for real-time response, but
then again, neither are your debug options.
Thanx, Paul
> > Acked-by: Peter Zijlstra (Intel)
> > Signed-off-by: Sebastian Andrzej Siewior
> > -
On Tue, Apr 22, 2025 at 06:56:17PM -0400, Joel Fernandes wrote:
>
>
> On 4/22/2025 6:55 PM, Joel Fernandes wrote:
> >
> >
> > On 4/22/2025 1:56 PM, Paul E. McKenney wrote:
> >> On Tue, Apr 22, 2025 at 07:38:30PM +0200, Uladzislau Rezki (Sony) wrote:
> &
his is not true, the srcu_read_unlock() can happen on any CPU, but it
> must be performed by the same task that invoked srcu_read_lock().
>
> Signed-off-by: Uladzislau Rezki (Sony)
Good catch!
Reviewed-by: Paul E. McKenney
> ---
> tools/memory-model/Documentation/explanation.t
On Sun, Apr 20, 2025 at 02:40:20AM -, Joel Fernandes wrote:
> Hello, Paul,
>
> On April 20, 2025, 12:21 a.m. UTC Paul E. McKenney wrote:
> > On Wed, Apr 16, 2025 at 11:19:22AM +, Joel Fernandes wrote:
> > >
> > >
> > > > On Apr 15, 2025,
On Wed, Apr 16, 2025 at 11:19:22AM +, Joel Fernandes wrote:
>
>
> > On Apr 15, 2025, at 8:19 PM, Paul E. McKenney wrote:
> >
> > On Mon, Apr 14, 2025 at 11:05:45AM -0400, Joel Fernandes wrote:
> >> On 4/10/2025 2:29 PM, Paul E. McKenney wrote:
> >&
On Sat, Apr 19, 2025 at 06:24:56PM -0400, Joel Fernandes wrote:
> Hi Paul,
>
> On 4/18/2025 6:45 PM, Paul E. McKenney wrote:
> >>>>> Suppose we fired up a guest OS and captured the console output. Is
> >>>>> there
> >>>>> a way
On Fri, Apr 18, 2025 at 10:29:19PM -, Joel Fernandes wrote:
> Hello, Paul,
>
> On Fri, 18 Apr 2025 22:26:17 GMT, "Paul E. McKenney" wrote:
> > On Fri, Apr 18, 2025 at 08:32:46PM +0200, Miguel Ojeda wrote:
> > > On Fri, Apr 18, 2025 at 8:
On Fri, Apr 18, 2025 at 11:20:29PM +0200, Thomas Weißschuh wrote:
> Hi Paul,
>
> On 2025-04-18 10:32:27-0700, Paul E. McKenney wrote:
> > On Wed, Apr 16, 2025 at 08:40:15PM +0200, Thomas Weißschuh wrote:
> > > Fix some issues uncovered by UBSAN and enable UBSAN for no
On Fri, Apr 18, 2025 at 08:32:46PM +0200, Miguel Ojeda wrote:
> On Fri, Apr 18, 2025 at 8:04 PM Paul E. McKenney wrote:
> >
> > Suppose we fired up a guest OS and captured the console output. Is there
> > a way to make that guest OS shut down automatically at the end o
sting
our scripts accordingly.
But, longer term, if there is a better way...
Thanx, Paul
you instead thinking in terms of the v6.16 merge window?
Either works for me, but left to myself, I would assume the v6.16
merge window. ;-)
Thanx, Paul
> ---
> Thomas Weißschuh (6):
> tools/nolibc: add __nolibc_has_feature()
On Tue, Apr 15, 2025 at 09:14:36PM -0400, Joel Fernandes wrote:
>
>
> On 4/15/2025 5:15 PM, Paul E. McKenney wrote:
> > On Tue, Apr 15, 2025 at 10:59:36AM -0700, Paul E. McKenney wrote:
> >> On Tue, Apr 15, 2025 at 01:16:15PM -0400, Joel Fernandes wrote:
> >>&
On Mon, Apr 14, 2025 at 11:05:45AM -0400, Joel Fernandes wrote:
> On 4/10/2025 2:29 PM, Paul E. McKenney wrote:
> >> +static int rcu_gpwrap_lag_init(void)
> >> +{
> >> + if (gpwrap_lag_cycle_mins <= 0 || gpwrap_lag_active_mins <= 0) {
> >> +
On Tue, Apr 15, 2025 at 10:59:36AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 15, 2025 at 01:16:15PM -0400, Joel Fernandes wrote:
> >
> >
> > On 3/31/2025 5:03 PM, Paul E. McKenney wrote:
> > > This commit adds a new rcutorture.n_up_down kernel boot parameter
>
On Tue, Apr 15, 2025 at 01:16:15PM -0400, Joel Fernandes wrote:
>
>
> On 3/31/2025 5:03 PM, Paul E. McKenney wrote:
> > This commit adds a new rcutorture.n_up_down kernel boot parameter
> > that specifies the number of outstanding SRCU up/down readers, which
> > begin
toring strikes again :)
Should us RCU guys be doing something different to make this less of
a problem?
Thanx, Paul
> On a serious note, thanks a lot for doing this! The code is much more
> organized this way IMO.
> I noticed a co
On Mon, Apr 14, 2025 at 10:56:24AM -0400, Joel Fernandes wrote:
> On 4/14/2025 10:24 AM, Paul E. McKenney wrote:
> > On Mon, Apr 14, 2025 at 08:07:24AM -0400, Joel Fernandes wrote:
> >>> On Apr 11, 2025, at 3:18 PM, Paul E. McKenney wrote:
> >>> On Fri, Apr 1
On Mon, Apr 14, 2025 at 08:07:24AM -0400, Joel Fernandes wrote:
>
>
> > On Apr 11, 2025, at 3:18 PM, Paul E. McKenney wrote:
> >
> > On Fri, Apr 11, 2025 at 05:36:32AM -, Joel Fernandes wrote:
> >> Hello, Paul,
> >>
> >>> On F
On Fri, Apr 11, 2025 at 05:36:32AM -, Joel Fernandes wrote:
> Hello, Paul,
>
> On Fri, 11 Apr 2025 05:33:16 GMT, "Paul E. McKenney" wrote:
> > On Thu, Apr 10, 2025 at 11:54:13AM -0700, Paul E. McKenney wrote:
> > > On Thu, Apr 10, 2025 at 11:29:03AM -0700,
erred replacement because
it overcomes the limitations of strncpy mentioned above.
Compile Tested
Signed-off-by: Kevin Paul Reddy Janagari
---
tools/testing/selftests/sync/sync.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/sync/sync.c
b/tools/te
On Thu, Apr 10, 2025 at 11:54:13AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 10, 2025 at 11:29:03AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 10, 2025 at 11:03:27AM -0400, Joel Fernandes wrote: >
> > Currently, the ->gpwrap is not tested (at all per my testing) due to
On Thu, Apr 10, 2025 at 11:29:03AM -0700, Paul E. McKenney wrote:
> On Thu, Apr 10, 2025 at 11:03:27AM -0400, Joel Fernandes wrote: >
> Currently, the ->gpwrap is not tested (at all per my testing) due to
> the > requirement of a large delta between a CPU's rdp->gp_
gt; usecases where ->gpwrap is set.
> > Signed-off-by: Joel Fernandes
Much better, thank you!
One potential nit below. I will run some tests on this version.
Thanx, Paul
> ---
> kernel/rcu/rcu.h| 4 +++
> kernel/r
ecurity_anon(struct inode
> *inode,
> return call_int_hook(inode_init_security_anon, inode, name,
> context_inode);
> }
> +EXPORT_SYMBOL(security_inode_init_security_anon);
>
> #ifdef CONFIG_SECURITY_PATH
> /**
> --
> 2.34.1
--
paul-moore.com
On Tue, Apr 08, 2025 at 06:05:19PM -0400, Joel Fernandes wrote:
>
>
> On 4/8/2025 4:58 PM, Paul E. McKenney wrote:
> > On Tue, Apr 08, 2025 at 08:18:05PM -, Joel Fernandes wrote:
> >> Hello, Paul,
> >>
> >> On Tue, 8 Apr 2025 20:16:08 GMT, "Pa
On Tue, Apr 08, 2025 at 08:18:05PM -, Joel Fernandes wrote:
> Hello, Paul,
>
> On Tue, 8 Apr 2025 20:16:08 GMT, "Paul E. McKenney" wrote:
> > This commit adds a new rcutorture.n_up_down kernel boot parameter
> > that specifies the number of outstanding SRCU up/d
On Tue, Apr 08, 2025 at 02:29:19PM -, Joel Fernandes wrote:
> Hello, Paul,
>
> On Tue, 8 Apr 2025 14:23:32 GMT, "Paul E. McKenney" wrote:
> > The torture.sh --do-rt command-line parameter is intended to mimic -rt
> > kernels. Now that CONFIG_PREEMPT_RT is u
be
possible to make kernels built with CONFIG_PREEMPT_RT=y to tolerate
testing of both, both will be enabled.
[ paulmck: Apply Sebastian Siewior feedback. ]
Signed-off-by: Paul E. McKenney
Cc: Sebastian Andrzej Siewior
---
tools/testing/selftests/rcutorture/bin/torture.sh | 14
On Sat, Apr 05, 2025 at 05:54:00PM +, Joel Fernandes wrote:
> > On Apr 5, 2025, at 1:23 PM, Paul E. McKenney wrote:
> >
> > On Sat, Apr 05, 2025 at 12:30:58PM -, Joel Fernandes wrote:
> >> Hello, Paul,
> >>
> >>> On Sat, 5 Apr 2025 12:2
deprecated.
Signed-off-by: Paul E. McKenney
---
scripts/checkpatch.pl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7b28ad3317427..de8ed5efc5b16 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -838,6 +838,8 @@ our
h, I did get this:
[ 601.891042] gpwraps: 13745
Which seems to indicate some testing. ;-)
Additional comments inline.
Thanx, Paul
> ---
> kernel/rcu/rcu.h| 4 +++
> kernel/rcu/rcutorture.c | 64 +
On Sat, Apr 05, 2025 at 12:30:58PM -, Joel Fernandes wrote:
> Hello, Paul,
>
> On Sat, 5 Apr 2025 12:26:12 GMT, "Paul E. McKenney" wrote:
> > On Sat, Mar 29, 2025 at 07:01:42PM -0400, Joel Fernandes wrote:
> > > Currently, the ->gpwrap is not test
On Sat, Apr 05, 2025 at 07:01:13AM -0400, Joel Fernandes wrote:
>
>
> On 4/2/2025 3:17 PM, Paul E. McKenney wrote:
> > On Wed, Apr 02, 2025 at 12:19:13PM -0400, Joel Fernandes wrote:
> >> Hello,
> >>
> >> On Wed, 2 Apr 2025 16:17:06 GMT, Sebastian Andrze
On Wed, Apr 02, 2025 at 09:42:11AM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-03-31 14:03:06 [-0700], Paul E. McKenney wrote:
> > The torture.sh --do-rt command-line parameter is intended to mimic -rt
> > kernels. Now that CONFIG_PREEMPT_RT is upstream, this commit makes thi
g
"--do-no-kasan --do-no-kcsan --do-no-normal" gets normal runs, so you
should not try to use this as a synonym for --do-none.
Signed-off-by: Paul E. McKenney
---
.../selftests/rcutorture/bin/torture.sh | 30 +--
1 file changed, 27 insertions(+), 3 deletions(-)
diff -
ng in use remain in the
rcu_torture_updown() function.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 46 ++---
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index e7f0521c
e
the user explicitly ask for it?
Co-developed-by: Boqun Feng
Signed-off-by: Boqun Feng
Signed-off-by: Paul E. McKenney
---
.../selftests/rcutorture/bin/torture.sh | 45 +++
1 file changed, 45 insertions(+)
diff --git a/tools/testing/selftests/rcutorture/bin/torture.s
doesn't rcu_torture_fwd_prog_nr() also invoke tick_dep_set_task()
and tick_dep_clear_task()? Because the point of this function is to test
RCU's ability to (eventually) force grace periods forward even when the
tick has been disabled during long CPU-bound kernel execution.
Signed-off-
On Tue, Apr 01, 2025 at 09:49:11PM -0700, Joe Perches wrote:
> On Tue, 2025-04-01 at 21:23 -0700, Paul E. McKenney wrote:
> > On Tue, Apr 01, 2025 at 08:48:44PM -0700, Joe Perches wrote:
> > > On Tue, 2025-04-01 at 07:05 -0700, Paul E. McKenney wrote:
> > > > On M
d-off-by: Uros Bizjak
Fixes: ac053946f5c40 ("compiler.h: introduce TYPEOF_UNQUAL() macro")
Reported-by: Paul Menzel
Closes:
https://lore.kernel.org/lkml/81a25a60-de78-43fb-b56a-131151e1c...@molgen.mpg.de/
Cc: Sami Tolvanen
Cc: Andrew Morton
---
include/linux/compiler.h | 6 +++---
On Wed, Apr 02, 2025 at 12:19:13PM -0400, Joel Fernandes wrote:
> Hello,
>
> On Wed, 2 Apr 2025 16:17:06 GMT, Sebastian Andrzej Siewior wrote:
> > On 2025-03-31 14:03:06 [-0700], Paul E. McKenney wrote:
> > > The torture.sh --do-rt command-line parameter is intended to
On Tue, Apr 01, 2025 at 08:48:44PM -0700, Joe Perches wrote:
> On Tue, 2025-04-01 at 07:05 -0700, Paul E. McKenney wrote:
> > On Mon, Mar 31, 2025 at 11:53:25PM -0700, Joe Perches wrote:
> > > On Mon, 2025-03-31 at 14:03 -0700, Paul E. McKenney wrote:
> > > > Use
On Tue, Apr 01, 2025 at 03:38:21PM +0200, Frederic Weisbecker wrote:
> Le Mon, Mar 31, 2025 at 02:29:52PM -0700, Paul E. McKenney a écrit :
> > The disagreement is a feature, at least up to a point. That feature
> > allows CPUs to go idle for long periods without RCU having to bot
On Mon, Mar 31, 2025 at 11:53:25PM -0700, Joe Perches wrote:
> On Mon, 2025-03-31 at 14:03 -0700, Paul E. McKenney wrote:
> > Uses of srcu_read_lock_lite() and srcu_read_unlock_lite() are better
> > served by the new srcu_read_lock_fast() and srcu_read_unlock_fast()
ents whose readers have ended. This kthread sleeps between one
and two milliseconds between consecutive scans.
[ paulmck: Apply kernel test robot feedback. ]
[ paulmck: Apply Z qiang feedback. ]
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 227 +
be
possible to make kernels built with CONFIG_PREEMPT_RT=y to tolerate
testing of both, both will be enabled.
Signed-off-by: Paul E. McKenney
Cc: Sebastian Andrzej Siewior
---
tools/testing/selftests/rcutorture/bin/torture.sh | 12
1 file changed, 8 insertions(+), 4 deletions
ps://lore.kernel.org/all/4bf081c8-9299-4ee3-b337-d5b751cef6be@paulmck-laptop/
Thanx, Paul
b/kernel/rcu/rcutorture.c| 124 --
On Mon, Mar 31, 2025 at 11:14:10PM +0200, Frederic Weisbecker wrote:
> Le Mon, Mar 31, 2025 at 11:28:47AM -0700, Paul E. McKenney a écrit :
> > > So I'm unfortunately asking again if it wouldn't be a good idea to have a
> > > single
> > > global state cou
.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index ea40f3ad32dc2..d2728e95a69b1 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -2438,6
lockdep enabled.
Signed-off-by: Paul E. McKenney
---
.../testing/selftests/rcutorture/bin/srcu_lockdep.sh | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh
b/tools/testing/selftests/rcutorture/bin
srcu_lockdep.sh.
Signed-off-by: Paul E. McKenney
---
.../selftests/rcutorture/bin/srcu_lockdep.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh
b/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh
index b94f6d3445c6c
moved on. Yes,
the srcu_barrier() at the end of the test will wait for them, but this
could result in confusing states, statistics, and diagnostic information.
So explicitly wait for them before we get to the end-of-test output.
[ paulmck: Apply kernel test robot feedback. ]
Signed-off-by:
The rcu_torture_one_read() function is designed for RCU readers that are
confined to a task, such that a single thread of control extends from the
beginning of a given RCU read-side critical section to its end. This does
not suffice for things like srcu_down_read() and srcu_up_read(), where
the cr
On Mon, Mar 31, 2025 at 12:10:58AM +0200, Frederic Weisbecker wrote:
> Le Thu, Mar 27, 2025 at 10:09:48AM -0700, Paul E. McKenney a écrit :
> > On Wed, Mar 26, 2025 at 10:42:52PM +, Joel Fernandes wrote:
> > >
> > >
> > > > On Mar 26, 2025, at 6:
On Wed, Mar 26, 2025 at 10:42:52PM +, Joel Fernandes wrote:
>
>
> > On Mar 26, 2025, at 6:33 PM, Paul E. McKenney wrote:
> >
> > On Mon, Mar 24, 2025 at 01:01:53PM -0400, Joel Fernandes wrote:
> >> The rcu_seq_done_exact() function checks if a grace perio
On Thu, Mar 27, 2025 at 05:08:35PM +, Joel Fernandes wrote:
>
>
> > On Mar 27, 2025, at 12:48 PM, Paul E. McKenney wrote:
> >
> > On Thu, Mar 27, 2025 at 12:22:12PM -0400, Joel Fernandes wrote:
> >> Paul,
> >>
> >>>> If rtorsu
On Thu, Mar 27, 2025 at 12:22:12PM -0400, Joel Fernandes wrote:
> Paul,
>
> >> If rtorsu_hrt timer is still in timer_queue, invoke hrtimer_cancel() will
> >> remove it from timerqueue and directly return, so the
> >> rcu_torture_updown_hrt()
> >
ere is a new
> > kthread ("rcu_torture_updown") that scans an per-reader array looking
> > for elements whose readers have ended. This kthread sleeps between one
> > and two milliseconds between consecutive scans.
> >
> > [ paulmck: Apply kernel test robot feedback
On Wed, Mar 26, 2025 at 10:50:13PM +, Joel Fernandes wrote:
>
>
> > On Mar 26, 2025, at 6:36 PM, Paul E. McKenney wrote:
> >
> > On Mon, Mar 24, 2025 at 01:01:54PM -0400, Joel Fernandes wrote:
> >> The previous patch improved the rcu_seq_done_exact() fun
; Signed-off-by: Joel Fernandes
This is a good test for the guardband being way too short.
Are there other tests the should be run, possibly on a separate gp_seq
used only for testing? Should the test below be under CONFIG_PROVE_RCU?
Thanx,
is limited to just 2 GPs.
> rcu_seq_done() does not have such strict requirements, however its large
> false-negative window of ULONG_MAX/2 is not ideal for the polling API.
> However, this also means care is needed to ensure the guardband is as
> large as needed to avoid the example sce
e protected from forever-idle CPUs by ->gpwrap), but could be
an issue on 32-bit systems for user of polled RCU grace periods.
In contrast, making the guard band a bit longer than it needs to be
has little or no downside.
Thanx, Paul
>
On Wed, Mar 19, 2025 at 10:42:38AM +0100, Frederic Weisbecker wrote:
> Le Tue, Mar 18, 2025 at 10:22:33AM -0700, Paul E. McKenney a écrit :
> > On Fri, Mar 14, 2025 at 03:36:42PM +0100, Frederic Weisbecker wrote:
> > > A CPU within hotplug operations can make the RCU exp
On Wed, Mar 19, 2025 at 10:01:36AM +0100, Frederic Weisbecker wrote:
> Le Tue, Mar 18, 2025 at 10:18:12AM -0700, Paul E. McKenney a écrit :
> > On Fri, Mar 14, 2025 at 03:36:39PM +0100, Frederic Weisbecker wrote:
> > > A full memory barrier in the RCU-PREEMPT task unblock path a
amp;rcu_state.gp_seq)
> // Two full GP differences
>
> rcu_seq_done_exact(&rnp->gp_seq, snap)
> // rnp->gp_seq = 1
> WRITE_ONCE(rnp->gp_seq, rcu_state.gp_seq);
>
> Add a comment about those expec
On Fri, Mar 14, 2025 at 03:39:05PM +0100, Frederic Weisbecker wrote:
> Le Mon, Mar 03, 2025 at 12:10:50PM -0800, Paul E. McKenney a écrit :
> > On Fri, Feb 14, 2025 at 12:25:59AM +0100, Frederic Weisbecker wrote:
> > > A CPU coming online checks for an ongoing grace period a
lf.
>
> Fix this to make sure related precious informations aren't lost over
> a stall report.
>
> Reported-by: Paul E. McKenney
> Signed-off-by: Frederic Weisbecker
Much better, thank you!
Reviewed-by: Paul E. McKenney
> ---
> kernel/rcu/tree_nocb.h | 3 ++
been online, the ends of any corresponding readers will give up at
the beginning of the first pass of the loop in __rcu_report_exp_rnp().
This is because the ->expmask is guaranteed to be non-zero. (Which is
kind of what you are saying in the last paragraph of your commit log,
just digging
to send an IPI. Therefore the exp kworker can only wait
> until it observes the CPU as officially online.
>
> Such a lag is expected to be very short. However #VMEXIT and other
> hazards can stay on the way. Report long delays, 10 jiffies is
> considered a high threshold already.
what do we do if this assertion triggers? And do we want it to take
effect only in kernels built with CONFIG_PROVE_RCU? Or is such a broken
assumption bad enough to justify a splat in production kernels?
If the answer to the last question is "yes" (and you, not me, work for
a dis
eriod completes.
>
> This makes the explicit barrier in this place superflous. Therefore
> remove it as it is confusing.
>
> Signed-off-by: Frederic Weisbecker
Still cannot see a problem with this, but still a bit nervous.
Acked-by: Paul E. McKenney
> ---
> kernel/
On Thu, Mar 13, 2025 at 05:40:19PM +0100, Frederic Weisbecker wrote:
> Le Fri, Feb 14, 2025 at 01:10:43AM -0800, Paul E. McKenney a écrit :
> > On Fri, Feb 14, 2025 at 12:25:57AM +0100, Frederic Weisbecker wrote:
> > > When a grace period is started, the ->expmask of each node
ay be called from the kernel.
>
> Signed-off-by: Blaise Boscaccy
> Acked-by: Song Liu
> Acked-by: Paul Moore
> ---
> include/linux/lsm_hook_defs.h | 6 +++---
> include/linux/security.h | 12 ++--
> kernel/bpf/sysca
moved on. Yes,
the srcu_barrier() at the end of the test will wait for them, but this
could result in confusing states, statistics, and diagnostic information.
So explicitly wait for them before we get to the end-of-test output.
[ paulmck: Apply kernel test robot feedback. ]
Signed-off-by:
.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 3042a7950fe23..fcdd6271f435c 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -2438,6
lockdep enabled.
Signed-off-by: Paul E. McKenney
---
.../testing/selftests/rcutorture/bin/srcu_lockdep.sh | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh
b/tools/testing/selftests/rcutorture/bin
srcu_lockdep.sh.
Signed-off-by: Paul E. McKenney
---
.../selftests/rcutorture/bin/srcu_lockdep.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh
b/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh
index b94f6d3445c6c
The rcu_torture_one_read() function is designed for RCU readers that are
confined to a task, such that a single thread of control extends from the
beginning of a given RCU read-side critical section to its end. This does
not suffice for things like srcu_down_read() and srcu_up_read(), where
the cr
be
possible to make kernels built with CONFIG_PREEMPT_RT=y to tolerate
testing of both, both will be enabled.
Signed-off-by: Paul E. McKenney
Cc: Sebastian Andrzej Siewior
---
tools/testing/selftests/rcutorture/bin/torture.sh | 12
1 file changed, 8 insertions(+), 4 deletions
ithout matching ->down_read().
Thanx, Paul
b/kernel/rcu/rcutorture.c| 124 --
b/tools/testing/selftests/rcutorture/bin/srcu_lockdep.sh |
doesn't rcu_torture_fwd_prog_nr() also invoke tick_dep_set_task()
and tick_dep_clear_task()? Because the point of this function is to test
RCU's ability to (eventually) force grace periods forward even when the
tick has been disabled during long CPU-bound kernel execution.
Signed-off-
ng in use remain in the
rcu_torture_updown() function.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 46 ++---
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 6afcd33e
ents whose readers have ended. This kthread sleeps between one
and two milliseconds between consecutive scans.
[ paulmck: Apply kernel test robot feedback. ]
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 227
1 file changed, 208 inserti
gt; > this purpose.
> >
> > Cc:
> > Cc: Greg Kroah-Hartman
> > Cc: Keith Busch
> > Closes: https://www.spinics.net/lists/kernel/msg5563270.html
> > Fixes: 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from
> > kmem_cache_destroy()")
1 - 100 of 16681 matches
Mail list logo
