Re: [Jfs-discussion] [PATCH] jfs: lockdep fix

["Krzysztof Helt" <krzysztof.h1@wp.pl>]

Dnia 20-10-2009 o godz. 22:00 Dave Kleikamp napisał(a):
> On Tue, 2009-10-20 at 20:48 +0200, Krzysztof Helt wrote:
> > From: Krzysztof Helt <krzysztof.h1@wp.pl>
> > 
> > Release rdwrlock semaphore during memory allocation.
> > This fixes the locked already reported here:
> > 
> > http://www.mail-archive.com/jfs-discussion@lists.sourceforge.net/msg01389.html
> > 
> > The problem here is that memory allocation is done with rdwrlock
> > semaphore taken and the VM can get into the jfs layer taking the
> > rdwrlock again.
> > 
> > Also, the patch fixes the lockdep below. This problem is created because
> > the rdwrlock semaphore acquires the commit_mutex and it is called with
> > interrupts enabled. The interrupt may hit with the commit_mutex taken
> > and take the rdwrlock (again) inside the interrupt context.
> 
> The rdwrlock should never be taken in interrupt context.
> 

Right. It is taken in the RECLAIM_FS context.

> > =========================================================
> > [ INFO: possible irq lock inversion dependency detected ]
> > 2.6.32-rc3 #99
> > ---------------------------------------------------------
> > kswapd0/180 just changed the state of lock:
> >  (&jfs_ip->rdwrlock#2){++++-.}, at: [<c02e2207>] jfs_get_block+0x47/0x280
> > but this lock took another, RECLAIM_FS-unsafe lock in the past:
> >  (&jfs_ip->commit_mutex){+.+.+.}
> > 
> > and interrupts could create inverse lock ordering between them.
> > 
> > 
> > other info that might help us debug this:
> > no locks held by kswapd0/180.
> > 
> > the shortest dependencies between 2nd lock and 1st lock:
> >  -> (&jfs_ip->commit_mutex){+.+.+.} ops: 7937 {
> >     HARDIRQ-ON-W at:
> 
> <snip>
> 
> > ---
> > 
> > I am not sure if this is the right fix to the problem. The heavy use of
> > the jfs volume can lock up a machine (e.g. hit me in Ubuntu 9.04).
> 
> I don't think we can just drop the mutex, since it protects the inode's
> xtree from being modified while another thread is either reading or
> writing it.
> 
> I proposed another fix here:
> http://bugzilla.kernel.org/show_bug.cgi?id=13613
> 
> It seems I haven't followed up and submitted it to the vfs maintainer.
> Could you please give that patch a try and see if it fixes the problem
> for you?
> 

I have tested it a little and I will do some more. At least, there is no 
easy way to trigger the previous lockdep (with rdwrlock only reported to 
the 2.6.30). It seems your fix helps here.

However, I think it does not help with this new lockdep I have reported. 
The new locked is due to the fact that commit_mutex is taken with the 
rdwrlock hold and enabled interrupts. The kswapd may start and create 
the inverse locking order.  The kswapd takes the rdwrlock and some other 
task may hold the commit_mutex. The rdwrlock is taken in jfs_get_block() 
and calls the extAlloc() which takes the commit_mutex. One possible fix 
is to move the commit mutex to the jfs_get_block() before the rdwrlock. 
The extAlloc() is called from the jfs_get_block() only.

Kind regards,
Krzysztof

----------------------------------------------------
WYGRAJ wycieczkę kolejową po północnej Hiszpanii!
http://klik.wp.pl/?adr=http%3A%2F%2Fwww.navigeo.pl%2Fcontest%2Fidea_tour&sid=885