linux-kernel - Re: [PATCH] ext4: fix allocation failure in ext4_mb_load_buddy

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: <294A93D3-4FBA-46E7-8814-1C7E0CC82359@dilger.ca>
Date: Wed, 24 Sep 2025 17:33:15 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: Theodore Ts'o <tytso@....edu>,
 linux-ext4 <linux-ext4@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>,
 syzbot+fd3f70a4509fca8c265d@...kaller.appspotmail.com
Subject: Re: [PATCH] ext4: fix allocation failure in ext4_mb_load_buddy_gfp

On Sep 23, 2025, at 7:16 PM, Deepanshu Kartikey <kartikey406@...il.com> wrote:
> 
> Fix WARNING in __alloc_pages_slowpath() when ext4_discard_preallocations()
> is called during memory pressure.
> 
> The issue occurs when __GFP_NOFAIL is used during memory reclaim context,
> which can lead to allocation warnings. Avoid using __GFP_NOFAIL when
> the current process is already in memory allocation context to prevent
> potential deadlocks and warnings.

This quiets the memory allocation warning, but will result in a filesystem
error being generated (read-only or panic) if the allocation fails, if you
follow the code a few lines further down.  That is not good error handling
for a memory allocation failure during cache cleanup.

When __GFP_NOFAIL was *always* passed, then the error could never be hit,
which is why it was put there in the first place.

It looks like this function can return an error and the caller will retry,
so that would be preferable to causing the filesystem to abort in this case.

Cheers, Andreas

> 
> Reported-by: syzbot+fd3f70a4509fca8c265d@...kaller.appspotmail.com
> Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>
> Tested-by: syzbot+fd3f70a4509fca8c265d@...kaller.appspotmail.com
> ---
> fs/ext4/mballoc.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 5898d92ba19f..61ee009717f1 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -5656,9 +5656,11 @@ void ext4_discard_preallocations(struct inode *inode)
> 	list_for_each_entry_safe(pa, tmp, &list, u.pa_tmp_list) {
> 		BUG_ON(pa->pa_type != MB_INODE_PA);
> 		group = ext4_get_group_number(sb, pa->pa_pstart);
> +		gfp_t flags = GFP_NOFS;
> +		if (!(current->flags & PF_MEMALLOC))
> +			flags |= __GFP_NOFAIL;
> 
> -		err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
> -					     GFP_NOFS|__GFP_NOFAIL);
> +		err = ext4_mb_load_buddy_gfp(sb, group, &e4b, flags);
> 		if (err) {
> 			ext4_error_err(sb, -err, "Error %d loading buddy information for %u",
> 				       err, group);
> --
> 2.43.0
> 


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)