On Tue, Sep 24, 2019 at 03:51:04PM +0100, Al Viro wrote: > 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? Sorry I mis-read the code a little bit. This is purely for the subvolume link directories. We haven't wandered down into this directory yet. If the subvolume is being deleted and we still have the fake directory entry for it then we just populate it with this dummy inode and then we can't lookup anything underneath it. Thanks, Josef
