linux-kernel - Re: [PATCH 08/14] inode: move to per-sb LRU locks

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]

Message-ID: <20110712003403.GH23038@dastard>
Date:	Tue, 12 Jul 2011 10:34:03 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	viro@...IV.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 08/14] inode: move to per-sb LRU locks

On Mon, Jul 11, 2011 at 03:21:44PM -0400, Christoph Hellwig wrote:
> On Fri, Jul 08, 2011 at 02:14:40PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@...hat.com>
> > 
> > With the inode LRUs moving to per-sb structures, there is no longer
> > a need for a global inode_lru_lock. The locking can be made more
> > fine-grained by moving to a per-sb LRU lock, isolating the LRU
> > operations of different filesytsems completely from each other.
> 
> Btw, any reason this is not done for dcache_lru_lock?

I have a patch that does exactly that, but it causes random crashes
and oopsen in the dentry code due to corrupted lists and dentries
when running xfstests. Like the inode cache, it is a simple
translation of dcache_lru_lock to sb->s_dentry_lru_lock, so it
should not be changing what is protected by the LRU lock.

The patch used to work fine before the massive locking rework of the
dentry cache, so it appears that there is now something unknown that
dcache_lru_lock is implicitly protecting.  However, the locking is
now so complex I've been unable to debug the problems caused by the
patch, so I simply dropped the patch.

I might try again later to break up the dcache_lru_lock, but right
now it's not showing up as a badly contended lock in my tests and
I've got other things that are more important to do, so I've been
ignoring the problem....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/