Re: [PATCH v5 1/5] mm/zone_device: Reinitialize large zone device private folios

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

On Wed, Jan 14, 2026 at 01:48:25PM -0800, Andrew Morton wrote:
> On Wed, 14 Jan 2026 20:19:52 +0100 Francois Dugast <francois.dugast@intel.com> wrote:
> 
> > Reinitialize metadata for large zone device private folios in
> > zone_device_page_init prior to creating a higher-order zone device
> > private folio. This step is necessary when the folio’s order changes
> > dynamically between zone_device_page_init calls to avoid building a
> > corrupt folio. As part of the metadata reinitialization, the dev_pagemap
> > must be passed in from the caller because the pgmap stored in the folio
> > page may have been overwritten with a compound head.
> 
> Thanks.  What are the worst-case userspace-visible effects of the bug?

If you reallocate a subset of pages from what was originally a large
device folio, the pgmap mapping becomes invalid because it was
overwritten by the compound head, and this can crash the kernel.

Alternatively, consider the case where the original folio had an order
of 9 and _nr_pages was set. If you then reallocate the folio plus one as
an individual page, the flags would still have PG_locked set, causing a
hang the next time you try to lock the page.

This is pretty bad if drivers implement a buddy allocator for device
pages (Xe does; Nouveau doesn’t, which is why they haven’t hit this
issue). Only Nouveau enables large device pages in 6.19 but probably
best to have kernel flying around with known issues.

Matt