[PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Yun Zhou]

When netfs_create_write_req() fails with -ENOMEM in netfs_writepages(),
the couldnt_start error path redirties and unlocks the first folio, then
calls writeback_iter() expecting it to return NULL. However, if the
mapping contains multiple dirty folios, writeback_iter() returns the
next one, triggering WARN_ON_ONCE(folio != NULL).

This can be reproduced via 9p (cache=loose) with shared mmap writes and
fault injection (fail_nth), where v9fs_mmap_vm_close() triggers
writeback on a mapping with multiple dirty folios during mmap overlap.

Fix this by looping over all remaining dirty folios in the ENOMEM path,
redirtying and unlocking each one. This ensures all folios taken by the
writeback iterator are properly released, and they will be retried on
the next writeback cycle when memory is available.

Reported-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=0da43efa72f88bd3a8af
Fixes: ac5f95ac5d6d ("netfs: Fix writeback error handling")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
---
 fs/netfs/write_issue.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/netfs/write_issue.c b/fs/netfs/write_issue.c
index f2761c99795a..5aa47128f7e7 100644
--- a/fs/netfs/write_issue.c
+++ b/fs/netfs/write_issue.c
@@ -597,10 +597,11 @@ int netfs_writepages(struct address_space *mapping,
 
 couldnt_start:
 	if (error == -ENOMEM) {
-		folio_redirty_for_writepage(wbc, folio);
-		folio_unlock(folio);
-		folio = writeback_iter(mapping, wbc, folio, &error);
-		WARN_ON_ONCE(folio != NULL);
+		/* Redirty all dirty folios and let writeback retry later. */
+		do {
+			folio_redirty_for_writepage(wbc, folio);
+			folio_unlock(folio);
+		} while ((folio = writeback_iter(mapping, wbc, folio, &error)));
 	} else {
 		netfs_kill_dirty_pages(mapping, wbc, folio);
 	}
-- 
2.43.0

Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Zhou, Yun]

Tested-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com

https://lore.kernel.org/all/6a4c9787.a1ad617e.25832.0006.GAE@google.com/

On 7/7/26 13:25, Yun Zhou wrote:
> When netfs_create_write_req() fails with -ENOMEM in netfs_writepages(),
> the couldnt_start error path redirties and unlocks the first folio, then
> calls writeback_iter() expecting it to return NULL. However, if the
> mapping contains multiple dirty folios, writeback_iter() returns the
> next one, triggering WARN_ON_ONCE(folio != NULL).
> 
> This can be reproduced via 9p (cache=loose) with shared mmap writes and
> fault injection (fail_nth), where v9fs_mmap_vm_close() triggers
> writeback on a mapping with multiple dirty folios during mmap overlap.
> 
> Fix this by looping over all remaining dirty folios in the ENOMEM path,
> redirtying and unlocking each one. This ensures all folios taken by the
> writeback iterator are properly released, and they will be retried on
> the next writeback cycle when memory is available.
> 
> Reported-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=0da43efa72f88bd3a8af
> Fixes: ac5f95ac5d6d ("netfs: Fix writeback error handling")
> Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> ---
>   fs/netfs/write_issue.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/netfs/write_issue.c b/fs/netfs/write_issue.c
> index f2761c99795a..5aa47128f7e7 100644
> --- a/fs/netfs/write_issue.c
> +++ b/fs/netfs/write_issue.c
> @@ -597,10 +597,11 @@ int netfs_writepages(struct address_space *mapping,
>   
>   couldnt_start:
>   	if (error == -ENOMEM) {
> -		folio_redirty_for_writepage(wbc, folio);
> -		folio_unlock(folio);
> -		folio = writeback_iter(mapping, wbc, folio, &error);
> -		WARN_ON_ONCE(folio != NULL);
> +		/* Redirty all dirty folios and let writeback retry later. */
> +		do {
> +			folio_redirty_for_writepage(wbc, folio);
> +			folio_unlock(folio);
> +		} while ((folio = writeback_iter(mapping, wbc, folio, &error)));
>   	} else {
>   		netfs_kill_dirty_pages(mapping, wbc, folio);
>   	}

Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Zhou, Yun]

Friendly ping.

