linux-kernel - [patch 00/14] reworked minimal inode

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-next>] [day] [month] [year] [list]

Date:	Fri, 22 Oct 2010 00:08:29 +1100
From:	npiggin@...nel.dk
To:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	npiggin@...nel.dk
Subject: [patch 00/14] reworked minimal inode_lock breaking series

I am still very much against the locking design of Dave's patchset, but
especially the way it is broken out. I could fathom accepting some of the
i_lock width reduction if they are properly broken out and justified and
documented why they are safe. But lumping this huge series of stuff before
inode_lock is even lifted is not the right way to go about it.

I still maintain that i_lock for icache state lock is the way to go at least
until we get quite a way down the track. I think a lot of people can't see it
maybe because my patchset wasn't broken out terribly well.

So I am posting here just the initial lock breaking part, reworked. In
particular, i_lock coverage is established before adding broken out data
structure locks, but it also cleans things up and attempts not to move stuff
around that isn't strictly required.

I still wait until everything is covered before touching inode_lock, but I have
explained how it is actually possible to start removing some of inode_lock even
before then, which I think is a good demonstration of the power of having full
i_lock coverage.

The steps here should be relatively easy to follow and verify (I hope), and
they lead quite easily to the actual scalability improvement steps. So please
don't get sidetracked on the temporary trylock ugliness!

Thanks,
Nick

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