Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree

[Matthew Brost <matthew.brost@intel.com>]

On Mon, Aug 03, 2026 at 02:55:45PM +0200, Christian König wrote:
> On 7/21/26 18:55, Matthew Brost wrote:
> > On Mon, Jul 20, 2026 at 03:08:22PM -0700, Matthew Brost wrote:
> >> On Mon, Jul 20, 2026 at 03:46:00PM +0100, Matthew Wilcox wrote:
> >>> On Mon, Jul 20, 2026 at 04:41:41PM +0200, Christoph Hellwig wrote:
> >>>>>   /**
> >>>>>  - * ttm_backup_backup_page() - Backup a page
> >>>>>  + * ttm_backup_backup_folio() - Backup a folio
> >>>>>    * @backup: The struct backup pointer to use.
> >>>>>  - * @page: The page to back up.
> >>>>>  - * @writeback: Whether to perform immediate writeback of the page.
> >>>>>  + * @folio: The folio to back up.
> >>>>>  + * @order: The allocation order of @folio.  Since TTM allocates higher-order
> >>>>>  + *         pages without __GFP_COMP, folio_nr_pages(@folio) would always
> >>>>>  + *         return 1; the caller must pass the true order explicitly.
> >>>
> >>> Wait, what?  This is just broken.  TTM should change to allocate using
> >>> GFP_COMP.  Why can't graphics people ask questions before writing stupid
> >>> patches?
> >>>
> >>
> >> To be honest, I have no idea why TTM doesn't set GFP_COMP. This
> >> predates my work in graphics by nearly a decade.
> 
> Oh, that is a rather long (and sad) story.
> 
> TTM (or GFX HW in general) has the requirement that a page once allocated as huge page must stay a huge page as long as it exists, in other words a page split is not possible.
> 

Right, but I'd take it a step further: pages must remain resident (for
3D workloads) while DMA fences are attached to them (via the BO's
dma_resv).

That's why the pages are neither on the LRU nor rmappable. In other
words, everything is fully managed by TTM and the driver on the graphics
side.

> This is not a problem per see because in theory there should never be a page split required for such allocations because we map everything into userspace using VM_PFNMAP and vmf_insert_pfn_prot(), so the special bit is set we don't have any direct I/O, swapping.....
> 

Yes.

> >>
> >> I found the following comment in TTM, which was added in this patch:
> >> `git format-patch -1 bf9eee249ac20`
> >>
> >> As far as I can tell, setting GFP_COMP would make things a lot easier in
> >> a number of places.
> >>
> >> Christian, who maintains TTM, is out for a couple of weeks, but this is
> >> something we should probably take a closer look at.
> >>
> > 
> > I have looked into this a bit, changing TTM over to allocations with
> > GFP_COMP seems pretty straight forward. I have local patches that are
> > working with my driver (Xe), will post something shortly.
> 
> Well it should work in TTM. The issue was (is?) that we had multiple other components in the kernel who got that completely wrong.
> 

:(

> Especially KVM tried to grab a page reference from walking the page tables, ignoring the special bit in the PTE and then just incrementing the page reference from 0->1 and then later doing a put_page() into the middle of a huge page allocation.
> 

This does sound like a problem and a bit more clear than the comment in
the existing code.

> Long story short that already resulted in multiple CVEs.
> 
> So yeah in theory we could use GFP_COMP here, but we need to make sure that this doesn't break anywhere else.
> 

I haven't tested KVM or audited the entire kernel, so it's entirely
possible that my attempt to use GFP_COMP broke something. :(

It's probably worth investigating if this is still an issue. If it is,
we should at least update the comment in TTM to clearly explain what the
problem is.

Matt

> Regards,
> Christian.
> 
> > 
> > Matt
> > 
> >> Sorry for sending a stupid patch.
> >>
> >> Matt
>