Re: [PATCH] mm: vmalloc: make vmalloc_to_page() deal with PMD/PUD mappings

[Dave Hansen <dave.hansen@intel.com>]

On 06/02/2017 08:11 AM, Ard Biesheuvel wrote:
>>> +     pte_t pte = huge_ptep_get((pte_t *)pud);
>>> +
>>> +     if (pte_present(pte))
>>> +             page = pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
>> x86 has pmd/pud_page().  Seems a bit silly to open-code it here.
>>
> So I should replace pud_page() with what exactly?

Whoops, I was reading that wrong.

So, the pud in this case is a huge pud pointing to data.  pud_page()
gives us the head page, but not the base (tail) page.  The 'addr' math
gets us that.

First of all, this math isn't guaranteed to work.  We don't guarantee
virtual contiguity for all mem_map[]s.  I think you need to go to a pfn
or paddr first, add the pud offset, then convert to a 'struct page'.

But, what *is* the right thing to return here?  Do the users here want
the head page or the tail page?

BTW, _are_ your huge vmalloc pages compound?

>>> +#else
>>> +     VIRTUAL_BUG_ON(1);
>>> +#endif
>>> +     return page;
>>> +}
>> So if somebody manages to call this function on a huge page table entry,
>> but doesn't have hugetlbfs configured on, we kill the machine?
> Yes. But only if you have CONFIG_DEBUG_VIRTUAL defined, in which case
> it seems appropriate to signal a failure rather than proceed with
> dereferencing the huge PMD entry as if it were a table entry.

Why kill the machine rather than just warning and returning NULL?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>