From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] vfs: move ACL cache lookup into generic code
Date: Sat, 23 Jul 2011 07:06:26 +0100 [thread overview]
Message-ID: <20110723060626.GC24703@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20110723043120.GB24703@ZenIV.linux.org.uk>
On Sat, Jul 23, 2011 at 05:31:20AM +0100, Al Viro wrote:
> Heh... In addition to ocfs2 leak: 9p leaks nicely if v9fs_acl_mode() is
> called with !S_ISDIR(mode). In that case acl reference is simply lost.
> So yes, it's worth looking at.
Damn... FWIW, that code is seriously broken and not only on failure exits.
Guys, think what happens if we have a negative dentry and call e.g. mkdir().
Dentry is hashed. Eventually we get to
d_instantiate(dentry, inode);
err = v9fs_fid_add(dentry, fid);
in v9fs_create() (or v9fs_vfs_mkdir_dotl()). At the same time somebody does
lookup *in* that directory. We do find that thing in dcache, it's (already)
positive and we hit
dfid = v9fs_fid_lookup(dentry->d_parent);
at the same time. That calls v9fs_fid_lookup_with_uid() and then
v9fs_fid_add(). Now, we have two tasks doing v9fs_fid_add() on the same
dentry. Which is to say,
dent = dentry->d_fsdata;
if (!dent) {
dent = kmalloc(sizeof(struct v9fs_dentry), GFP_KERNEL);
if (!dent)
return -ENOMEM;
spin_lock_init(&dent->lock);
INIT_LIST_HEAD(&dent->fidlist);
dentry->d_fsdata = dent;
}
and that's an obvious leak. It's not easy to hit, but... Note that
->d_revalidate() does *not* help - v9fs_create() will force revaliation
of parent, but the second process might be already past that point.
Moreover, ->d_revalidate() would just talk to server and return 1, so
even if the second process does hit it, nothing will change except for
minor delay. And the first one might be sleeping in blocking allocation
at that point...
I don't like that; we certainly can protect v9fs_fid_add() in standard way
(i.e. recheck ->d_fsdata after kmalloc(), if we have lost the race - kfree()
and go on, otherwise set ->d_fsdata and make that check+assignment atomic,
e.g. by use of ->d_lock). However, that looks like a kludge. Is there any
saner way to do it? E.g. do we absolutely have to do that *after*
d_instantiate()?
next prev parent reply other threads:[~2011-07-23 6:06 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-22 17:37 VFS pathname walking cleanups (i_op and ACL access) Linus Torvalds
2011-07-22 17:37 ` [PATCH 1/2] VFS: Cut down inode->i_op->xyz accesses in path walking Linus Torvalds
2011-07-22 17:47 ` Christoph Hellwig
2011-07-22 23:40 ` Al Viro
2011-07-22 23:54 ` Linus Torvalds
2011-07-23 3:55 ` [PATCH] " Linus Torvalds
2011-07-23 13:35 ` Christoph Hellwig
2011-07-23 14:46 ` Al Viro
2011-07-23 14:51 ` Christoph Hellwig
2011-07-23 15:45 ` Linus Torvalds
[not found] ` <alpine.LFD.2.02.1107251852220.13796@i5.linux-foundation.org>
2011-07-26 3:05 ` Al Viro
2011-07-26 3:23 ` Linus Torvalds
2011-07-26 18:41 ` Al Viro
2011-07-26 18:45 ` Linus Torvalds
2011-08-07 6:06 ` Linus Torvalds
2011-08-07 6:51 ` Al Viro
2011-08-07 23:43 ` Linus Torvalds
2011-07-22 17:40 ` VFS pathname walking cleanups (i_op and ACL access) Christoph Hellwig
2011-07-22 17:45 ` [PATCH 2/2] vfs: move ACL cache lookup into generic code Linus Torvalds
2011-07-22 17:50 ` Christoph Hellwig
2011-07-22 17:54 ` Linus Torvalds
2011-07-23 2:34 ` [PATCH] " Linus Torvalds
2011-07-23 3:29 ` Al Viro
2011-07-23 3:42 ` Linus Torvalds
2011-07-23 4:31 ` Al Viro
2011-07-23 6:06 ` Al Viro [this message]
2011-07-25 8:15 ` Aneesh Kumar K.V
2011-07-25 8:16 ` Aneesh Kumar K.V
2011-07-23 7:47 ` Al Viro
2011-07-23 14:50 ` Christoph Hellwig
2011-07-23 15:32 ` Al Viro
2011-07-23 17:02 ` Al Viro
2011-07-23 17:31 ` Linus Torvalds
2011-07-23 18:20 ` Al Viro
2011-07-23 18:29 ` Linus Torvalds
2011-07-23 21:53 ` Al Viro
2011-07-23 22:38 ` Al Viro
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=20110723060626.GC24703@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).