Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1443468 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE Vlastimil Babka <vbabka@suse.cz> - 2016-07-14 15:50 +0200
    Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE Dave Hansen <dave.hansen@intel.com> - 2016-07-14 16:30 +0200
      Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE David Vrabel <david.vrabel@citrix.com> - 2016-07-14 17:00 +0200

#1443468 — 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@linux.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@linux.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

[toc] | [next] | [standalone]

#1443484

On 07/14/2016 06:47 AM, Vlastimil Babka wrote:
> 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?

I've cc'd a few Xen guys.  I think they're the only ones that would care.

But, as far as I can tell, the Xen pte_val() will take a _PAGE_PRESENT
PTE and muck with it.  But its answer will never differ for an all 0 PTE
from !pte_none() because that PTE does not have _PAGE_PRESENT set.

It does seem fragile that Xen is doing it this way, but I guess it works.

[toc] | [prev] | [next] | [standalone]

#1443502

On 14/07/16 15:24, Dave Hansen wrote:
> On 07/14/2016 06:47 AM, Vlastimil Babka wrote:
>> 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?
> 
> I've cc'd a few Xen guys.  I think they're the only ones that would care.
> 
> But, as far as I can tell, the Xen pte_val() will take a _PAGE_PRESENT
> PTE and muck with it.  But its answer will never differ for an all 0 PTE
> from !pte_none() because that PTE does not have _PAGE_PRESENT set.
> 
> It does seem fragile that Xen is doing it this way, but I guess it works.

Xen PV guests never plays games with non-present PTEs so, for the
series, wrt Xen:

Acked-by: David Vrabel <david.vrabel@citrix.com>

FWIW, present PTEs have a hardware-specified meaning where-as
non-present PTEs do not, so I'm not sure I'd view Xen PV guests making
this distinct as "fragile".


David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web