On Wed, 14 Jan 2026 15:51:16 -0800 Matthew Brost [off-list ref] wrote:

On Wed, Jan 14, 2026 at 03:34:21PM -0800, Matthew Brost wrote:

quoted

On Wed, Jan 14, 2026 at 01:48:25PM -0800, Andrew Morton wrote:

quoted

On Wed, 14 Jan 2026 20:19:52 +0100 Francois Dugast [off-list ref] wrote:

quoted

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.

...

s/best to have kernel/best to not have kernels

Great, thanks.  I pasted all the above into the changelog to help
explain our reasons.  I'll retain the patch in mm-hotfixes, targeting
6.19-rcX.  The remainder of the series is DRM stuff, NotMyProblem.  I
assume that getting this into 6.19-rcX is helpful to DRM - if not, and
if taking this via the DRM tree is preferable then let's discuss.

Can reviewers please take a look at this reasonably promptly?


btw, this patch uses

+		struct folio *new_folio = (struct folio *)new_page;

Was page_folio() unsuitable?