From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: 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, rostedt@goodmis.org, dhowells@redhat.com,
edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com,
joel@joelfernandes.org
Subject: Re: [PATCH tip/core/rcu 4/4] srcu: Add READ_ONCE() to srcu_struct ->srcu_gp_seq load
Date: Tue, 18 Feb 2020 21:26:44 +0100 [thread overview]
Message-ID: <20200218202644.GG11457@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20200218163405.GF2935@paulmck-ThinkPad-P72>
On Tue, Feb 18, 2020 at 08:34:05AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 18, 2020 at 12:43:34PM +0100, Peter Zijlstra wrote:
> > Well, I didn't get further than the Changelog fails to describe an
> > actual problem and it looks like compare-against-a-constant.
> >
> > (worse, it masks off everything but the 2 lowest bits, so even if there
> > was a problem with load-tearing, it still wouldn't matter)
>
> There is still the possibility of load fusing.
Agreed; that can be an issue. But if so, that then needs to be stated.
> And the possibility
> of defending against possible future changes as well as the current
> snapshot of the code base.
Sure; and like I said, if you want to use READ_ONCE() I'm not going to
argue.
> > I'm not going to argue with you if you want to use READ_ONCE() vs
> > data_race() and a comment to denote false-positive KCSAN warnings, but I
> > do feel somewhat strongly that the Changelog should describe the actual
> > problem -- if there is one -- or just flat out state that this is to
> > make KCSAN shut up but the code is fine.
>
> The problem is that "the code is fine" is highly subjective and varies
> over time. :-/
>
> But in this case there was a real problem, just that I got confused
> when analyzing.
Shit happens :-)
> > That is; every KCSAN report should be analysed, right? All I'm asking is
> > for that analysis to end up in the Changelog.
>
> Before responding further, I have to ask...
>
> Are you intending your "every KCSAN report should be analyzed" to apply
> globally or just when someone creates a patch based on such a report?
Ideally every KCSAN report, but that is a longer term effort. But
specifically, when someone has written a patch, I expect that same
someone to have analysed the code. Then it also makes sense to put that
in the Changelog.
> In any case, you have acked this patch's successor (thank you very
> much!), so on this specific patch (or more accurately, its successor)
> I presume that we are all good.
We are. That new patch describes a clear problem and fixes it.
Anyway, the reaoson I'm being difficuly is partly because on the one
hand I'm just an annoying pendant at times, but also because I've seen
a bunch of, let's say, hasty, KCSAN patches.
next prev parent reply other threads:[~2020-02-18 20:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-15 0:29 [PATCH tip/core/rcu 0/4] SRCU updates for v5.7 Paul E. McKenney
2020-02-15 0:29 ` [PATCH tip/core/rcu 1/4] srcu: Fix __call_srcu()/process_srcu() datarace paulmck
2020-02-17 12:42 ` Peter Zijlstra
2020-02-17 17:01 ` Joel Fernandes
2020-02-17 17:11 ` Peter Zijlstra
2020-02-17 17:46 ` Joel Fernandes
2020-02-17 18:18 ` Paul E. McKenney
2020-02-15 0:29 ` [PATCH tip/core/rcu 2/4] srcu: Fix __call_srcu()/srcu_get_delay() datarace paulmck
2020-02-15 0:29 ` [PATCH tip/core/rcu 3/4] srcu: Fix process_srcu()/srcu_batches_completed() datarace paulmck
2020-02-15 0:29 ` [PATCH tip/core/rcu 4/4] srcu: Add READ_ONCE() to srcu_struct ->srcu_gp_seq load paulmck
2020-02-17 12:45 ` Peter Zijlstra
2020-02-17 18:32 ` Paul E. McKenney
2020-02-17 23:06 ` Paul E. McKenney
2020-02-18 11:46 ` Peter Zijlstra
2020-02-18 21:48 ` Paul E. McKenney
2020-02-18 11:43 ` Peter Zijlstra
2020-02-18 16:34 ` Paul E. McKenney
2020-02-18 20:26 ` Peter Zijlstra [this message]
2020-02-18 21:38 ` Paul E. McKenney
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=20200218202644.GG11457@worktop.programming.kicks-ass.net \
--to=peterz@infradead.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=joel@joelfernandes.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.