linux-kernel - Re: [tree] latest kill-the-BKL tree, v12

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Apr 2009 19:13:45 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Alexander Beregalov <a.beregalov@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-nfs@...r.kernel.org, netdev@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Alessio Igor Bogani <abogani@...ware.it>,
	Jeff Mahoney <jeffm@...e.com>,
	ReiserFS Development List <reiserfs-devel@...r.kernel.org>,
	Chris Mason <chris.mason@...cle.com>
Subject: Re: [tree] latest kill-the-BKL tree, v12

On Thu, 2009-04-16 at 01:07 +0200, Ingo Molnar wrote:
> * Alexander Beregalov <a.beregalov@...il.com> wrote:
> 
> > 2009/4/14 Ingo Molnar <mingo@...e.hu>:
> > >
> > > * Alexander Beregalov <a.beregalov@...il.com> wrote:
> > >
> > >> On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote:
> > >> > Ingo,
> > >> >
> > >> > This small patchset fixes some deadlocks I've faced after trying
> > >> > some pressures with dbench on a reiserfs partition.
> > >> >
> > >> > There is still some work pending such as adding some checks to ensure we
> > >> > _always_ release the lock before sleeping, as you suggested.
> > >> > Also I have to fix a lockdep warning reported by Alessio Igor Bogani.
> > >> > And also some optimizations....
> > >> >
> > >> > Thanks,
> > >> > Frederic.
> > >> >
> > >> > Frederic Weisbecker (3):
> > >> >   kill-the-BKL/reiserfs: provide a tool to lock only once the write lock
> > >> >   kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file
> > >> >   kill-the-BKL/reiserfs: only acquire the write lock once in
> > >> >     reiserfs_dirty_inode
> > >> >
> > >> >  fs/reiserfs/inode.c         |   10 +++++++---
> > >> >  fs/reiserfs/lock.c          |   26 ++++++++++++++++++++++++++
> > >> >  fs/reiserfs/super.c         |   15 +++++++++------
> > >> >  include/linux/reiserfs_fs.h |    2 ++
> > >> >  4 files changed, 44 insertions(+), 9 deletions(-)
> > >> >
> > >>
> > >> Hi
> > >>
> > >> The same test - dbench on reiserfs on loop on sparc64.
> > >>
> > >> [ INFO: possible circular locking dependency detected ]
> > >> 2.6.30-rc1-00457-gb21597d-dirty #2
> > >
> > > I'm wondering ... your version hash suggests you used vanilla
> > > upstream as a base for your test. There's a string of other fixes
> > > from Frederic in tip:core/kill-the-BKL branch, have you picked them
> > > all up when you did your testing?
> > >
> > > The most coherent way to test this would be to pick up the latest
> > > core/kill-the-BKL git tree from:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/kill-the-BKL
> > >
> > 
> > I did not know about this branch, now I am testing it and there is 
> > no more problem with that testcase (dbench).
> > 
> > I will continue testing.
> 
> thanks for testing it! It seems reiserfs with Frederic's changes 
> appears to be more stable now on your system.
> 
> I saw your NFS circular locking kill-the-BKL problem report on LKML 
> - also attached below.
> 
> Hopefully someone on the Cc: list with NFS experience can point out 
> the BKL assumption that is causing this.

I have no idea what Alexander is seeing. There should be no BKL
dependencies at all left in the RPC client code. Most of the NFS client
code is clean too, with only the posix lock code, and the NFSv4 callback
server remaining...

Cheers
  Trond

--
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/