From: Joshua Crofts <joshua.crofts1@gmail.com>
To: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: Viacheslav Dubeyko <slava@dubeyko.com>,
linux-nilfs@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+cae54346a70bbceeff2c@syzkaller.appspotmail.com
Subject: Re: [PATCH] nilfs2: fix infinite loop in nilfs_clean_segments()
Date: Fri, 17 Jul 2026 12:40:10 +0200 [thread overview]
Message-ID: <20260717124010.00001374@gmail.com> (raw)
In-Reply-To: <CAKFNMo=L6fQa54Nd+u4ySOeTAuWF36cgymYwdjKJpD_FLeXKfw@mail.gmail.com>
On Fri, 17 Jul 2026 19:34:21 +0900
Ryusuke Konishi <konishi.ryusuke@gmail.com> wrote:
> On Fri, Jul 17, 2026 at 4:49 PM Joshua Crofts wrote:
> >
> > syzbot reported a hung task in nilfs_transaction_begin(). This occurs
> > because the cleaner ioctl falls into an infinite loop if
> > nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device
> > is remounted as read-only after an I/O error).
> >
> > Currently in nilfs_clean_segments(), if err is non-zero, it logs the
> > error and sleeps but doesn't abort when it encounters a terminal error
> > like -EROFS. This causes the thread to loop forever.
> >
> > Fix this by breaking out of the loop if nilfs_segctor_construct()
> > returns -EROFS. This matches the behaviour in
> > nilfs_segctor_write_out(), which also handles -EROFS.
> >
> > Reported-by: syzbot+cae54346a70bbceeff2c@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=cae54346a70bbceeff2c
> > Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
> > Assisted-by: gemini:gemini-3.1-pro
> > Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
> > ---
> > As much as I've tried, syzbot is unable to test this and always fails
> > with "FATAL: Kernel too old". Nevertheless, I've tested the patch with
> > the same reproducer in QEMU and the system didn't hang.
>
> Thanks for the patch, Joshua!
> This fix correctly addresses the issue reported by syzbot.
>
> I have one request regarding the loop exit:
> Could you modify the patch to jump to the out_unlock label instead of
> using break?
> This is to prevent discard commands from being sent to the underlying
> block device when the operation has failed and the filesystem state
> has degraded to read-only.
Yes, no problem, that makes more sense. Will send a new version in a bit.
--
Kind regards,
Joshua Crofts
prev parent reply other threads:[~2026-07-17 10:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 7:47 [PATCH] nilfs2: fix infinite loop in nilfs_clean_segments() Joshua Crofts
2026-07-17 10:34 ` Ryusuke Konishi
2026-07-17 10:40 ` Joshua Crofts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260717124010.00001374@gmail.com \
--to=joshua.crofts1@gmail.com \
--cc=konishi.ryusuke@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=syzbot+cae54346a70bbceeff2c@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.