From: Al Viro <viro@zeniv.linux.org.uk>
To: Josef Bacik <josef@toxicpanda.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"zhengbin (A)" <zhengbin13@huawei.com>, Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
"zhangyi (F)" <yi.zhang@huawei.com>,
renxudong1@huawei.com, Hou Tao <houtao1@huawei.com>,
linux-btrfs@vger.kernel.org, "Yan, Zheng" <zyan@redhat.com>,
linux-cifs@vger.kernel.org, Steve French <sfrench@us.ibm.com>
Subject: Re: [PATCH] Re: Possible FS race condition between iterate_dir and d_alloc_parallel
Date: Tue, 24 Sep 2019 15:51:04 +0100 [thread overview]
Message-ID: <20190924145104.GE26530@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190924133025.jeh7ond2svm3lsub@macbook-pro-91.dhcp.thefacebook.com>
On Tue, Sep 24, 2019 at 09:30:26AM -0400, Josef Bacik wrote:
> > We pass next->d_name.name to dir_emit() (i.e. potentially to
> > copy_to_user()). And we have no warranty that it's not a long
> > (== separately allocated) name, that will be freed while
> > copy_to_user() is in progress. Sure, it'll get an RCU delay
> > before freeing, but that doesn't help us at all.
> >
> > I'm not familiar with those areas in btrfs or cifs; could somebody
> > explain what's going on there and can we indeed end up finding aliases
> > to those suckers?
>
> We can't for the btrfs case. This is used for the case where we have a link to
> a subvolume but the root has disappeared already, so we add in that dummy inode.
> We completely drop the dcache from that root downards when we drop the
> subvolume, so we're not going to find aliases underneath those things. Is that
> what you're asking? Thanks,
Umm... Completely drop, you say? What happens if something had been opened
in there at that time?
Could you give a bit more background? How much of that subvolume remains
and what does btrfs_lookup() have to work with?
next prev parent reply other threads:[~2019-09-24 14:51 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 14:44 Possible FS race condition between iterate_dir and d_alloc_parallel zhengbin (A)
2019-09-03 15:40 ` Al Viro
2019-09-03 15:41 ` Al Viro
2019-09-04 6:15 ` zhengbin (A)
2019-09-05 17:47 ` Al Viro
2019-09-06 0:55 ` Jun Li
2019-09-06 2:00 ` Al Viro
2019-09-06 2:32 ` zhengbin (A)
2019-09-09 14:10 ` zhengbin (A)
2019-09-09 14:59 ` Al Viro
2019-09-09 15:10 ` zhengbin (A)
[not found] ` <7e32cda5-dc89-719d-9651-cf2bd06ae728@huawei.com>
2019-09-10 21:53 ` Al Viro
2019-09-10 22:17 ` Al Viro
2019-09-14 16:16 ` [PATCH] " Al Viro
2019-09-14 16:49 ` Linus Torvalds
2019-09-14 17:01 ` Al Viro
2019-09-14 17:15 ` Linus Torvalds
2019-09-14 20:04 ` Al Viro
2019-09-14 22:57 ` Linus Torvalds
2019-09-15 0:50 ` Al Viro
2019-09-15 1:41 ` Linus Torvalds
2019-09-15 16:02 ` Al Viro
2019-09-15 17:58 ` Linus Torvalds
2019-09-21 14:07 ` Al Viro
2019-09-21 16:21 ` Linus Torvalds
2019-09-21 17:18 ` Al Viro
2019-09-21 17:38 ` Linus Torvalds
2019-09-24 2:52 ` Al Viro
2019-09-24 13:30 ` Josef Bacik
2019-09-24 14:51 ` Al Viro [this message]
2019-09-24 15:01 ` Josef Bacik
2019-09-24 15:11 ` Al Viro
2019-09-24 15:26 ` Josef Bacik
2019-09-24 16:33 ` Al Viro
[not found] ` <CAHk-=wiJ1eY7y6r_cFNRPCqD+BJZS7eJeQFO6OrXxRFjDAipsQ@mail.gmail.com>
2019-09-29 5:29 ` Al Viro
2019-09-25 11:59 ` Amir Goldstein
2019-09-25 12:22 ` Al Viro
2019-09-25 12:34 ` Amir Goldstein
2019-09-22 21:29 ` Al Viro
2019-09-23 3:32 ` zhengbin (A)
2019-09-23 5:08 ` Al Viro
2019-09-16 2:04 ` 266a9a8b41: WARNING:possible_recursive_locking_detected kernel test robot
2019-09-16 2:58 ` Al Viro
2019-09-16 2:58 ` Al Viro
2019-09-16 3:03 ` Al Viro
2019-09-16 3:03 ` Al Viro
2019-09-16 3:44 ` Linus Torvalds
2019-09-16 3:44 ` Linus Torvalds
2019-09-16 17:16 ` Al Viro
2019-09-16 17:16 ` Al Viro
2019-09-16 17:29 ` Al Viro
2019-09-16 17:29 ` Al Viro
2019-09-17 8:59 ` Rong Chen
2019-09-17 7:03 ` zhengbin
2019-09-17 12:01 ` Al Viro
2019-09-17 12:01 ` Al Viro
2019-09-19 3:36 ` zhengbin
2019-09-19 3:36 ` zhengbin (A)
2019-09-19 3:55 ` Al Viro
2019-09-19 3:55 ` Al Viro
2019-09-19 4:16 ` zhengbin
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=20190924145104.GE26530@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=houtao1@huawei.com \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=renxudong1@huawei.com \
--cc=sfrench@us.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=yi.zhang@huawei.com \
--cc=zhengbin13@huawei.com \
--cc=zyan@redhat.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.