[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <be4a252a-f39c-4f9d-8a76-5fc09a158f23@nvidia.com>
Date: Fri, 18 Apr 2025 16:26:56 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: linux-kernel@...r.kernel.org, Davidlohr Bueso <dave@...olabs.net>,
"Paul E. McKenney" <paulmck@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>, Boqun Feng <boqun.feng@...il.com>,
Uladzislau Rezki <urezki@...il.com>, Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>
Cc: rcu@...r.kernel.org, kernel test robot <oliver.sang@...el.com>
Subject: Re: [PATCH 09/14] rcutorture: Check for ->up_read() without matching
->down_read()
On 4/18/2025 12:09 PM, Joel Fernandes wrote:
> From: "Paul E. McKenney" <paulmck@...nel.org>
>
> This commit creates counters in the rcu_torture_one_read_state_updown
> structure that check for a call to ->up_read() that lacks a matching
> call to ->down_read().
>
> While in the area, add end-of-run cleanup code that prevents calls to
> rcu_torture_updown_hrt() from happening after the test has 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. ]
Fyi, I just updated this commit message:
[ joel: Apply Boqun's fix for counter increment ordering. ]
Hope it looks good now [1], thank you Boqun for the fix!
- Joel
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=rcu/for-next&id=fc9e01b94032d2b017925a5f1437532e021bba5d
Powered by blists - more mailing lists