All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [RFC 1/5] net: rtnetlink: Fix incorrect RCU API usage
Date: Wed, 20 Feb 2019 13:08:51 -0500	[thread overview]
Message-ID: <20190220180851.GA97771@google.com> (raw)
In-Reply-To: <20190220164034.GM11787@linux.ibm.com>

On Wed, Feb 20, 2019 at 08:40:34AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 19, 2019 at 11:08:23PM -0500, Joel Fernandes (Google) wrote:
> > From: Joel Fernandes <joel@joelfernandes.org>
> > 
> > rtnl_register_internal() and rtnl_unregister_all tries to directly
> > dereference an RCU protected pointed outside RCU read side section.
> > While this is Ok to do since a lock is held, let us use the correct
> > API to avoid programmer bugs in the future.
> > 
> > This also fixes sparse warnings arising from not using RCU API.
> > 
> > net/core/rtnetlink.c:332:13: warning: incorrect type in assignment
> > (different address spaces) net/core/rtnetlink.c:332:13:    expected
> > struct rtnl_link **tab net/core/rtnetlink.c:332:13:    got struct
> > rtnl_link *[noderef] <asn:4>*<noident>
> > 
> > Signed-off-by: Joel Fernandes <joel@joelfernandes.org>
> 
> First, thank you for doing this!

No problem, it is my pleasure. It is just good to see these warnings/errors
show up (which I didn't anticipate when I first wrote the check) so we can
harden the kernel more fwiw.

> I was going to complain that these were update-side accesses, but it
> looks like rtnl_dereference() already handles both readers and updaters.
> 
> So looks good to me, but the maintainers of course have the final word.

Thanks!
Also my confidence level is a bit less for patches 4/5 and 5/5, could
you share your thoughts on those? The scheduler code seems to use
rcu_assign_pointer() in those where it seems a WRITE_ONCE() would just suffice.
In fact, in some cases I replaced with smp_store_release() just to be safe.
Speaking of which, do you feel those are legit uses of rcu_assign_pointer()
or would you expect rcu_assign_pointer() to be used only for RCU protected
pointers? I am hoping it is the latter since that is what the sparse check
expects (and RCU protected pointer being assigned to).

 - Joel


> 
> > ---
> >  net/core/rtnetlink.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> > index 5ea1bed08ede..98be4b4818a9 100644
> > --- a/net/core/rtnetlink.c
> > +++ b/net/core/rtnetlink.c
> > @@ -188,7 +188,7 @@ static int rtnl_register_internal(struct module *owner,
> >  	msgindex = rtm_msgindex(msgtype);
> >  
> >  	rtnl_lock();
> > -	tab = rtnl_msg_handlers[protocol];
> > +	tab = rtnl_dereference(rtnl_msg_handlers[protocol]);
> >  	if (tab == NULL) {
> >  		tab = kcalloc(RTM_NR_MSGTYPES, sizeof(void *), GFP_KERNEL);
> >  		if (!tab)
> > @@ -329,7 +329,7 @@ void rtnl_unregister_all(int protocol)
> >  	BUG_ON(protocol < 0 || protocol > RTNL_FAMILY_MAX);
> >  
> >  	rtnl_lock();
> > -	tab = rtnl_msg_handlers[protocol];
> > +	tab = rtnl_dereference(rtnl_msg_handlers[protocol]);
> >  	if (!tab) {
> >  		rtnl_unlock();
> >  		return;
> > -- 
> > 2.21.0.rc0.258.g878e2cd30e-goog
> > 
> 

  reply	other threads:[~2019-02-20 18:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20  4:08 [RFC 0/5] RCU fixes for rcu_assign_pointer usage Joel Fernandes (Google)
2019-02-20  4:08 ` [RFC 1/5] net: rtnetlink: Fix incorrect RCU API usage Joel Fernandes (Google)
2019-02-20 16:40   ` Paul E. McKenney
2019-02-20 18:08     ` Joel Fernandes [this message]
2019-02-20  4:08 ` [RFC 2/5] ixgbe: " Joel Fernandes (Google)
2019-02-20  4:08 ` [RFC 3/5] sched/cpufreq: " Joel Fernandes (Google)
2019-02-20  4:08 ` [RFC 4/5] sched/toplogy: Use smp_store_release() instead of rcu_assign_pointer Joel Fernandes (Google)
2019-02-20  4:08 ` [RFC 5/5] rcuwait: Replace rcu_assign_pointer with smp_store_release Joel Fernandes (Google)
2019-02-20  4:11 ` [RFC 0/5] RCU fixes for rcu_assign_pointer usage Joel Fernandes
2019-02-20 16:42   ` Paul E. McKenney
2019-02-20 18:09     ` Joel Fernandes
2019-02-20 18:28       ` Paul E. McKenney
2019-02-21 16:50         ` Joel Fernandes

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=20190220180851.GA97771@google.com \
    --to=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.ibm.com \
    --cc=rcu@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.