On Thu, Jan 13, 2011 at 10:09 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Thu, 13 Jan 2011, Nick Piggin wrote: >> > inode = entry->d_inode; >> > if (inode && is_bad_inode(inode)) >> > return 0; >> >> Now it can be the case that entry->d_inode is not stable -- it can >> go away or even flip between inodes in the case of concurrent >> unlink/creat activity. And you may be using a different inode than >> the namei path walk is using! >> This isn't as scary as it sounds actually, because any such changes >> do get detected and the path walk restarted in that case. >> >> You might be OK becuse you do test for NULL (although it really >> wants an ACCESS_ONCE() so it doesn't load a NULL or different >> inodes, but that's quite theoretical). >> >> But this is a little unfriendly for filesystems, and I do want to impress >> the rule to not touch ->d_parent or ->d_inode in rcu walk mode >> (just to avoid any surprises). >> >> So what I have done in such cases is to update the API to provide >> what the callers want. In this case, we could consider adding an >> inode parameter to .d_revalidate, which callers can be sure matches >> the inode used by vfs, and will not change. > > Yes, I think supplying an inode to ->d_revalidate() would be the right > thing. OK I'll work something up. > I see that there's nd->inode, and it's documented in vfs.txt, but IMO > we shouln'd be encouraging new uses of 'nd' inside filesystem > callbacks, rather the opposite. A 'flags' parameter too might make > sense which, for the moment, would only have LOOKUP_RCU instead of all > the lookup flags. I have tried to avoid filesystems poking in nd (except for this case I guess), so yes an inode * parameter should work. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
