linux-kernel - Re: Inode Lock Scalability V7 (was V6)

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]

Message-ID: <20101022050112.GA7201@amd>
Date:	Fri, 22 Oct 2010 16:01:12 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Nick Piggin <npiggin@...nel.dk>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Inode Lock Scalability V7 (was V6)

On Fri, Oct 22, 2010 at 03:46:57PM +1100, Nick Piggin wrote:
> The difficulty with inode_lock breaking is not the data structures.
> We know how to lock and modify them. The hardest part is verifying
> that a particular inode has no new, unhandled concurrency introduced
> to it (eg. the particular concurrency you pointed out in Dave's patch
> just now). Agree?
> 
> So in that case, I think it is much more natural to be able to take
> an inode and with i_lock, cover it from all icache state concurrency.
> I object to it being called over engineering -- it's actually just a
> big hammer on the inode, compared with fiddling with more complex
> rules.

And yes, being a big hammer, it is actually ugly and clunky for
the first pass.

The intention is always that we can start steps to streamline it
now. I had been looking at switching lock orders around, reducing
i_lock coverage etc, but I found that with RCU, things got a lot
cleaner without reducing i_lock coverage. With RCU the important
part of the locking shifts back, from the read side, to the write
side. Not surprisingly, this made my lock more natural, wheras it
does nothing for a lock ordering which is the other way around.

And I think you give too little credit to i_lock being used to
protect all i_state. Sure it's not strictly needed, and we could
start breaking bits and pieces. But it works really nicely, and
is maintainable and easier to convince yourself of correctness.

Have an inode? Want to do something to it? Take i_lock. You're
done. We don't _need_ to ever think about concurrent modifications.
Really, this is the "big dumb" approach IMO. Breaking things out
finer than per-inode basis is premature optimisation at this point.
Note that my series never precluded such incremental changes, in
fact it makes them easier.

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