On Thu, Mar 21, 2013 at 6:22 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > > In theory, we can make vfs_rmdir() and vfs_unlink() check the presense of > the corresponding method before locking the victim; that would suffice to > kludge around that mess on procfs. Along with ->d_inode comparison in > lock_rename() it *might* suffice.
Hmm, yes. Maybe we can do that as a stopgap, backport that, and leave any bigger changes for the development tree. That would make the issue less urgent, never mind all the other worries about backporting complicated patches for subtle issues. I realize you aren't entirely thrilled about it, but we actually already seem to do that check in both vfs_rmdir().and vfs_unlink() before getting the child i_mutex. I wonder if that is because we've already seen lockdep splats for this case... Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/