From: Omar Sandoval <osandov@osandov.com>
To: Pranith Kumar <bobby.prani+lkml@gmail.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <jbacik@fb.com>,
Joe Perches <joe@perches.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO
Date: Sun, 30 Nov 2014 19:15:55 -0800 [thread overview]
Message-ID: <20141201031555.GB14040@mew> (raw)
In-Reply-To: <CAJhHMCD6voVEry=CkSyu5FpjiYXzh1aWxNq2_gmxasHqgV+csA@mail.gmail.com>
On Sun, Nov 30, 2014 at 10:11:41AM -0500, Pranith Kumar wrote:
> On Sun, Nov 30, 2014 at 3:26 AM, Omar Sandoval <osandov@osandov.com> wrote:
> > A naked read of the value of an RCU pointer isn't safe. Put the whole access in
> > an RCU critical section, not just the pointer dereference.
> >
> > Signed-off-by: Omar Sandoval <osandov@osandov.com>
>
> You can use rcu_access_pointer() in the if() condition check rather
> than increasing the read critical section. We should try to keep the
> critical section as small as possible.
>
> Also, since we have rcu_str_deref() we can use that instead of
> rcu_dereference() on device->name. Thoughts?
>
That's right, I forgot about rcu_access_pointer. The difference is probably
negligible, and I doubt the performance of this ioctl is very important. Since
we're going to be dereferencing the pointer anyways in some (most?) cases, I
think this is a bit more readable.
--
Omar
next prev parent reply other threads:[~2014-12-01 3:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 8:26 [PATCH 0/3] btrfs: fix RCU string sparse noise Omar Sandoval
2014-11-30 8:26 ` [PATCH 1/3] rcustring: clean up botched __rcu annotations Omar Sandoval
2014-11-30 8:26 ` [PATCH 2/3] btrfs: fix suspicious RCU in BTRFS_IOC_DEV_INFO Omar Sandoval
2014-11-30 15:11 ` Pranith Kumar
2014-12-01 3:15 ` Omar Sandoval [this message]
2014-11-30 8:26 ` [PATCH 3/3] btrfs: refactor btrfs_device->name updates Omar Sandoval
2014-11-30 15:26 ` Pranith Kumar
2014-12-01 2:52 ` Omar Sandoval
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=20141201031555.GB14040@mew \
--to=osandov@osandov.com \
--cc=bobby.prani+lkml@gmail.com \
--cc=clm@fb.com \
--cc=jbacik@fb.com \
--cc=joe@perches.com \
--cc=josh@joshtriplett.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.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.