I don´t know exactly what I was doing at that time - probably I edited a _huge_ image gimp.

> [ Added a few more people to the cc ]>> On Mon, Oct 31, 2011 at 1:35 AM, Knut Petersen> <Knut_Petersen@t-online.de> 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?>> Linus>