Re: [PATCH] ramfs: convert alloc_pages() to folio_alloc() in ramfs_nommu_expand_for_mapping()

[Matthew Wilcox <willy@infradead.org>]

On Wed, Feb 25, 2026 at 06:44:28PM +0000, Viacheslav Dubeyko wrote:
> CC: linux-fsdevel@vger.kernel.org

Good plan.

> On Tue, 2026-02-24 at 15:31 -0500, AnishMulay wrote:
> > Currently, ramfs_nommu_expand_for_mapping() utilizes the deprecated
> > alloc_pages() API. This patch converts the allocation step to use

alloc_pages() is not deprecated.  There are no plans for its removal.

> > the modern folio_alloc() API, removing a legacy caller and helping
> > pave the way for the eventual removal of alloc_pages().
> > 
> > Because nommu architectures require physically contiguous memory that
> > often needs to be trimmed to the exact requested size, the allocated
> > folio is immediately shattered using split_page().

Except that split_page() doesn't work on folios.  It says so right there
in the documentation:

 * split_page takes a non-compound higher-order page, and splits it into

Folios are compound pages.  This should have told you that you were
going the wrong thing.

> > Since split_page() destroys the compound folio metadata, using folio
> > iteration helpers (like folio_page) becomes unsafe. Therefore, this
> > patch deliberately drops back to a standard struct page array after
> > the split. This safely isolates the folio conversion to the allocation
> > phase while strictly preserving the existing trimming and page cache
> > insertion behavior.

Please stop trying to help, particularly for code you can't test.