lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 15:00:23 -0500 From: Dave Kleikamp <shaggy@...ux.vnet.ibm.com> To: Krzysztof Helt <krzysztof.h1@...pl> Cc: linux-kernel <linux-kernel@...r.kernel.org>, jfs-discussion@...ts.sourceforge.net Subject: Re: [Jfs-discussion] [PATCH] jfs: lockdep fix On Tue, 2009-10-20 at 20:48 +0200, Krzysztof Helt wrote: > From: Krzysztof Helt <krzysztof.h1@...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. > ========================================================= > [ 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? Thanks, Shaggy > diff --git a/fs/jfs/inode.c b/fs/jfs/inode.c > index b2ae190..de18324 100644 > --- a/fs/jfs/inode.c > +++ b/fs/jfs/inode.c > @@ -244,9 +244,22 @@ int jfs_get_block(struct inode *ip, sector_t lblock, > #ifdef _JFS_4K > if ((rc = extHint(ip, lblock64 << ip->i_sb->s_blocksize_bits, &xad))) > goto unlock; > + > + /* release lock to avoid lockdep with jfs_ip->commit_mutex */ > + if (create) > + IWRITE_UNLOCK(ip); > + else > + IREAD_UNLOCK(ip); > + > rc = extAlloc(ip, xlen, lblock64, &xad, false); > + > if (rc) > - goto unlock; > + return rc; > + > + if (create) > + IWRITE_LOCK(ip, RDWRLOCK_NORMAL); > + else > + IREAD_LOCK(ip, RDWRLOCK_NORMAL); > > set_buffer_new(bh_result); > map_bh(bh_result, ip->i_sb, addressXAD(&xad)); -- David Kleikamp IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists