From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pranith Kumar <pranith@gatech.edu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: usage of rcu_dereference_raw
Date: Mon, 21 Apr 2014 15:03:52 -0700 [thread overview]
Message-ID: <20140421220352.GV4496@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJhHMCBrec++R-SOqHhZzNO8jimZWpEy5i-uM4UeLHG9yb-sqw@mail.gmail.com>
On Mon, Apr 21, 2014 at 05:37:01PM -0400, Pranith Kumar wrote:
> Hi Paul,
>
> I was trying to see the various uses of rcu_dereference_ functions to
> understand how they were being used. A doubt cropped up while doing this:
>
> * rcu_dereference_raw(): the documentation explicitly mentions that this
> should be minimally used as this does no checking of read critical sections
> and does not implement barriers. But looking at the code, there are various
> places where this is being used and it is being used I think in a buggy
> way. For example, in drivers/net/wireless/iwlwifi/dvm/main.c, there is this:
>
> kfree(rcu_dereference_raw(priv->noa_data));
>
> I can't imagine a scenario in which this is valid. So my question is this:
> do most of the uses of rcu_dereference_raw() need to be changed to use other
> dereference functions or are there cases where its usage is valid?
Well, the first call to it from iwl_op_mode_dvm_start() is valid because
that field has never been exposed to readers, so that no other task or
CPU has access to this field.
The second call from iwl_op_mode_dvm_stop() -might- be valid. For it
to be valid, there must be a grace period between the time that the
field was made inaccessible to readers and the time that iwl_uninit_drv()
was called. Usually something like synchronize_rcu() waits for the
needed grace period.
Please let me know what you find!
Thanx, Paul
next prev parent reply other threads:[~2014-04-21 22:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 21:37 usage of rcu_dereference_raw Pranith Kumar
2014-04-21 22:03 ` Paul E. McKenney [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-04-21 22:47 Pranith Kumar
2014-04-28 21:13 ` 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=20140421220352.GV4496@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pranith@gatech.edu \
/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.