All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-sparse <linux-sparse@vger.kernel.org>
Subject: Re: Using sparse to catch invalid RCU dereferences?
Date: Tue, 8 Apr 2008 10:24:36 -0700	[thread overview]
Message-ID: <20080408172436.GE8381@linux.vnet.ibm.com> (raw)
In-Reply-To: <1207670955.5550.15.camel@johannes.berg>

On Tue, Apr 08, 2008 at 06:09:15PM +0200, Johannes Berg wrote:
> 
> > So the address_space attribute says what the pointer points to rather
> > than where the pointer resides, correct?
> 
> Yeah. It's currently used for __user and __iomem. Using it for rcu
> wouldn't be quite the way it was intended, I think, but hey :)

;-)

> > It might be.  There are a number of places where it is legal to access
> > RCU-protected pointers directly, and all of these would need to be
> > changed.  For example, in the example above, one could do:
> > 
> > 	foo = NULL;
> 
> Yeah, all of those would lead to sparse warnings. Are we willing to
> change all that code?

If it found some bugs, I would certainly be in favor!

> > I recently tried to modify rcu_assign_pointer() to issue the memory
> > memory barrier only when the pointer was non-NULL, but this ended badly.
> > Probably because I am not the greatest gcc expert around...  We ended
> > up having to define an rcu_assign_index() to handle the possibility of
> > assigning a zero-value array index, but my attempts to do type-checking
> > backfired, and I eventually gave it up.  Again, someone a bit more clued
> > in to gcc than I am could probably pull it off.
> 
> I don't think I would be that person :)

When it comes to gcc extensions and type-casting trickery, I am not all
that clued in, to be honest...

> > In addition, it is legal to omit rcu_dereference() and rcu_assign_pointer()
> > when holding the update-side lock.
> 
> Right. Those too would lead to problems, unless we change that code to
> use those (or other) macros.

Yep.

> > So I very much like this approach in general, but it will require some
> > care to implement.  I would be very happy to review and comment!!!
> 
> I'll play with it a bit if I get around, was just reviewing some RCU
> usage and had the feeling that it should be possible to automate.

If it finds a few bugs, it would be worth it!

							Thanx, Paul

  reply	other threads:[~2008-04-08 17:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-07 22:04 Using sparse to catch invalid RCU dereferences? Johannes Berg
2008-04-08 15:52 ` Paul E. McKenney
2008-04-08 16:09   ` Johannes Berg
2008-04-08 17:24     ` Paul E. McKenney [this message]
2008-04-09 20:09   ` Johannes Berg
2008-04-10 22:32     ` Paul E. McKenney
2008-04-10 22:32       ` Paul E. McKenney
2008-04-11 20:54       ` Johannes Berg
2008-04-11 18:18   ` Peter Zijlstra
2008-04-11 18:43     ` 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=20080408172436.GE8381@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    /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.