On Wed, Jan 14, 2026 at 03:34:21PM -0800, Matthew Brost wrote: > On Wed, Jan 14, 2026 at 01:48:25PM -0800, Andrew Morton wrote: > > On Wed, 14 Jan 2026 20:19:52 +0100 Francois Dugast > > <[email protected]> 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
s/_nr_pages/the order was encoded the page flags. Not clearing _nr_pages is probably bad too, not sure what the side affect of that is, but it can't be good. > 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. s/best to have kernel/best to not have kernels Matt > > Matt
