On Mon, 2011-10-31 at 08:08 -0700, Linus Torvalds wrote: > [ Added a few more people to the cc ] > > On Mon, Oct 31, 2011 at 1:35 AM, Knut Petersen > <Knut_Petersen@xxxxxxxxxxx> wrote: > > After a " rm -r /verybigdir" (about 12G on a 25G reiserfs 3.6partition) > > I found the following report about a circular locking dependency in > > kernel 3.1.0 > > Heh. There is even a comment about the ordering violation: > > /* We use I_MUTEX_CHILD here to silence lockdep. It's safe because xattr > * mutation ops aren't called during rename or splace, which are the > * only other users of I_MUTEX_CHILD. It violates the ordering, but that's > * better than allocating another subclass just for this code. */ > > and apparently the comment is wrong: we *do* end up looking up xattrs > during splice, due to the security_inode_need_killpriv() thing. > > So I think this needs a suid (or sgid) file that has xattrs and is removed. > > That said, I suspect this is a false positive, because the actual > unlink can never happen while somebody is splicing to/from the same > file at the same time (because then the iput wouldn't be the last one > for the inode, and the file removal would be delayed until the file > has been closed for the last time). > > But the hacky use of "I_MUTEX_CHILD" is basically not the proper way > to silence the lockdep splat. > > Anybody? I_MUTEX_XATTR sounds like the right nesting for something called xattr_*() but then, what do I know about filesystems.. Jeff Mahoney wrote this, Jeff any clue? -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
