linux-kernel - Re: [PATCH 1/2] kho: add support for preserving vmalloc allocations

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] [day] [month] [year] [list]

Message-ID: <aMgbYrYwxKjiW6Pd@kernel.org>
Date: Mon, 15 Sep 2025 16:57:54 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Graf <graf@...zon.com>, Baoquan He <bhe@...hat.com>,
	Changyuan Lyu <changyuanl@...gle.com>, Chris Li <chrisl@...nel.org>,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	Pratyush Yadav <pratyush@...nel.org>, kexec@...ts.infradead.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] kho: add support for preserving vmalloc allocations

On Thu, Sep 04, 2025 at 09:30:32AM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 03, 2025 at 10:25:02PM +0300, Mike Rapoport wrote:
> 
> > It seems that our major disagreement is about using 'folio' vs 'page' in
> > the naming.
> 
> It is a folio because folio is the name for something that is a high
> order page and it signals that the pointer is the head page. Which is
> excatly what KHO preservation works on.

kmalloc_large() and vmalloc(VMAP_HUGE) are not folios and won't be.
 
> I don't know what the next step is when folio is split - presumably we
> will get a new type to represent an abstract memdesc head of a high
> order allocation that the lowest KHO primitives will change over to.
> 
> > I'd rather stick to the good old 'page' and when the time comes we can
> > 's/page/memdesc/g' supposing Matthew actually plans for it.
> 
> I think you should just convert from the vmap page to folio for now
> and most likely vmap will stop using page someday..

This is wrong. vmalloc is not a folio and according to memdesc plan [1] it
will be be page until it becomes memdesc.
  
> > There is a struct page for everything that's memblock_alloc()ed. And we can
> > do page list, but for large  physically contiguous allocation it does not
> > make sense. 
> 
> Arguably you could make them into high order pages and preserve those..

They are not aligned by order and they may be partially freed starting at
arbitrary page. Making them high order pages will be a mess.

[1] https://kernelnewbies.org/MatthewWilcox/Memdescs

-- 
Sincerely yours,
Mike.