On Wed, Apr 22, 2015 at 07:07:59PM +0100, Al Viro wrote: > And one more: may_follow_link() is now potentially oopsable. Look: suppose > we've reached the link in RCU mode, just as it got unlinked. link->dentry > has become negative and may_follow_link() steps into > /* Allowed if owner and follower match. */ > inode = link->dentry->d_inode; > if (uid_eq(current_cred()->fsuid, inode->i_uid)) > return 0; > Oops... Incidentally, I suspect that your __read_seqcount_retry() in > follow_link() might be lacking a barrier; why isn't full read_seqcount_retry() > needed? > > FWIW, I would rather fetch ->d_inode *and* checked ->seq proir to calling > get_link(), and passed inode to it as an explicit argument. And passed it > to may_follow_link() as well... Hrm... You know, something really weird is going on here. Where are you setting nd->seq? I don't see anything in follow_link() doing that. And nd->seq _definitely_ needs setting if you want to stay in RCU mode - at that point it matches the dentry of symlink, not that of nd->path (== parent directory). Neil, could you tell me which kernel you'd been testing (ideally - commit ID is a public git tree), what config and what tests had those been? -- 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
