[lkml]   [2011]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BUG] kernel 3.1.0 possible circular locking dependency detected
    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
    > <> 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?

     \ /
      Last update: 2011-11-07 18:21    [W:0.021 / U:0.184 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site