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 <[email protected]>
> >
> > Release rdwrlock semaphore during memory allocation.
> > This fixes the locked already reported here:
> >
> > http://www.mail-archive.com/[email protected]/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
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
