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. -- 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
