From: David Howells <dhowells@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: dhowells@redhat.com, paulmck@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: memory barrier question
Date: Thu, 16 Sep 2010 15:30:56 +0100 [thread overview]
Message-ID: <6383.1284647456@redhat.com> (raw)
In-Reply-To: <E1OwEjQ-0006wS-MU@pomaz-ex.szeredi.hu>
Miklos Szeredi <miklos@szeredi.hu> wrote:
> Is the rmb() really needed?
>
> Take this code from fs/namei.c for example:
>
> inode = next.dentry->d_inode;
> if (!inode)
> goto out_dput;
>
> if (inode->i_op->follow_link) {
>
> It happily dereferences dentry->d_inode without a barrier after
> checking it for non-null, while that d_inode might have just been
> initialized on another CPU with a freshly created inode. There's
> absolutely no synchornization with that on this side.
Perhaps it's not necessary; once set, how likely is i_op to be changed once
I_NEW is cleared?
> Isn't the fact that we check the pointer for being non-null (together
> with locking/barrier on the other side) enough to ensure that it's
> safe to dereference it?
It's possible that since there's a dependency between the variables on the
reading CPU that the barrier is not required.
I think I have to refer that question to Paul.
David
next prev parent reply other threads:[~2010-09-16 14:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 14:36 memory barrier question Miklos Szeredi
2010-09-15 19:12 ` Rafael J. Wysocki
2010-09-16 11:55 ` David Howells
2010-09-16 13:42 ` Miklos Szeredi
2010-09-16 13:42 ` Miklos Szeredi
2010-09-16 13:42 ` Miklos Szeredi
2010-09-16 14:30 ` David Howells [this message]
2010-09-16 15:03 ` Paul E. McKenney
2010-09-16 16:06 ` Miklos Szeredi
2010-09-16 16:37 ` Paul E. McKenney
2010-09-16 16:56 ` Miklos Szeredi
2010-09-16 17:09 ` James Bottomley
2010-09-16 17:17 ` Miklos Szeredi
2010-09-16 17:40 ` James Bottomley
2010-09-17 21:49 ` Benjamin Herrenschmidt
2010-09-17 23:12 ` Paul E. McKenney
2010-09-19 2:47 ` Benjamin Herrenschmidt
2010-09-19 15:26 ` Paul E. McKenney
2010-09-19 20:15 ` Miklos Szeredi
2010-09-19 21:59 ` Paul E. McKenney
2010-09-20 0:58 ` James Bottomley
2010-09-20 1:29 ` Paul E. McKenney
2010-09-20 16:01 ` Miklos Szeredi
2010-09-20 18:25 ` Paul E. McKenney
2010-09-20 18:25 ` Paul E. McKenney
2010-09-20 18:57 ` Paul E. McKenney
2010-09-20 20:26 ` Michael Cree
2010-09-20 20:40 ` Paul E. McKenney
2010-09-21 14:59 ` Paul E. McKenney
2010-09-22 18:41 ` Paul E. McKenney
2010-09-18 1:12 ` Alan Cox
2010-09-16 16:50 ` Jamie Lokier
2010-09-16 16:18 ` Peter Zijlstra
2010-09-16 16:18 ` Peter Zijlstra
2010-09-16 17:59 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2010-09-20 10:34 George Spelvin
2010-10-29 13:23 Memory " Tetsuo Handa
2010-10-29 15:09 ` Paul E. McKenney
2010-10-30 5:48 ` Tetsuo Handa
2010-10-30 6:11 ` Eric Dumazet
2010-10-30 12:40 ` Tetsuo Handa
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=6383.1284647456@redhat.com \
--to=dhowells@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paulmck@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 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.