On 10/19/21 20:52, Jason Gunthorpe wrote:
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
Hi,
On 10/19/21 20:21, Jason Gunthorpe wrote:
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) || pmd_devmap(pmd))) {And vmf_insert_pfn_pmd_prot() unconditionally sets
entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE.
As such gup_huge_pmd() will try to deref a struct page:
head = try_grab_compound_head(pmd_page(orig), refs, flags);
and thus crash.
Prevent this by never using IO memory with vmf_insert_pfn_pud/pmd_prot().
Actually I think if fast gup will break even page backed memory since the backing drivers don't assume anybody else takes a refcount / pincount. Normal pages have PTE_SPECIAL and VM_PFNMAP to block that.
Erk, yes, that is even worse.
(Side note I was recommended to introduce a PTE_HUGESPECIAL bit for this and basically had a patch ready but got scared off when trying to handle 64-bit PTE atomic updates on x86-32)
Right, a PMD_SPECIAL bit is needed to make this work.
Yes, PMD_SPECIAL it was :)
It might be that we (Intel) try to resurrect this code using PTE_HUGESPECIAL in the near future for i915, but until that, I think it's the safest option to disable it completely.
Okay, do you want a patch to just delete this function?
That'd be great.
Thanks,
Thomas
Jason