From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, mingo@kernel.org, jiangshanlai@gmail.com,
dipankar@in.ibm.com, akpm@linux-foundation.org,
mathieu.desnoyers@efficios.com, josh@joshtriplett.org,
tglx@linutronix.de, dhowells@redhat.com, edumazet@google.com,
fweisbec@gmail.com, oleg@redhat.com
Subject: Re: [PATCH tip/core/rcu 1/3] rcu-tasks: *_ONCE() for rcu_tasks_cbs_head
Date: Tue, 18 Feb 2020 20:13:59 -0500 [thread overview]
Message-ID: <20200219011359.GA29762@google.com> (raw)
In-Reply-To: <20200219001640.GP2935@paulmck-ThinkPad-P72>
On Tue, Feb 18, 2020 at 04:16:40PM -0800, Paul E. McKenney wrote:
> On Tue, Feb 18, 2020 at 07:01:44PM -0500, Joel Fernandes wrote:
> > On Tue, Feb 18, 2020 at 02:54:55PM -0800, Paul E. McKenney wrote:
> > > On Tue, Feb 18, 2020 at 05:45:03PM -0500, Steven Rostedt wrote:
> > > > On Tue, 18 Feb 2020 12:22:26 -0800
> > > > "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > > >
> > > > > On Tue, Feb 18, 2020 at 09:11:42PM +0100, Peter Zijlstra wrote:
> > > > > > On Tue, Feb 18, 2020 at 08:27:19AM -0800, Paul E. McKenney wrote:
> > > > > > > On Tue, Feb 18, 2020 at 08:56:48AM +0100, Peter Zijlstra wrote:
> > > > > >
> > > > > > > > I just took offence at the Changelog wording. It seems to suggest there
> > > > > > > > actually is a problem, there is not.
> > > > > > >
> > > > > > > Quoting the changelog: "Not appropriate for backporting due to failure
> > > > > > > being unlikely."
> > > > > >
> > > > > > That implies there is failure, however unlikely.
> > > > > >
> > > > > > In this particular case there is absolutely no failure, except perhaps
> > > > > > in KCSAN. This patch is a pure annotation such that KCSAN can understand
> > > > > > the code.
> > > > > >
> > > > > > Like said, I don't object to the actual patch, but I do think it is
> > > > > > important to call out false negatives or to describe the actual problem
> > > > > > found.
> > > > >
> > > > > I don't feel at all comfortable declaring that there is absolutely
> > > > > no possibility of failure.
> > > >
> > > > Perhaps wording it like so:
> > > >
> > > > "There's know known issue with the current code, but the *_ONCE()
> > > > annotations here makes KCSAN happy, allowing us to focus on KCSAN
> > > > warnings that can help bring about known issues in other code that we
> > > > can fix, without being distracted by KCSAN warnings that we do not see
> > > > a problem with."
> > > >
> > > > ?
> > >
> > > That sounds more like something I might put in rcutodo.html as a statement
> > > of the RCU approach to KCSAN reports.
> > >
> > > But switching to a different situation (for variety, if nothing else),
> > > what about the commit shown below?
> > >
> > > Thanx, Paul
> > >
> > > ------------------------------------------------------------------------
> > >
> > > commit 35bc02b04a041f32470ae6d959c549bcce8483db
> > > Author: Paul E. McKenney <paulmck@kernel.org>
> > > Date: Tue Feb 18 13:41:02 2020 -0800
> > >
> > > rcutorture: Mark data-race potential for rcu_barrier() test statistics
> > >
> > > The n_barrier_successes, n_barrier_attempts, and
> > > n_rcu_torture_barrier_error variables are updated (without access
> > > markings) by the main rcu_barrier() test kthread, and accessed (also
> > > without access markings) by the rcu_torture_stats() kthread. This of
> > > course can result in KCSAN complaints.
> > >
> > > Because the accesses are in diagnostic prints, this commit uses
> > > data_race() to excuse the diagnostic prints from the data race. If this
> > > were to ever cause bogus statistics prints (for example, due to store
> > > tearing), any misleading information would be disambiguated by the
> > > presence or absence of an rcutorture splat.
> > >
> > > This data race was reported by KCSAN. Not appropriate for backporting
> > > due to failure being unlikely and due to the mild consequences of the
> > > failure, namely a confusing rcutorture console message.
> > >
> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > >
> > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > > index 5453bd5..b3301f3 100644
> > > --- a/kernel/rcu/rcutorture.c
> > > +++ b/kernel/rcu/rcutorture.c
> > > @@ -1444,9 +1444,9 @@ rcu_torture_stats_print(void)
> > > atomic_long_read(&n_rcu_torture_timers));
> > > torture_onoff_stats();
> > > pr_cont("barrier: %ld/%ld:%ld\n",
> > > - n_barrier_successes,
> > > - n_barrier_attempts,
> > > - n_rcu_torture_barrier_error);
> > > + data_race(n_barrier_successes),
> > > + data_race(n_barrier_attempts),
> > > + data_race(n_rcu_torture_barrier_error));
> >
> > Would it be not worth just fixing the data-race within rcutorture itself?
>
> I could use WRITE_ONCE() for updates and READ_ONCE() for statistics.
> However, my current rule is that diagnostic code that is not participating
> in the core synchronization uses data_race(). That way, if I do a typo
> and write to (say) n_barrier_attempts in some other thread, KCSAN will
> know to yell at me.
Oh, ok. That makes sense.
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
thanks,
- Joel
next prev parent reply other threads:[~2020-02-19 1:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-15 0:24 [PATCH tip/core/rcu 0/3] Tasks-RCU updates for v5.7 Paul E. McKenney
2020-02-15 0:25 ` [PATCH tip/core/rcu 1/3] rcu-tasks: *_ONCE() for rcu_tasks_cbs_head paulmck
2020-02-17 12:38 ` Peter Zijlstra
2020-02-17 18:16 ` Paul E. McKenney
2020-02-18 7:56 ` Peter Zijlstra
2020-02-18 16:27 ` Paul E. McKenney
2020-02-18 20:11 ` Peter Zijlstra
2020-02-18 20:22 ` Paul E. McKenney
2020-02-18 22:45 ` Steven Rostedt
2020-02-18 22:54 ` Paul E. McKenney
2020-02-18 23:13 ` Steven Rostedt
2020-02-18 23:54 ` Paul E. McKenney
2020-02-19 0:01 ` Joel Fernandes
2020-02-19 0:16 ` Paul E. McKenney
2020-02-19 1:13 ` Joel Fernandes [this message]
2020-02-19 1:48 ` Paul E. McKenney
2020-02-17 18:23 ` Joel Fernandes
2020-02-17 18:38 ` Marco Elver
2020-02-17 19:32 ` Joel Fernandes
2020-02-15 0:25 ` [PATCH tip/core/rcu 2/3] rcu: Add missing annotation for exit_tasks_rcu_start() paulmck
2020-02-17 14:44 ` Joel Fernandes
2020-02-17 23:10 ` Paul E. McKenney
2020-02-15 0:25 ` [PATCH tip/core/rcu 3/3] rcu: Add missing annotation for exit_tasks_rcu_finish() paulmck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200219011359.GA29762@google.com \
--to=joel@joelfernandes.org \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).