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  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]
Date:	Mon, 10 Nov 2014 17:58:22 -0500
From:	Jerome Glisse <>
To:	Linus Torvalds <>
Cc:	Andrew Morton <>,
	Linux Kernel Mailing List <>,
	linux-mm <>, Joerg Roedel <>,
	Mel Gorman <>, "H. Peter Anvin" <>,
	Peter Zijlstra <>,
	Andrea Arcangeli <>,
	Johannes Weiner <>,
	Larry Woodman <>,
	Rik van Riel <>,
	Dave Airlie <>,
	Brendan Conoboy <>,
	Joe Donohue <>,
	Duncan Poole <>,
	Sherry Cheung <>,
	Subhash Gutti <>,
	John Hubbard <>,
	Mark Hairgrove <>,
	Lucien Dunning <>,
	Cameron Buschardt <>,
	Arvind Gopalakrishnan <>,
	Shachar Raindel <>,
	Liran Liss <>,
	Roland Dreier <>,
	Ben Sander <>,
	Greg Stoner <>,
	John Bridgman <>,
	Michael Mantor <>,
	Paul Blinzer <>,
	Laurent Morichetti <>,
	Alexander Deucher <>,
	Oded Gabbay <>,
	Jérôme Glisse <>
Subject: Re: [PATCH 3/5] lib: lockless generic and arch independent page
 table (gpt) v2.

On Mon, Nov 10, 2014 at 01:47:01PM -0800, Linus Torvalds wrote:
> On Mon, Nov 10, 2014 at 1:35 PM, Linus Torvalds
> <> wrote:
> >
> > Or do you actually have a setup where actual non-CPU hardware actually
> > walks the page tables you create and call "page tables"?
> So just to clarify: I haven't looked at all your follow-up patches at
> all, although I've seen the overviews in earlier versions. When trying
> to read through the latest version, I got stuck on this one, and felt
> it was crazy.
> But maybe I'm misreading it and it actually has good reasons for it.
> But just from the details I look at, some of it looks too incestuous
> with the system (the split PTL lock use), other parts look really
> really odd (like the 64-bit shift counts), and some of it looks just
> plain buggy (the bitops for synchronization). And none of it is all
> that easy to actually read.

I hope my other emails explained the motivation for all this. The PTL
because update will happen concurrently as CPU page table update and
as CPU page table update i want the same kind of concurrency btw update
to disjoint address.

For 64bit shift and count i explained it is because some hw will have
a 64bit entry format for the page table no matter what arch they are
on (64bit hw page table on x86 32bit page table).

For bitop they are not use for synchronization but as flag inside a
single CPU thread and never share among different thread. This are
not synchronization point.

Sadly no matter how we wish code that is clear in our mind does not
necessarily end up as clear for other and i know the whole macro
things does not make this any easier. As i said the v1 is a non macro
version but it does pre-compute more things inside init and use more
of this precomputed value as parameter for CPU walk down.


>                         Linus
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists