From: Aurelien DESBRIERES <aurelien@hackers.camp>
To: jack@suse.cz
Cc: brauner@kernel.org, willy@infradead.org, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot@lists.linux.dev, syzkaller-bugs@googlegroups.com,
aurelien.desbrieres@gmail.com
Subject: Re: [syzbot ci] Re: buffer: warn when a buffer is attached to a second mmb
Date: Tue, 27 Oct 2026 13:16:49 +0100 [thread overview]
Message-ID: <20261027121649.69819-1-aurelien@hackers.camp> (raw)
In-Reply-To: <a7h6k7ecnmnj426ss45fqdk2kjodrjurjpwhcwao2bjkw7tqtl@qghx3vrx5ber>
On Tue 27-10-26 13:10:55, Jan Kara wrote:
> Woohoo, great that we have added this. So now we have some filesystem bugs
> to analyze ;). At least in ext4 case this is a real bug as xattr blocks can
> be indeed shared among inodes.
[...]
> I'm not sure about the FAT cases because directory blocks where this
> triggers should better belong to a single directory. So it could be some
> race with freeing & reallocating blocks. Needs more digging.
Our mails crossed; forget the pr_warn alternative then, the WARN stays
as sent. If digging into the FAT cases from the syzbot repros helps, I
can take that on; say so and I will report what I find. Your free and
reallocate theory also describes something beamfs could do with its
indirect blocks, so I am running xfstests against the warning on our
side first.
Aurelien
prev parent reply other threads:[~2026-10-27 12:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 17:06 mmb_sync: b_mmb NULL window races mmb_mark_buffer_dirty Aurelien DESBRIERES
2026-10-26 13:08 ` Jan Kara
2026-10-26 20:56 ` Aurelien DESBRIERES
2026-10-26 21:36 ` [PATCH] buffer: warn when a buffer is attached to a second mmb Aurelien DESBRIERES
2026-10-26 21:54 ` Jan Kara
2026-10-27 8:46 ` [syzbot ci] " syzbot ci
2026-10-27 12:10 ` Aurelien DESBRIERES
2026-10-27 12:10 ` Jan Kara
2026-10-27 12:16 ` Aurelien DESBRIERES [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=20261027121649.69819-1-aurelien@hackers.camp \
--to=aurelien@hackers.camp \
--cc=aurelien.desbrieres@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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.