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.

Thanks,
Fengguang