Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree
From: Matthew Brost
Date: Tue Jul 21 2026 - 13:08:44 EST
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.
>
> 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.
Matt
> Sorry for sending a stupid patch.
>
> Matt