lkml.org 
[lkml]   [2012]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: mq: INFO: possible circular locking dependency detected
    On Wed 08-08-12 15:54:39, Wu Fengguang wrote:
    > On Wed, Aug 08, 2012 at 03:17:38PM +0800, Fengguang Wu wrote:
    > > On Tue, Aug 07, 2012 at 07:39:55AM +0100, Al Viro wrote:
    > > > On Tue, Aug 07, 2012 at 01:04:12PM +0800, Fengguang Wu wrote:
    > > >
    > > > > FYI, here is a different back trace on that commit.
    > > > >
    > > > > [ 3.255043] ======================================================
    > > > > [ 3.255052] [ INFO: possible circular locking dependency detected ]
    > > > > [ 3.255052] 3.5.0-rc6-bisect-00355-geb04c28 #4 Not tainted
    > > > > [ 3.255052] -------------------------------------------------------
    > > > > [ 3.255052] init/1 is trying to acquire lock:
    > > > > [ 3.255052] (&mm->mmap_sem){++++++}, at: [<ffffffff81180d00>] might_fault+0x70/0xe0
    > > > > [ 3.255052]
    > > > > [ 3.255052] but task is already holding lock:
    > > > > [ 3.255052] (&sb->s_type->i_mutex_key){+.+.+.}, at: [<ffffffff811d191e>] vfs_readdir+0x6e/0x130
    > > >
    > > > Do you see any similar with the _next_ commit?
    > >
    > > Stress tests show that the next commit is free from both the "circular
    > > locking dependency" issues.
    >
    > Sorry.. but this still remains for commit 5d37e9e6("fs: Skip atime
    > update on frozen filesystem"):
    >
    > [ 175.588560] [ INFO: possible circular locking dependency detected ]
    > [ 175.588560] 3.5.0-rc6-bisect-00356-g5d37e9e6 #46 Not tainted
    > [ 175.588560] -------------------------------------------------------
    > [ 175.588560] trinity-child0/493 is trying to acquire lock:
    > [ 175.588560] (&sb->s_type->i_mutex_key#14){+.+.+.}, at: [<ffffffff811cc4fe>] vfs_unlink+0x6e/0x1d0
    > [ 175.588560]
    > [ 175.588560] but task is already holding lock:
    > [ 175.588560] (sb_writers#11){.+.+.+}, at: [<ffffffff811e40af>] mnt_want_write+0x2f/0x90
    > [ 175.588560]
    > [ 175.588560] which lock already depends on the new lock.
    OK, this is a theoretical deadlock since mqueue (virtual) filesystem cannot
    really be frozen. But we should convert the mqueue code to deal with new
    lock ordering of i_mutex and mnt_want_write() anyway to make lockdep happy
    if anything... That file somehow escaped my conversion efforts. I'll send a
    fix tomorrow.

    Honza
    --
    Jan Kara <jack@suse.cz>
    SUSE Labs, CR


    \
     
     \ /
      Last update: 2012-08-15 01:03    [W:0.025 / U:209.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site