Re: races in ll_splice_alias() and elsewhere (ext4, ocfs2)

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Mar 10, 2016 at 02:20:42AM +0000, Al Viro wrote:

> Umm...  AFAICS, ext4_d_revalidate() is racy, starting with the very
> first line.  What's to prevent it being moved while we are calling that?
> Lose timeslice on preemption, have mv(1) move it elsewhere, followed by
> rmdir taking the now-empty parent out.  Come back and dir points to
> freed memory, with ci being complete junk.  Looks like oopsen galore...
> Ted, am I missing something subtle here?

BTW, the fact that original parent dentry is pinned by caller doesn't help
at all - by the time we get to ext4_d_revalidate() its ->d_parent might have
been pointing to something we are *not* pinning, with another rename() +
rmdir() completing the problem.  It's going to be hard to hit, but not
impossible.  Have d_move() happen right after we'd found the match in
__d_lookup(), then get preempted just as we'd fetched (already changed)
->d_parent->d_inode in ext4_d_revalidate().  The second rename() + rmdir()
have to complete by the time we regain CPU and we are screwed.