From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Drokin, Oleg" <oleg.drokin@intel.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
"Hammond, John" <john.hammond@intel.com>
Subject: Re: [RFC] lustre treatment of dentry->d_name
Date: Tue, 21 Oct 2014 21:07:42 +0100 [thread overview]
Message-ID: <20141021200742.GU7996@ZenIV.linux.org.uk> (raw)
In-Reply-To: <BCCE2291-C6E5-4FD5-A0A8-D9B3BF5D6F8B@intel.com>
On Tue, Oct 21, 2014 at 03:46:02AM +0000, Drokin, Oleg wrote:
> Hello!
>
> On Oct 20, 2014, at 9:13 PM, Al Viro wrote:
>
> > a) what protects ->d_name in ll_intent_file_open()? It copies
> > ->d_name.name and ->d_name.len into local variables and proceeds to
> > use those; what's to guarantee that dentry won't get hit with d_move()
> > halfway through that? None of the locks that would give an exclusion
> > against d_move() appear to be held…
>
> You are right. We hit something very similar not too long ago.
Umm... While we are at it - what's the story with ll_setxattr() handling
of "trusted.lov"? What happens on the protocol level and why do we need
a file name for that, while for directories we don't seem to need it?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-10-21 20:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 1:13 [RFC] lustre treatment of dentry->d_name Al Viro
2014-10-21 2:55 ` Al Viro
2014-10-21 3:55 ` Drokin, Oleg
2014-10-21 3:46 ` Drokin, Oleg
2014-10-21 4:02 ` Al Viro
2014-10-21 13:34 ` Drokin, Oleg
2014-10-21 21:17 ` Al Viro
2014-10-22 1:48 ` Drokin, Oleg
2014-10-22 2:50 ` Al Viro
2014-10-22 9:30 ` Drokin, Oleg
2014-10-21 19:30 ` Al Viro
2014-10-22 1:49 ` Drokin, Oleg
2014-10-21 20:07 ` Al Viro [this message]
2014-10-22 1:53 ` Drokin, Oleg
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=20141021200742.GU7996@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=andreas.dilger@intel.com \
--cc=john.hammond@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=oleg.drokin@intel.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.