linux-ext4 - Re: [PATCH 22/25] fs/buffer: prevent WARN_ON in __alloc_pages

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aP8h1jz8JEN-3du0@infradead.org>
Date: Mon, 27 Oct 2025 00:40:06 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Baokun Li <libaokun@...weicloud.com>,
	"Darrick J. Wong" <djwong@...nel.org>, linux-ext4@...r.kernel.org,
	tytso@....edu, adilger.kernel@...ger.ca, jack@...e.cz,
	linux-kernel@...r.kernel.org, kernel@...kajraghav.com,
	mcgrof@...nel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, yi.zhang@...wei.com, yangerkun@...wei.com,
	chengzhihao1@...wei.com, libaokun1@...wei.com,
	catherine.hoang@...cle.com
Subject: Re: [PATCH 22/25] fs/buffer: prevent WARN_ON in
 __alloc_pages_slowpath() when BS > PS

On Sat, Oct 25, 2025 at 06:56:57PM +0100, Matthew Wilcox wrote:
> If filesystems actually require __GFP_NOFAIL for high-order allocations,
> then this is a new requirement that needs to be communicated to the MM
> developers, not hacked around in filesystems (or the VFS).  And that
> communication needs to be a separate thread with a clear subject line
> to attract the right attention, not buried in patch 26/28.

It's not really new.  XFS had this basically since day 1, but with
Linus having a religious aversion against __GFP_NOFAIL most folks
have given up on trying to improve it as it just ends up in shouting
matches in political grounds.  XFS just ends up with it's own fallback
in xfs_buf_alloc_backing_mem which survives the various rounds of
refactoring since XFS was merged.  Given that weird behavior in some
of the memory allocators where GFP_NOFAIL is simply ignored for too
large allocations that seems like by far the sanest option in the
current Linux environment unfortunately.