On 7/7/2026 1:25 PM, Yun Zhou wrote:
> When netfs_create_write_req() fails with -ENOMEM in netfs_writepages(),
> the couldnt_start error path redirties and unlocks the first folio, then
> calls writeback_iter() expecting it to return NULL. However, if the
> mapping contains multiple dirty folios, writeback_iter() returns the
> next one, triggering WARN_ON_ONCE(folio != NULL).
> 
> This can be reproduced via 9p (cache=loose) with shared mmap writes and
> fault injection (fail_nth), where v9fs_mmap_vm_close() triggers
> writeback on a mapping with multiple dirty folios during mmap overlap.
> 
> Fix this by looping over all remaining dirty folios in the ENOMEM path,
> redirtying and unlocking each one. This ensures all folios taken by the
> writeback iterator are properly released, and they will be retried on
> the next writeback cycle when memory is available.
> 
> Reported-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=0da43efa72f88bd3a8af
> Fixes: ac5f95ac5d6d ("netfs: Fix writeback error handling")
> Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
> ---
>   fs/netfs/write_issue.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/netfs/write_issue.c b/fs/netfs/write_issue.c
> index f2761c99795a..5aa47128f7e7 100644
> --- a/fs/netfs/write_issue.c
> +++ b/fs/netfs/write_issue.c
> @@ -597,10 +597,11 @@ int netfs_writepages(struct address_space *mapping,
>   
>   couldnt_start:
>   	if (error == -ENOMEM) {
> -		folio_redirty_for_writepage(wbc, folio);
> -		folio_unlock(folio);
> -		folio = writeback_iter(mapping, wbc, folio, &error);
> -		WARN_ON_ONCE(folio != NULL);
> +		/* Redirty all dirty folios and let writeback retry later. */
> +		do {
> +			folio_redirty_for_writepage(wbc, folio);
> +			folio_unlock(folio);
> +		} while ((folio = writeback_iter(mapping, wbc, folio, &error)));
>   	} else {
>   		netfs_kill_dirty_pages(mapping, wbc, folio);
>   	}

Is writeback_iter() missing some error handling? -- was Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[David Howells]

Yun Zhou <yun.zhou@windriver.com> wrote:

> When netfs_create_write_req() fails with -ENOMEM in netfs_writepages(),
> the couldnt_start error path redirties and unlocks the first folio, then
> calls writeback_iter() expecting it to return NULL. However, if the
> mapping contains multiple dirty folios, writeback_iter() returns the
> next one, triggering WARN_ON_ONCE(folio != NULL).
> 
> This can be reproduced via 9p (cache=loose) with shared mmap writes and
> fault injection (fail_nth), where v9fs_mmap_vm_close() triggers
> writeback on a mapping with multiple dirty folios during mmap overlap.
> 
> Fix this by looping over all remaining dirty folios in the ENOMEM path,
> redirtying and unlocking each one. This ensures all folios taken by the
> writeback iterator are properly released, and they will be retried on
> the next writeback cycle when memory is available.
>
> ...
> --- a/fs/netfs/write_issue.c
> +++ b/fs/netfs/write_issue.c
> @@ -597,10 +597,11 @@ int netfs_writepages(struct address_space *mapping,
>  
>  couldnt_start:
>  	if (error == -ENOMEM) {
> -		folio_redirty_for_writepage(wbc, folio);
> -		folio_unlock(folio);
> -		folio = writeback_iter(mapping, wbc, folio, &error);
> -		WARN_ON_ONCE(folio != NULL);
> +		/* Redirty all dirty folios and let writeback retry later. */
> +		do {
> +			folio_redirty_for_writepage(wbc, folio);
> +			folio_unlock(folio);
> +		} while ((folio = writeback_iter(mapping, wbc, folio, &error)));
>  	} else {
>  		netfs_kill_dirty_pages(mapping, wbc, folio);
>  	}

This seems like the wrong thing to do - or, at least, a bug in the
writeback_iter() API.  Getting something like ENOMEM would seem to indicate
that all subsequent writeback_iter() calls in this loop are pointless as it
looks like the sequence will just go { lock, undirty, dirty, unlock } for each
folio.

David

Re: Is writeback_iter() missing some error handling? -- was Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Zhou, Yun]

On 7/22/26 22:04, David Howells wrote:
> Yun Zhou <yun.zhou@windriver.com> wrote:
> 
>>   couldnt_start:
>>        if (error == -ENOMEM) {
>> -             folio_redirty_for_writepage(wbc, folio);
>> -             folio_unlock(folio);
>> -             folio = writeback_iter(mapping, wbc, folio, &error);
>> -             WARN_ON_ONCE(folio != NULL);
>> +             /* Redirty all dirty folios and let writeback retry later. */
>> +             do {
>> +                     folio_redirty_for_writepage(wbc, folio);
>> +                     folio_unlock(folio);
>> +             } while ((folio = writeback_iter(mapping, wbc, folio, &error)));
>>        } else {
>>                netfs_kill_dirty_pages(mapping, wbc, folio);
>>        }
> 
> This seems like the wrong thing to do - or, at least, a bug in the
> writeback_iter() API.  Getting something like ENOMEM would seem to indicate
> that all subsequent writeback_iter() calls in this loop are pointless as it
> looks like the sequence will just go { lock, undirty, dirty, unlock } for each
> folio.
> 

Thanks for the feedback. I understand the concern — the loop is indeed 
doing mechanical { redirty, unlock } work that ideally writeback_iter() 
could handle internally when the caller has nothing meaningful to do 
with the folios.

However, given the current writeback_iter() API contract ("callers must 
keep calling until it returns NULL"), I'm not sure there's a cleaner way 
to handle this without a VFS/mm level change. And in the meantime, 
syzbot is hitting this — the WARN fires and any folio returned beyond 
the first is left locked.

Would it be acceptable to keep this as a minimal stopgap fix for the 
immediate bug, with the understanding that it can be cleaned up later if 
writeback_iter() gains an early-abort mechanism? Happy to adjust the 
approach if you have something else in mind.

BR,
Yun

Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Christoph Hellwig]

On Tue, Jul 07, 2026 at 01:25:55PM +0800, Yun Zhou wrote:
> When netfs_create_write_req() fails with -ENOMEM in netfs_writepages(),
> the couldnt_start error path redirties and unlocks the first folio,

writeback must use mempools to back resoures, or __GFP_NOFAIL if it
can't for some reason.  -ENOMEM must not happend in writeback paths
or your toast.  So please fix the cause of this error and not the
symptoms.

Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Zhou, Yun]

