public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: NeilBrown <neilb@suse.de>,
	Patrick Marlier <patrick.marlier@gmail.com>,
	linux-kernel@vger.kernel.org, mingo@kernel.org,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
	dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com,
	fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com,
	wangyun@linux.vnet.ibm.com
Subject: Re: [PATCH tip/core/rcu 3/4] md/bitmap: Fix list_entry_rcu usage
Date: Tue, 19 May 2015 15:07:25 -0700	[thread overview]
Message-ID: <20150519220725.GA6776@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150518094321.2012a66a@gandalf.local.home>

On Mon, May 18, 2015 at 09:43:21AM -0400, Steven Rostedt wrote:
> On Mon, 18 May 2015 12:06:47 +1000
> NeilBrown <neilb@suse.de> wrote:
> 
> 
> > > struct mddev {
> > > ...
> > > 	struct list_head                disks;
> > > ...}
> > > 
> > > struct list_head {
> > >          struct list_head *next, *prev;
> > > };
> > > 
> > > The tricky thing is that "list_entry_rcu" before and after the patch is 
> > > reading the same thing.
> > 
> > No it isn't.
> > Before the patch it is passed the address of the 'next' field.  After the
> > patch it is passed the contents of the 'next' field.
> 
> Right.
> 
> > 
> > 
> > > 
> > > However in your case, the change I proposed is probably wrong I trust 
> > > you on this side. :) What's your proposal to fix it with the rculist patch?
> > 
> > What needs fixing?  I don't see anything broken.
> > 
> > Maybe there is something in this "rculist patch" that I'm missing.  Can you
> > point me at it?
> > 
> 
> Probably some debugging tool like sparse notices that the assignment
> isn't a true list entry and complains about it. In other words, I think
> the real fix is to fix the debugging tool to ignore this, because the
> code is correct, and this is a false positive failure, and is causing
> more harm than good, because people are sending out broken patches due
> to it.

OK, finally did the history trawling that I should have done to begin with.

Back in 2010, Arnd added the __rcu pointer checking in sparse.
But the RCU list primitives were used on non-RCU-protected lists, so
some casting pain was required to avoid sparse complaints.  (Keep in
mind that the list_head structure does not mark ->next with __rcu.)
Arnd's workaround was to copy the pointer to the local stack, casting
it to an __rcu pointer, then use rcu_dereference_raw() to do the needed
traversal of an RCU-protected pointer.

This of course resulted in an extraneous load from the stack, which
Patrick noticed in his performance work, and which motivated him to send
the patches.

Perhaps what I should do is create an rcu_dereference_nocheck() for use
in list traversals, that omits the sparse checking.  That should get rid
of both the sparse warnings and the strange casts.

The code in md probably needs to change in any case, as otherwise we are
invoking rcu_dereference_whatever() on a full struct list_head rather
than on a single pointer.  Or am I missing something here?

							Thanx, Paul


  reply	other threads:[~2015-05-19 22:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 22:46 [PATCH tip/core/rcu 0/4] RCU-protected list updates for 4.2 Paul E. McKenney
2015-05-12 22:46 ` [PATCH tip/core/rcu 1/4] rculist: Fix another sparse warning Paul E. McKenney
2015-05-12 22:46   ` [PATCH tip/core/rcu 2/4] rculist: Fix list_entry_rcu to read ptr with rcu_dereference_raw Paul E. McKenney
2015-05-12 22:46   ` [PATCH tip/core/rcu 3/4] md/bitmap: Fix list_entry_rcu usage Paul E. McKenney
2015-05-13  2:38     ` Steven Rostedt
2015-05-13  2:58       ` NeilBrown
2015-05-13 13:17         ` Paul E. McKenney
2015-05-16 17:42         ` Patrick Marlier
2015-05-18  2:06           ` NeilBrown
2015-05-18 13:43             ` Steven Rostedt
2015-05-19 22:07               ` Paul E. McKenney [this message]
2015-05-20  5:09                 ` NeilBrown
2015-05-20 13:28                   ` Paul E. McKenney
2015-05-21  0:07                     ` NeilBrown
2015-09-11 23:05                 ` Paul E. McKenney
2015-09-13 10:06                   ` Patrick Marlier
2015-09-13 16:10                     ` Paul E. McKenney
2015-09-22 20:50                       ` Paul E. McKenney
2015-09-23 17:57                         ` Patrick Marlier
2015-09-24  4:45                           ` Paul E. McKenney
2015-05-18 13:53             ` Patrick Marlier
2015-05-18 19:36               ` Patrick Marlier
2015-05-12 22:46   ` [PATCH tip/core/rcu 4/4] netfilter: " Paul E. McKenney
2015-05-13  2:42     ` Steven Rostedt

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=20150519220725.GA6776@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bobby.prani@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhart@linux.intel.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=neilb@suse.de \
    --cc=oleg@redhat.com \
    --cc=patrick.marlier@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=wangyun@linux.vnet.ibm.com \
    /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