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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWhV4n/YgjmmpMWB@lstrano-desk.jf.intel.com>
Date: Wed, 14 Jan 2026 18:50:10 -0800
From: Matthew Brost <matthew.brost@...el.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Francois Dugast <francois.dugast@...el.com>,
	<intel-xe@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>, Zi Yan
	<ziy@...dia.com>, Alistair Popple <apopple@...dia.com>, adhavan Srinivasan
	<maddy@...ux.ibm.com>, Nicholas Piggin <npiggin@...il.com>, Michael Ellerman
	<mpe@...erman.id.au>, "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>,
	Felix Kuehling <Felix.Kuehling@....com>, Alex Deucher
	<alexander.deucher@....com>, Christian König
	<christian.koenig@....com>, David Airlie <airlied@...il.com>, Simona Vetter
	<simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
	Lyude Paul <lyude@...hat.com>, Danilo Krummrich <dakr@...nel.org>, "David
 Hildenbrand" <david@...nel.org>, Oscar Salvador <osalvador@...e.de>, "Jason
 Gunthorpe" <jgg@...pe.ca>, Leon Romanovsky <leon@...nel.org>, Lorenzo Stoakes
	<lorenzo.stoakes@...cle.com>, "Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, "Suren
 Baghdasaryan" <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, "Balbir
 Singh" <balbirs@...dia.com>, <linuxppc-dev@...ts.ozlabs.org>,
	<kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<amd-gfx@...ts.freedesktop.org>, <nouveau@...ts.freedesktop.org>,
	<linux-mm@...ck.org>, <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH v5 1/5] mm/zone_device: Reinitialize large zone device
 private folios

On Wed, Jan 14, 2026 at 06:40:42PM -0800, Andrew Morton wrote:
> On Wed, 14 Jan 2026 15:51:16 -0800 Matthew Brost <matthew.brost@...el.com> wrote:
> 
> > 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 <francois.dugast@...el.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
> > 
> > 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.
> 

I would prefer to take this through DRM since our window for 7.0 closes
earlier than the rest of Linux (typically this Friday), which makes it
easier for me to merge the other four patches and include them in the
next PR. If we can't take it through DRM, I'm sure we can figure
something out - new as a maintainer here, so still figuring out all DRM
flows.

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

The compound head might be pointing somewhere else here, and we are
trying to clear the metadata from new_page up to order << 1. So we
explictly do not want to use page_folio here.

Matt