On 7/23/26 12:59, Christoph Hellwig wrote:
> On Tue, Jul 07, 2026 at 01:25:55PM +0800, Yun Zhou wrote:
>> When netfs_create_write_req() fails with -ENOMEM in netfs_writepages(),
>> the couldnt_start error path redirties and unlocks the first folio,
> 
> writeback must use mempools to back resoures, or __GFP_NOFAIL if it
> can't for some reason.  -ENOMEM must not happend in writeback paths
> or your toast.  So please fix the cause of this error and not the
> symptoms.
> 

Thanks for the review. You're right - writeback should not fail with ENOMEM.

I'll follow your suggestion and use __GFP_NOFAIL for the allocation in 
the writeback path. The ENOMEM here comes from rolling_buffer_init() 
which uses plain GFP_NOFS for its folio_queue allocation.

Using mempools would be the more robust approach, but it requires adding 
a new mempool, modifying the rolling_buffer_init() signature and all its 
callers, plus the init/destroy lifecycle - a much larger change. 
__GFP_NOFAIL is a minimal fix that achieves the same goal for the 
writeback path.

Will send v2 shortly.

Re: Is writeback_iter() missing some error handling? -- was Re: [PATCH] netfs: fix ENOMEM handling in netfs_writepages() to drain all dirty folios

[Matthew Wilcox]

On Wed, Jul 22, 2026 at 03:04:03PM +0100, David Howells wrote:
> This seems like the wrong thing to do - or, at least, a bug in the
> writeback_iter() API.  Getting something like ENOMEM would seem to indicate
> that all subsequent writeback_iter() calls in this loop are pointless as it
> looks like the sequence will just go { lock, undirty, dirty, unlock } for each
> folio.

I'd find it hard to call a bug, when it's intended behaviour:

                 * For integrity writeback we have to keep going until we have
                 * written all the folios we tagged for writeback above, even if
                 * we run past wbc->nr_to_write or encounter errors.
                 * We stash away the first error we encounter in wbc->saved_err
                 * so that it can be retrieved when we're done.  This is because
                 * the file system may still have state to clear for each folio.
                 *
                 * For background writeback we exit as soon as we run past
                 * wbc->nr_to_write or encounter the first error.

Why are you getting ENOMEM for a sync() writeback anyway?  Is this some
stupid error injection?