lockdep annotations?

lockdep annotations?

[Christian Kujau]

Hi,

I try to follow -rc kernels and just upgraded to 2.6.23-rc5 and I still 
see: "INFO: possible circular locking dependency detected". Out of 
curiosity: (when) will these warnings be addressed? I mean, suits me for 
enabling CONFIG_LOCKDEP in the first place, but the only warnings I get 
is still xfs :)

FWIW, full log is here: http://nerdbynature.de/bits/2.6.23-rc5/messages_2.6.23-rc5

Thanks,
Christian.
-- 
BOFH excuse #156:

Zombie processes haunting the computer

Re: lockdep annotations?

[Lachlan McIlroy]

This is a locking inversion between the iolock and iprune_mutex.  I
hadn't seen this one before.  Was your system running low on memory
at the time?

We can't drop the iolock in the write path so we'll have to avoid
acquiring the iolock in xfs_ireclaim() which means we'll need another
way to synchronise with xfs_sync_inodes().

Thanks for pointing this one out.

Lachlan

Christian Kujau wrote:
> Hi,
> 
> I try to follow -rc kernels and just upgraded to 2.6.23-rc5 and I still 
> see: "INFO: possible circular locking dependency detected". Out of 
> curiosity: (when) will these warnings be addressed? I mean, suits me for 
> enabling CONFIG_LOCKDEP in the first place, but the only warnings I get 
> is still xfs :)
> 
> FWIW, full log is here: 
> http://nerdbynature.de/bits/2.6.23-rc5/messages_2.6.23-rc5
> 
> Thanks,
> Christian.

Re: lockdep annotations?

[Christian Kujau]

On Mon, 3 Sep 2007, Lachlan McIlroy wrote:
> This is a locking inversion between the iolock and iprune_mutex.  I
> hadn't seen this one before.  Was your system running low on memory
> at the time?

Usually, this might be the case, as lockdep reports only once and when 
it does it's usually the morning after the last reboot, when a script 
runs the backups (so the box is under load, probably memory pressure 
involved). However, this time I don't remember memory consuming tasks 
running. Unfortunately, I cannot reproduce this yet...

thanks for your explanations,
Christian.
-- 
BOFH excuse #321:

Scheduled global CPU outage

Re: lockdep annotations?

[David Chinner]

On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote:
> This is a locking inversion between the iolock and iprune_mutex.  I
> hadn't seen this one before.  Was your system running low on memory
> at the time?
> 
> We can't drop the iolock in the write path so we'll have to avoid
> acquiring the iolock in xfs_ireclaim() which means we'll need another
> way to synchronise with xfs_sync_inodes().

I don't think a deadlock exists here - we have to be going through
memory reclaim to hit this inversion, so the only place that we
can deadlock is if we are holding the iprune_mutex across a memory
allocation. I don't think we do that....

Not to mention that the inode we hold the iolock on won't be on the
inode free list so we won't ever try to lock it during reclaim, either.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: lockdep annotations?

[Lachlan McIlroy]

David Chinner wrote:
> On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote:
>> This is a locking inversion between the iolock and iprune_mutex.  I
>> hadn't seen this one before.  Was your system running low on memory
>> at the time?
>>
>> We can't drop the iolock in the write path so we'll have to avoid
>> acquiring the iolock in xfs_ireclaim() which means we'll need another
>> way to synchronise with xfs_sync_inodes().
> 
> I don't think a deadlock exists here - we have to be going through
> memory reclaim to hit this inversion, so the only place that we
> can deadlock is if we are holding the iprune_mutex across a memory
> allocation. I don't think we do that....
> 
> Not to mention that the inode we hold the iolock on won't be on the
> inode free list so we won't ever try to lock it during reclaim, either.
> 
Yep.  This is just another case where we've confused lockdep.