linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@lip6.fr>
To: Michal Hocko <mhocko@kernel.org>
Cc: Dave Hansen <dave@sr71.net>,
	linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	bp@alien8.de, ak@linux.intel.com, dave.hansen@intel.com,
	dave.hansen@linux.intel.com
Subject: Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE
Date: Wed, 13 Jul 2016 17:23:27 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1607131722440.2959@hadrien> (raw)
In-Reply-To: <20160713151820.GA20693@dhcp22.suse.cz>



On Wed, 13 Jul 2016, Michal Hocko wrote:

> [CCing Julia]
>
> On Thu 07-07-16 17:19:15, 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().
>
> This looks like something that coccinelle could help with and automate.
> Especially when the patch seems interesting for applying to older kernel
> code streams.
>
> Julia would it be hard to generate a metapatch which would check the
> {pte,pmd}_val() usage in conditions and replace them with {pte,pmd}_none
> equivalents?

Thanks for forwarding.  A priori, it looks quite trivial.  I will do the
obvious thing and send the results for verification.

julia

> > 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>
>
> Other than that looks good to me. Feel free to add
> Acked-by: Michal Hocko <mhocko@suse.com>
>
> > ---
> >
> >  b/arch/x86/mm/init_64.c    |   12 ++++++------
> >  b/arch/x86/mm/pageattr.c   |    2 +-
> >  b/arch/x86/mm/pgtable_32.c |    2 +-
> >  3 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff -puN arch/x86/mm/init_64.c~knl-strays-50-pte_val-cleanups arch/x86/mm/init_64.c
> > --- a/arch/x86/mm/init_64.c~knl-strays-50-pte_val-cleanups	2016-07-07 17:17:44.942808493 -0700
> > +++ b/arch/x86/mm/init_64.c	2016-07-07 17:17:44.949808807 -0700
> > @@ -354,7 +354,7 @@ phys_pte_init(pte_t *pte_page, unsigned
> >  		 * pagetable pages as RO. So assume someone who pre-setup
> >  		 * these mappings are more intelligent.
> >  		 */
> > -		if (pte_val(*pte)) {
> > +		if (!pte_none(*pte)) {
> >  			if (!after_bootmem)
> >  				pages++;
> >  			continue;
> > @@ -396,7 +396,7 @@ phys_pmd_init(pmd_t *pmd_page, unsigned
> >  			continue;
> >  		}
> >
> > -		if (pmd_val(*pmd)) {
> > +		if (!pmd_none(*pmd)) {
> >  			if (!pmd_large(*pmd)) {
> >  				spin_lock(&init_mm.page_table_lock);
> >  				pte = (pte_t *)pmd_page_vaddr(*pmd);
> > @@ -470,7 +470,7 @@ phys_pud_init(pud_t *pud_page, unsigned
> >  			continue;
> >  		}
> >
> > -		if (pud_val(*pud)) {
> > +		if (!pud_none(*pud)) {
> >  			if (!pud_large(*pud)) {
> >  				pmd = pmd_offset(pud, 0);
> >  				last_map_addr = phys_pmd_init(pmd, addr, end,
> > @@ -673,7 +673,7 @@ static void __meminit free_pte_table(pte
> >
> >  	for (i = 0; i < PTRS_PER_PTE; i++) {
> >  		pte = pte_start + i;
> > -		if (pte_val(*pte))
> > +		if (!pte_none(*pte))
> >  			return;
> >  	}
> >
> > @@ -691,7 +691,7 @@ static void __meminit free_pmd_table(pmd
> >
> >  	for (i = 0; i < PTRS_PER_PMD; i++) {
> >  		pmd = pmd_start + i;
> > -		if (pmd_val(*pmd))
> > +		if (!pmd_none(*pmd))
> >  			return;
> >  	}
> >
> > @@ -710,7 +710,7 @@ static bool __meminit free_pud_table(pud
> >
> >  	for (i = 0; i < PTRS_PER_PUD; i++) {
> >  		pud = pud_start + i;
> > -		if (pud_val(*pud))
> > +		if (!pud_none(*pud))
> >  			return false;
> >  	}
> >
> > diff -puN arch/x86/mm/pageattr.c~knl-strays-50-pte_val-cleanups arch/x86/mm/pageattr.c
> > --- a/arch/x86/mm/pageattr.c~knl-strays-50-pte_val-cleanups	2016-07-07 17:17:44.944808582 -0700
> > +++ b/arch/x86/mm/pageattr.c	2016-07-07 17:17:44.950808852 -0700
> > @@ -1185,7 +1185,7 @@ repeat:
> >  		return __cpa_process_fault(cpa, address, primary);
> >
> >  	old_pte = *kpte;
> > -	if (!pte_val(old_pte))
> > +	if (pte_none(old_pte))
> >  		return __cpa_process_fault(cpa, address, primary);
> >
> >  	if (level == PG_LEVEL_4K) {
> > diff -puN arch/x86/mm/pgtable_32.c~knl-strays-50-pte_val-cleanups arch/x86/mm/pgtable_32.c
> > --- a/arch/x86/mm/pgtable_32.c~knl-strays-50-pte_val-cleanups	2016-07-07 17:17:44.946808672 -0700
> > +++ b/arch/x86/mm/pgtable_32.c	2016-07-07 17:17:44.950808852 -0700
> > @@ -47,7 +47,7 @@ void set_pte_vaddr(unsigned long vaddr,
> >  		return;
> >  	}
> >  	pte = pte_offset_kernel(pmd, vaddr);
> > -	if (pte_val(pteval))
> > +	if (!pte_none(pteval))
> >  		set_pte_at(&init_mm, vaddr, pte, pteval);
> >  	else
> >  		pte_clear(&init_mm, vaddr, pte);
> > _
>
> --
> Michal Hocko
> SUSE Labs
>

  reply	other threads:[~2016-07-13 15:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08  0:19 [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum Dave Hansen
2016-07-08  0:19 ` [PATCH 1/4] x86, swap: move swap offset/type up in PTE to work around erratum Dave Hansen
2016-07-13  8:03   ` [tip:x86/mm] x86/mm: Move " tip-bot for Dave Hansen
2016-07-13 15:19   ` [PATCH 1/4] x86, swap: move " Michal Hocko
2016-07-08  0:19 ` [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Dave Hansen
2016-07-13  8:03   ` [tip:x86/mm] x86/mm: Ignore " tip-bot for Dave Hansen
2016-07-13 15:21   ` [PATCH 2/4] x86, pagetable: ignore " Michal Hocko
2016-07-13 15:47     ` Dave Hansen
2016-07-14  6:13       ` Michal Hocko
2016-07-08  0:19 ` [PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum Dave Hansen
2016-07-13  8:04   ` [tip:x86/mm] x86/mm: Disallow " tip-bot for Dave Hansen
2016-07-08  0:19 ` [PATCH 4/4] x86: use pte_none() to test for empty PTE Dave Hansen
2016-07-13  8:04   ` [tip:x86/mm] x86/mm: Use " tip-bot for Dave Hansen
2016-07-13 15:18   ` [PATCH 4/4] x86: use " Michal Hocko
2016-07-13 15:23     ` Julia Lawall [this message]
2016-07-13 15:49     ` Julia Lawall
2016-07-13 16:28       ` Dave Hansen
2016-07-14 13:47   ` Vlastimil Babka
2016-07-14 14:24     ` Dave Hansen
2016-07-14 14:50       ` David Vrabel
2016-07-13  9:54 ` [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum Vlastimil Babka
  -- strict thread matches above, loose matches on Subject: below --
2016-07-01 17:46 Dave Hansen
2016-07-01 17:47 ` [PATCH 4/4] x86: use pte_none() to test for empty PTE Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1607131722440.2959@hadrien \
    --to=julia.lawall@lip6.fr \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).