linux-kernel - Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

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: <71d7b63a-45dd-c72d-a277-03124b0053ae@suse.cz>
Date:	Thu, 14 Jul 2016 15:47:00 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Dave Hansen <dave@...1.net>, linux-kernel@...r.kernel.org
Cc:	x86@...nel.org, linux-mm@...ck.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, bp@...en8.de, ak@...ux.intel.com,
	mhocko@...e.com, dave.hansen@...el.com, dave.hansen@...ux.intel.com
Subject: Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

On 07/08/2016 02:19 AM, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@...ux.intel.com>
>
> The page table manipulation code seems to have grown a couple of
> sites that are looking for empty PTEs.  Just in case one of these
> entries got a stray bit set, use pte_none() instead of checking
> for a zero pte_val().
>
> The use pte_same() makes me a bit nervous.  If we were doing a
> pte_same() check against two cleared entries and one of them had
> a stray bit set, it might fail the pte_same() check.  But, I
> don't think we ever _do_ pte_same() for cleared entries.  It is
> almost entirely used for checking for races in fault-in paths.
>
> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>

So, this might be just because I know next to nothing about (para)virt, 
but...

in arch/x86/include/asm/paravirt.h, pte_val is implemented via some 
pvops, which suggests that obtaining a pte value is different than just 
reading it from memory. But I don't see pte_none() defined to be using 
this on paravirt, and it shares (before patch 2/4) the "return !pte.pte" 
implementation, AFAICS?

So that itself is suspicious to me. And now that this patches does 
things like this:

-              if (pte_val(*pte)) {
+              if (!pte_none(*pte)) {

So previously on paravirt these tests would read pte via the pvops, and 
now they won't. Is that OK?

Thanks,
Vlastimil