* Re: 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 [not found] <20080913233138.GA19576@orion> @ 2008-09-16 2:52 ` Dave Chinner 2008-09-16 4:31 ` Grant Coady 2008-09-16 7:35 ` Alexander Beregalov 0 siblings, 2 replies; 5+ messages in thread From: Dave Chinner @ 2008-09-16 2:52 UTC (permalink / raw) To: Alexander Beregalov; +Cc: rjw, linux-kernel, kernel-testers, linux-fsdevel, xfs On Sun, Sep 14, 2008 at 03:31:38AM +0400, Alexander Beregalov wrote: > Hi > > [ INFO: possible circular locking dependency detected ] > 2.6.27-rc6-00034-gd1c6d2e #3 > ------------------------------------------------------- > nfsd/1766 is trying to acquire lock: > (iprune_mutex){--..}, at: [<c01743fb>] shrink_icache_memory+0x38/0x1a8 > > but task is already holding lock: > (&(&ip->i_iolock)->mr_lock){----}, at: [<c021134f>] > xfs_ilock+0xa2/0xd6 > > > I read files through nfs and saw delay for few seconds. > System is x86_32, nfs, xfs. > The last working kernel is 2.6.27-rc5, > I do not know yet is it reproducible or not. <sigh> We need a FAQ for this one. It's a false positive. Google for an explanation - I've explained it 4 or 5 times in the past year and asked that the lockdep folk invent a special annotation for the iprune_mutex (or memory reclaim) because of the way it can cause recursion into the filesystem and hence invert lock orders without causing deadlocks..... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 2008-09-16 2:52 ` 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 Dave Chinner @ 2008-09-16 4:31 ` Grant Coady 2008-09-16 7:03 ` Dave Chinner 2008-09-16 7:35 ` Alexander Beregalov 1 sibling, 1 reply; 5+ messages in thread From: Grant Coady @ 2008-09-16 4:31 UTC (permalink / raw) To: Dave Chinner Cc: Alexander Beregalov, rjw, linux-kernel, kernel-testers, linux-fsdevel, xfs On Tue, 16 Sep 2008 12:52:04 +1000, Dave Chinner <david@fromorbit.com> wrote: >On Sun, Sep 14, 2008 at 03:31:38AM +0400, Alexander Beregalov wrote: >> Hi >> >> [ INFO: possible circular locking dependency detected ] >> 2.6.27-rc6-00034-gd1c6d2e #3 >> ------------------------------------------------------- >> nfsd/1766 is trying to acquire lock: >> (iprune_mutex){--..}, at: [<c01743fb>] shrink_icache_memory+0x38/0x1a8 >> >> but task is already holding lock: >> (&(&ip->i_iolock)->mr_lock){----}, at: [<c021134f>] >> xfs_ilock+0xa2/0xd6 >> >> >> I read files through nfs and saw delay for few seconds. >> System is x86_32, nfs, xfs. >> The last working kernel is 2.6.27-rc5, >> I do not know yet is it reproducible or not. > ><sigh> > >We need a FAQ for this one. It's a false positive. Google for an >explanation - I've explained it 4 or 5 times in the past year and >asked that the lockdep folk invent a special annotation for the >iprune_mutex (or memory reclaim) because of the way it can cause >recursion into the filesystem and hence invert lock orders without >causing deadlocks..... Yeah, but a 30 second dreadlock? It's a long wait wondering what's gone down or not ;) Grant. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 2008-09-16 4:31 ` Grant Coady @ 2008-09-16 7:03 ` Dave Chinner 0 siblings, 0 replies; 5+ messages in thread From: Dave Chinner @ 2008-09-16 7:03 UTC (permalink / raw) To: Grant Coady Cc: Alexander Beregalov, rjw, linux-kernel, kernel-testers, linux-fsdevel, xfs On Tue, Sep 16, 2008 at 02:31:05PM +1000, Grant Coady wrote: > On Tue, 16 Sep 2008 12:52:04 +1000, Dave Chinner <david@fromorbit.com> wrote: > > >On Sun, Sep 14, 2008 at 03:31:38AM +0400, Alexander Beregalov wrote: > >> Hi > >> > >> [ INFO: possible circular locking dependency detected ] > >> 2.6.27-rc6-00034-gd1c6d2e #3 > >> ------------------------------------------------------- > >> nfsd/1766 is trying to acquire lock: > >> (iprune_mutex){--..}, at: [<c01743fb>] shrink_icache_memory+0x38/0x1a8 > >> > >> but task is already holding lock: > >> (&(&ip->i_iolock)->mr_lock){----}, at: [<c021134f>] > >> xfs_ilock+0xa2/0xd6 > >> > >> > >> I read files through nfs and saw delay for few seconds. > >> System is x86_32, nfs, xfs. > >> The last working kernel is 2.6.27-rc5, > >> I do not know yet is it reproducible or not. > > > ><sigh> > > > >We need a FAQ for this one. It's a false positive. Google for an > >explanation - I've explained it 4 or 5 times in the past year and > >asked that the lockdep folk invent a special annotation for the > >iprune_mutex (or memory reclaim) because of the way it can cause > >recursion into the filesystem and hence invert lock orders without > >causing deadlocks..... > > Yeah, but a 30 second dreadlock? It's a long wait wondering what's > gone down or not ;) The delay will be probably due to how slow the system can be when it runs out of memory, not from the lockdep report. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 2008-09-16 2:52 ` 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 Dave Chinner 2008-09-16 4:31 ` Grant Coady @ 2008-09-16 7:35 ` Alexander Beregalov 2008-09-17 18:33 ` Alexander Beregalov 1 sibling, 1 reply; 5+ messages in thread From: Alexander Beregalov @ 2008-09-16 7:35 UTC (permalink / raw) To: Alexander Beregalov, rjw, linux-kernel, kernel-testers, linux-fsdevel, xfs 2008/9/16 Dave Chinner <david@fromorbit.com>: > On Sun, Sep 14, 2008 at 03:31:38AM +0400, Alexander Beregalov wrote: >> Hi >> >> [ INFO: possible circular locking dependency detected ] >> 2.6.27-rc6-00034-gd1c6d2e #3 >> ------------------------------------------------------- >> nfsd/1766 is trying to acquire lock: >> (iprune_mutex){--..}, at: [<c01743fb>] shrink_icache_memory+0x38/0x1a8 >> >> but task is already holding lock: >> (&(&ip->i_iolock)->mr_lock){----}, at: [<c021134f>] >> xfs_ilock+0xa2/0xd6 >> >> >> I read files through nfs and saw delay for few seconds. >> System is x86_32, nfs, xfs. >> The last working kernel is 2.6.27-rc5, >> I do not know yet is it reproducible or not. > > <sigh> > > We need a FAQ for this one. It's a false positive. Google for an > explanation - I've explained it 4 or 5 times in the past year and > asked that the lockdep folk invent a special annotation for the > iprune_mutex (or memory reclaim) because of the way it can cause > recursion into the filesystem and hence invert lock orders without > causing deadlocks..... Hi Dave Yes, you already explained a similar message to me, but it was a bug, not false positive. http://lkml.org/lkml/2008/7/3/29 http://lkml.org/lkml/2008/7/3/315 I will try to bisect. It is not a OOM case. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 2008-09-16 7:35 ` Alexander Beregalov @ 2008-09-17 18:33 ` Alexander Beregalov 0 siblings, 0 replies; 5+ messages in thread From: Alexander Beregalov @ 2008-09-17 18:33 UTC (permalink / raw) To: Alexander Beregalov, rjw, linux-kernel, kernel-testers, linux-fsdevel, xfs 2008/9/16 Alexander Beregalov <a.beregalov@gmail.com>: > 2008/9/16 Dave Chinner <david@fromorbit.com>: >> On Sun, Sep 14, 2008 at 03:31:38AM +0400, Alexander Beregalov wrote: >>> Hi >>> >>> [ INFO: possible circular locking dependency detected ] >>> 2.6.27-rc6-00034-gd1c6d2e #3 >>> ------------------------------------------------------- >>> nfsd/1766 is trying to acquire lock: >>> (iprune_mutex){--..}, at: [<c01743fb>] shrink_icache_memory+0x38/0x1a8 >>> >>> but task is already holding lock: >>> (&(&ip->i_iolock)->mr_lock){----}, at: [<c021134f>] >>> xfs_ilock+0xa2/0xd6 >>> >>> >>> I read files through nfs and saw delay for few seconds. >>> System is x86_32, nfs, xfs. >>> The last working kernel is 2.6.27-rc5, >>> I do not know yet is it reproducible or not. >> >> <sigh> >> >> We need a FAQ for this one. It's a false positive. Google for an >> explanation - I've explained it 4 or 5 times in the past year and >> asked that the lockdep folk invent a special annotation for the >> iprune_mutex (or memory reclaim) because of the way it can cause >> recursion into the filesystem and hence invert lock orders without >> causing deadlocks..... > > Hi Dave > > Yes, you already explained a similar message to me, but it was a bug, > not false positive. > http://lkml.org/lkml/2008/7/3/29 > http://lkml.org/lkml/2008/7/3/315 > > I will try to bisect. > It is not a OOM case. > I can not reproduce it. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-09-17 18:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20080913233138.GA19576@orion>
2008-09-16 2:52 ` 2.6.27-rc6: lockdep warning: iprune_mutex at shrink_icache_memory+0x38/0x1a8 Dave Chinner
2008-09-16 4:31 ` Grant Coady
2008-09-16 7:03 ` Dave Chinner
2008-09-16 7:35 ` Alexander Beregalov
2008-09-17 18:33 ` Alexander Beregalov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox