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

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.

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

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

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.

Regards,
Christian.

> 
> Matt
> 
>> Sorry for sending a stupid patch.
>>
>> Matt