[PATCH] drm/ttm: Do not put non-struct page memory into PUD/PMDs

[Jason Gunthorpe]

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. 

> 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?

Jason