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] [day] [month] [year] [list]
Date:	Thu, 28 Aug 2008 11:00:46 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Hugh Dickens <hugh@...itas.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: Definition of x86 _PAGE_SPECIAL and sharing _PAGE_UNUSED1

On Thursday 28 August 2008 10:47, Jeremy Fitzhardinge wrote:
> Nick Piggin wrote:
> > Ah... pity it was hidden away there and not put into the include file.
>
> Yes.  I just prepped a patch to bring it out into the light.
>
> > I don't feel strongly about it. But you should put your definition in
> > pgtable.h (and possibly explain how it coexists with _SPECIAL).
>
> Yes, that was my plan, but without knowing how _SPECIAL is used, it's a
> bit tricky.  Is there a comment somewhere which describes who sets it
> and when?  From a quick look, it seems it's set on newly added user
> pages which aren't COWed.  Can they be shared file-backed pages?
> Anonymous pages?  Device pages?

They'll tend to be device pages. XIP filesystem mappings can set it too.

They won't be set on anonymous pages, or on normally mmap()ed pagecache
pages (although best not to take the latter as a strict rule because
in theory a filesystem _could_ map a pagecache page).


> >> Am I right in supposing that _PAGE_SPECIAL can only be set on user
> >> pages?
> >
> > Yes.
>
> OK, that won't clash with CPA tests at all, since they're kernel only.

Right. But they could nearly have clashed without ever being set on
kernel ptes -- if we ever _tested_ kernel ptes for that bit (gup.c
has other safeguards that should keep us away from kernel pages, but
it could in theory be implemented on x86 by only testing _PTE_SPECIAL
if we know it won't be set on kernel ptes).

But if we just document the fact now that _PTE_SPECIAL is valid for
only user ptes, then I think your CPA test bit fits nicely into the
kernel side and we're no longer wasting half a bit ;)


> >> (Also, "SPECIAL" is awfully generic.  Was there really no more
> >> descriptive name for this?)
> >
> > I thought it was about on par with its counterpart, which is "normal".
> > Either way, I don't think a casual reader would get an adequate idea
> > of how it works in one word. normal ~= refcounted, special ~= !refcounted
> > I guess, but it is slightly more than that and besides, normal was there
> > first, and I think Linus coined it... if you can convince him to change
> > it then you have my blessing to change special into whatever you want.
>
> It's only used in a couple of places, so giving it a longer name
> wouldn't cost much.  _PAGE_USER_UNCOUNTED?  But ugh, a lot of cross-arch
> churnpatch to do it.

And you have to get Linus to accept a patch turning vm_normal_page into
vm_user_counted. Good luck :)

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

Powered by blists - more mailing lists