All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 4/8] L1TFv8 8
Date: Fri, 29 Jun 2018 14:22:22 +0200	[thread overview]
Message-ID: <20180629122222.GC5963@dhcp22.suse.cz> (raw)
In-Reply-To: <70cd88b9-5417-48a5-d5c9-1bba4b9de91a@suse.cz>

On Thu 28-06-18 10:05:47, speck for Vlastimil Babka wrote:
> On 06/27/2018 05:51 PM, speck for Michal Hocko wrote:
> > Jan Beulich has noticed that these are not correct on 32b PAE systems
> > because phys_addr_t is wider than unsigned long. So we need an explicit
> > cas for pfn_* and use phys_addr_t for other direction. I think we want
> > the following:
> > 
> >>From d3050e2b99e9070defcd990b7bc31a4b433367c5 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.cz>
> > Date: Wed, 27 Jun 2018 17:46:50 +0200
> > Subject: [PATCH] x86/speculation/l1tf: fix up pte->pfn conversion for PAE
> > 
> > Jan has noticed that pte_pfn and co. resp. pfn_pte are incorrect for
> > CONFIG_PAE because phys_addr_t is wider than unsigned long and so the
> > pte_val reps. shift left would get truncated. Fix this up by using
> > proper types.
> > 
> > Noticed-by: Jan Beulich <JBeulich@suse.com>
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> Good catch. Looks good to me, and some basic printk tests on manually
> created and modified pte's confirm that the problem does exist and the
> fix works.
> 
> Acked-by: Vlastimil Babka <vbabka@suse.cz>

Thanks for the review. Btw. could you add
Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation")

if you haven't pushed this yet Thomas?

> 
> > ---
> >  arch/x86/include/asm/pgtable.h | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> > index 6a090a76fdca..26fd42a91946 100644
> > --- a/arch/x86/include/asm/pgtable.h
> > +++ b/arch/x86/include/asm/pgtable.h
> > @@ -191,21 +191,21 @@ static inline u64 protnone_mask(u64 val);
> >  
> >  static inline unsigned long pte_pfn(pte_t pte)
> >  {
> > -	unsigned long pfn = pte_val(pte);
> > +	phys_addr_t pfn = pte_val(pte);
> >  	pfn ^= protnone_mask(pfn);
> >  	return (pfn & PTE_PFN_MASK) >> PAGE_SHIFT;
> >  }
> >  
> >  static inline unsigned long pmd_pfn(pmd_t pmd)
> >  {
> > -	unsigned long pfn = pmd_val(pmd);
> > +	phys_addr_t pfn = pmd_val(pmd);
> >  	pfn ^= protnone_mask(pfn);
> >  	return (pfn & pmd_pfn_mask(pmd)) >> PAGE_SHIFT;
> >  }
> >  
> >  static inline unsigned long pud_pfn(pud_t pud)
> >  {
> > -	unsigned long pfn = pud_val(pud);
> > +	phys_addr_t pfn = pud_val(pud);
> >  	pfn ^= protnone_mask(pfn);
> >  	return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
> >  }
> > @@ -555,7 +555,7 @@ static inline pgprotval_t check_pgprot(pgprot_t pgprot)
> >  
> >  static inline pte_t pfn_pte(unsigned long page_nr, pgprot_t pgprot)
> >  {
> > -	phys_addr_t pfn = page_nr << PAGE_SHIFT;
> > +	phys_addr_t pfn = (phys_addr_t)page_nr << PAGE_SHIFT;
> >  	pfn ^= protnone_mask(pgprot_val(pgprot));
> >  	pfn &= PTE_PFN_MASK;
> >  	return __pte(pfn | check_pgprot(pgprot));
> > @@ -563,7 +563,7 @@ static inline pte_t pfn_pte(unsigned long page_nr, pgprot_t pgprot)
> >  
> >  static inline pmd_t pfn_pmd(unsigned long page_nr, pgprot_t pgprot)
> >  {
> > -	phys_addr_t pfn = page_nr << PAGE_SHIFT;
> > +	phys_addr_t pfn = (phys_addr_t)page_nr << PAGE_SHIFT;
> >  	pfn ^= protnone_mask(pgprot_val(pgprot));
> >  	pfn &= PHYSICAL_PMD_PAGE_MASK;
> >  	return __pmd(pfn | check_pgprot(pgprot));
> > @@ -571,7 +571,7 @@ static inline pmd_t pfn_pmd(unsigned long page_nr, pgprot_t pgprot)
> >  
> >  static inline pud_t pfn_pud(unsigned long page_nr, pgprot_t pgprot)
> >  {
> > -	phys_addr_t pfn = page_nr << PAGE_SHIFT;
> > +	phys_addr_t pfn = (phys_addr_t)page_nr << PAGE_SHIFT;
> >  	pfn ^= protnone_mask(pgprot_val(pgprot));
> >  	pfn &= PHYSICAL_PUD_PAGE_MASK;
> >  	return __pud(pfn | check_pgprot(pgprot));
> > 
> 

-- 
Michal Hocko
SUSE Labs

      reply	other threads:[~2018-06-29 14:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13 22:48 [MODERATED] [PATCH 0/8] L1TFv8 2 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 1/8] L1TFv8 0 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 2/8] L1TFv8 4 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 3/8] L1TFv8 5 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 4/8] L1TFv8 8 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 5/8] L1TFv8 3 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 6/8] L1TFv8 7 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 7/8] L1TFv8 1 Andi Kleen
2018-06-13 22:48 ` [MODERATED] [PATCH 8/8] L1TFv8 6 Andi Kleen
     [not found] ` <20180614150632.E064C61183@crypto-ml.lab.linutronix.de>
2018-06-21  9:02   ` [MODERATED] " Vlastimil Babka
2018-06-21 11:43     ` Vlastimil Babka
2018-06-21 13:17       ` Vlastimil Babka
2018-06-21 14:38         ` Michal Hocko
2018-06-21 14:38         ` Thomas Gleixner
2018-06-21 20:32         ` [MODERATED] " Andi Kleen
2018-06-22 15:46       ` Vlastimil Babka
2018-06-22 16:56         ` Andi Kleen
2018-06-25  7:04           ` Vlastimil Babka
2018-06-25 20:31             ` Andi Kleen
2018-06-26 12:01               ` Vlastimil Babka
2018-06-26 12:57                 ` Michal Hocko
2018-06-26 13:05                   ` Michal Hocko
2018-06-27  9:14                 ` Thomas Gleixner
     [not found] ` <20180613225434.1CDC8610FD@crypto-ml.lab.linutronix.de>
2018-06-27 15:51   ` [MODERATED] Re: x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation Michal Hocko
2018-06-28  8:05     ` [MODERATED] Re: [PATCH 4/8] L1TFv8 8 Vlastimil Babka
2018-06-29 12:22       ` Michal Hocko [this message]

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=20180629122222.GC5963@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=speck@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.