linux-kernel - Re: [PATCH 02/17] fs: icache lock s

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 17 Oct 2010 04:09:11 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Nick Piggin <npiggin@...nel.dk>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/17] fs: icache lock s_inodes list

On Sat, Oct 16, 2010 at 12:12:10PM -0400, Christoph Hellwig wrote:
> On Sat, Oct 16, 2010 at 06:54:11PM +1100, Nick Piggin wrote:
> > Because in the first part of the inode lock series, it is breaking
> > locks in obvious small steps as possible, by adding global locks
> > protecting bits of what inode_lock used to.
> 
> As seen by Dave's respin making it per-sb was just as easy as making
> it global. And it really is the logical synchronization domain.

If you want it to be scalable within a single sb, it needs to be
per cpu. If it is per-cpu it does not need to be per-sb as well
which just adds bloat.

And the entire idea of the first half of the inode series is that
it starts simple and just uses globals to demonstrate the locking
steps. It's obviously not supposed to be a "production" locking
model so I prefer it to be like that.

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