From: Tristan Madani <tristmd@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
Tristan Madani <tristan@talencesecurity.com>,
syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com
Subject: [PATCH 3/3] jffs2: fix GC thread BUG_ON during reconfigure via fspick
Date: Fri, 1 May 2026 11:02:46 +0000 [thread overview]
Message-ID: <20260501110246.50647-3-tristmd@gmail.com> (raw)
In-Reply-To: <20260501110246.50647-1-tristmd@gmail.com>
From: Tristan Madani <tristan@talencesecurity.com>
jffs2_do_remount_fs() uses fc->sb_flags to decide whether to start
the garbage collection thread. However, when called via fspick(2)
followed by fsconfig(FSCONFIG_CMD_RECONFIGURE), fc->sb_flags does
not reflect the current mount state -- it only contains flags being
explicitly changed (as indicated by fc->sb_flags_mask).
When fspick() is called with flags=0 on a read-only mount,
fc->sb_flags has SB_RDONLY clear (since SB_RDONLY is not in
sb_flags_mask). This causes jffs2_start_garbage_collect_thread()
to be called even though the filesystem remains read-only. On the
second reconfigure, BUG_ON(c->gc_task) fires because the thread
from the first call is still running.
Fix this by computing the effective read-only state using both
fc->sb_flags and fc->sb_flags_mask. Also unconditionally call
jffs2_stop_garbage_collect_thread() before potentially restarting
it, which is safe when gc_task is NULL and prevents the BUG_ON.
Reported-by: syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=61a9d95630970eece39d
Tested-by: syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com
Fixes: ec10a24f10c8f ("vfs: Convert jffs2 to use the new mount API")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jffs2/fs.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 6ada8369a7622..33574312b7abe 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -396,28 +396,28 @@ void jffs2_dirty_inode(struct inode *inode, int flags)
int jffs2_do_remount_fs(struct super_block *sb, struct fs_context *fc)
{
struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
+ bool new_ro;
if (c->flags & JFFS2_SB_FLAG_RO && !sb_rdonly(sb))
return -EROFS;
- /* We stop if it was running, then restart if it needs to.
- This also catches the case where it was stopped and this
- is just a remount to restart it.
- Flush the writebuffer, if necessary, else we loose it */
+ new_ro = (fc->sb_flags_mask & SB_RDONLY) ?
+ (fc->sb_flags & SB_RDONLY) : sb_rdonly(sb);
+
+ jffs2_stop_garbage_collect_thread(c);
+
if (!sb_rdonly(sb)) {
- jffs2_stop_garbage_collect_thread(c);
mutex_lock(&c->alloc_sem);
jffs2_flush_wbuf_pad(c);
mutex_unlock(&c->alloc_sem);
}
- if (!(fc->sb_flags & SB_RDONLY))
+ if (!new_ro)
jffs2_start_garbage_collect_thread(c);
fc->sb_flags |= SB_NOATIME;
return 0;
}
-
/* jffs2_new_inode: allocate a new inode and inocache, add it to the hash,
fill in the raw_inode while you're at it. */
struct inode *jffs2_new_inode (struct inode *dir_i, umode_t mode, struct jffs2_raw_inode *ri)
--
2.47.3
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Tristan Madani <tristmd@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
Tristan Madani <tristan@talencesecurity.com>,
syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com
Subject: [PATCH 3/3] jffs2: fix GC thread BUG_ON during reconfigure via fspick
Date: Fri, 1 May 2026 11:02:46 +0000 [thread overview]
Message-ID: <20260501110246.50647-3-tristmd@gmail.com> (raw)
In-Reply-To: <20260501110246.50647-1-tristmd@gmail.com>
From: Tristan Madani <tristan@talencesecurity.com>
jffs2_do_remount_fs() uses fc->sb_flags to decide whether to start
the garbage collection thread. However, when called via fspick(2)
followed by fsconfig(FSCONFIG_CMD_RECONFIGURE), fc->sb_flags does
not reflect the current mount state -- it only contains flags being
explicitly changed (as indicated by fc->sb_flags_mask).
When fspick() is called with flags=0 on a read-only mount,
fc->sb_flags has SB_RDONLY clear (since SB_RDONLY is not in
sb_flags_mask). This causes jffs2_start_garbage_collect_thread()
to be called even though the filesystem remains read-only. On the
second reconfigure, BUG_ON(c->gc_task) fires because the thread
from the first call is still running.
Fix this by computing the effective read-only state using both
fc->sb_flags and fc->sb_flags_mask. Also unconditionally call
jffs2_stop_garbage_collect_thread() before potentially restarting
it, which is safe when gc_task is NULL and prevents the BUG_ON.
Reported-by: syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=61a9d95630970eece39d
Tested-by: syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com
Fixes: ec10a24f10c8f ("vfs: Convert jffs2 to use the new mount API")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jffs2/fs.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 6ada8369a7622..33574312b7abe 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -396,28 +396,28 @@ void jffs2_dirty_inode(struct inode *inode, int flags)
int jffs2_do_remount_fs(struct super_block *sb, struct fs_context *fc)
{
struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
+ bool new_ro;
if (c->flags & JFFS2_SB_FLAG_RO && !sb_rdonly(sb))
return -EROFS;
- /* We stop if it was running, then restart if it needs to.
- This also catches the case where it was stopped and this
- is just a remount to restart it.
- Flush the writebuffer, if necessary, else we loose it */
+ new_ro = (fc->sb_flags_mask & SB_RDONLY) ?
+ (fc->sb_flags & SB_RDONLY) : sb_rdonly(sb);
+
+ jffs2_stop_garbage_collect_thread(c);
+
if (!sb_rdonly(sb)) {
- jffs2_stop_garbage_collect_thread(c);
mutex_lock(&c->alloc_sem);
jffs2_flush_wbuf_pad(c);
mutex_unlock(&c->alloc_sem);
}
- if (!(fc->sb_flags & SB_RDONLY))
+ if (!new_ro)
jffs2_start_garbage_collect_thread(c);
fc->sb_flags |= SB_NOATIME;
return 0;
}
-
/* jffs2_new_inode: allocate a new inode and inocache, add it to the hash,
fill in the raw_inode while you're at it. */
struct inode *jffs2_new_inode (struct inode *dir_i, umode_t mode, struct jffs2_raw_inode *ri)
--
2.47.3
next prev parent reply other threads:[~2026-05-01 11:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 11:02 [PATCH 1/3] jffs2: always stop garbage collection thread on unmount Tristan Madani
2026-05-01 11:02 ` Tristan Madani
2026-05-01 11:02 ` [PATCH 2/3] jffs2: clean up xattr refs in jffs2_del_ino_cache instead of BUG_ON Tristan Madani
2026-05-01 11:02 ` Tristan Madani
2026-05-01 11:02 ` Tristan Madani [this message]
2026-05-01 11:02 ` [PATCH 3/3] jffs2: fix GC thread BUG_ON during reconfigure via fspick Tristan Madani
2026-05-05 12:55 ` [PATCH 1/3] jffs2: always stop garbage collection thread on unmount Tristan Madani
2026-05-31 14:14 ` Richard Weinberger
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=20260501110246.50647-3-tristmd@gmail.com \
--to=tristmd@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=syzbot+61a9d95630970eece39d@syzkaller.appspotmail.com \
--cc=tristan@talencesecurity.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.