linux-kernel - Re: Switching TestSetPageLocked to trylock

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: <200808051409.46083.nickpiggin@yahoo.com.au>
Date:	Tue, 5 Aug 2008 14:09:45 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Switching TestSetPageLocked to trylock_page

On Tuesday 05 August 2008 13:57, Andrew Morton wrote:
> On Tue, 5 Aug 2008 13:41:53 +1000 Nick Piggin <nickpiggin@...oo.com.au> 
wrote:
> > On Tuesday 05 August 2008 13:28, Linus Torvalds wrote:
> > > On Tue, 5 Aug 2008, Nick Piggin wrote:
> > > > On Thursday 31 July 2008 17:26, Nick Piggin wrote:
> > > > > Hi,
> > > > >
> > > > > I'm wondering if I could get a patch merged which changes all
> > > > > TestSetPageLocked and replaces them with trylock_page?
> > > >
> > > > Yes? No?
> > > >
> > > > The alternative is try to merge it via -mm or -next, but that just
> > > > wastes everybodies time with conflicts of having these differences
> > > > between -mm and mainline.
> > >
> > > Heh. I had just been _assuming_ this would go through -mm, since it's
> > > exactly the kind of thing that usually does go through there.
> > >
> > > So I hadn't even really considered it.
> >
> > OK... it just causes Andrew headaches I suspect. But if he prefers
> > to hold onto it for an entire release cycle... Andrew?
>
> Yup.  A mechanical rename-foo-to-bar can be prepared and merged late -
> there's little payback for the pain of maintaining it for a couple of
> months.
>
> Would prefer either that we hold off until after 2.6.27 is released or
> just do it now.
>
> > > I don't mind the patch per se, but can you give some background on what
> > > the pending optimization is that makes such a big difference?
> >
> > Using the lock semantics bitops is the first one. While it is true
> > that we could just hack them into TestSetPageLocked, I really prefer
> > callers to require at least a cursory glance to convert them, and
> > understand that this is a lock lock, and not a test_and_set bitop
> > with full barrier semantics.
>
> This patch wouldn't do anything to ensure that callers get the review
> which you describe, would it?
>
> (and we don't need to patch the code to just read it!)

OK, not it doesn't really ensure that I guess. But it at least helps me
attempt to review callsites and maintainers of external patches hopefully
will get at least some heads up.

Basically it is the best we can do I think. I haven't seen any problems
in this area and I don't really expect to (only in some areas does the
lock implementation itself assume knowledge of barriers beyond regular
lock semantics).

In case something assumes a store won't be passed by TestSetPageLocked,
for example, it should be commented. Code that makes subtle use of
memory ordering and is not commented I think we can say from experience
is almost broken by definition :)

... no, that's not my excuse for introducing breakage.. I have *attempted*
to review callers, but it's not easy to detect uncommented use of barrier.
--
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/