* Matt Fleming <m...@codeblueprint.co.uk> wrote:
> On Mon, 14 Mar, at 11:30:19AM, Ingo Molnar wrote:
> >
> > * Matt Fleming <m...@codeblueprint.co.uk> wrote:
> >
> > > diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> > > index 8fee5b6f8f66..af74849e8c0f 100644
> > > --- a/arch/x86/mm/pageattr.c
> > > +++ b/arch/x86/mm/pageattr.c
> > > @@ -1055,7 +1055,7 @@ static int populate_pud(struct cpa_data *cpa,
> > > unsigned long start, pgd_t *pgd,
> > > /*
> > > * Map everything starting from the Gb boundary, possibly with 1G pages
> > > */
> > > - while (end - start >= PUD_SIZE) {
> > > + while (cpu_has_gbpages && end - start >= PUD_SIZE) {
> > > set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT | _PAGE_PSE |
> > > massage_pgprot(pud_pgprot)));
> >
> > Btw., can 'cpa->pfn << PAGE_SHIFT' possibly work on 32-bit systems?
> >
> > cpa->pfn is unsigned long, so the result gets truncated to 32 bits ...
> >
> > cpa->pfn should be u64.
>
> That is a nice catch.
>
> Note that we never run this code on 32-bit right now. Moving 32-bit to
> this code and away from the old_map scheme is on my TODO list.
There's a number of such occurences that look suspicious:
triton:~/tip> git grep 'cpa->pfn.*<<.*PAGE_SHIFT' arch/x86/
arch/x86/mm/pageattr.c: set_pmd(pmd, __pmd(cpa->pfn << PAGE_SHIFT |
_PAGE_PSE |
arch/x86/mm/pageattr.c: set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT |
_PAGE_PSE |
arch/x86/mm/pageattr.c: unsigned long laddr = (unsigned long)__va(cpa->pfn <<
PAGE_SHIFT);
arch/x86/mm/pageattr.c: unsigned long temp_cpa_vaddr = (cpa->pfn <<
PAGE_SHIFT) +
are you sure none of the code runs on 32-bit?
All this got introduced with:
| commit edc3b9129cecd0f0857112136f5b8b1bc1d45918
| Author: Matt Fleming <m...@codeblueprint.co.uk>
| Date: Fri Nov 27 21:09:31 2015 +0000
|
| x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
AFAICS.
Even if none of this is run on 32-bit, we should really fix it to be u64,
because
the code is really bogus and the fix is easy ...
Thanks,
Ingo
