From: Zhan Xusheng <zhanxusheng1024@gmail.com>
To: Ryusuke Konishi <konishi.ryusuke@gmail.com>,
Viacheslav Dubeyko <slava@dubeyko.com>
Cc: Zhan Xusheng <zhanxusheng@xiaomi.com>,
linux-nilfs <linux-nilfs@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzbot+5957361606d7b750b874@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] nilfs2: suppress false positive WARN_ONs for sufile after an FS error
Date: Thu, 6 Aug 2026 20:58:39 +0800 [thread overview]
Message-ID: <20260806125841.966577-1-zhanxusheng@xiaomi.com> (raw)
In-Reply-To: <20260806090311.32633-1-konishi.ryusuke@gmail.com>
On Thu, 6 Aug 2026 18:02:00 +0900 Ryusuke Konishi wrote:
> +#define nilfs_sufile_warn_on_error(sufile, err) \
> + ({ \
> + int _err = (err); \
> + \
> + if (unlikely(_err)) \
> + _err = WARN_ONCE(!sb_rdonly((sufile)->i_sb), \
> + "unexpected sufile error %d\n", _err) ? \
> + -EIO : -EROFS; \
> + unlikely(_err); \
> + })
The warning-suppression itself looks right to me: WARN_ONCE(!sb_rdonly)
only fires when the fs has not degraded to read-only, so the false
positives from the log writer go away.
But I think the value the macro evaluates to is not what the kernel-doc
above describes. The last statement is unlikely(_err), and unlikely(x)
expands to __builtin_expect(!!(x), 0), so the statement expression
evaluates to !!(_err), i.e. 0 or 1, not _err. So the macro returns:
err == 0 -> 0
not read-only -> 1 (documented as -EIO)
read-only -> 1 (documented as -EROFS)
For the WARN_ON() replacements that discard the return value this does
not matter. But nilfs_segctor_truncate_segments() consumes it as an
error code:
ret = nilfs_sufile_warn_on_error(
sufile, nilfs_sufile_free(sufile, segbuf->sb_nextnum));
if (ret && err != -EROFS)
err = ret;
...
return err;
so it stores 1 rather than -EIO/-EROFS, nilfs_segctor_collect() then
returns 1, and the "err != -EROFS" preference cannot distinguish the two
codes. That seems to contradict both the kernel-doc and the intent to
"return the error code appropriately".
Wouldn't ending the macro with plain
_err;
do what's intended? The branch hint is already provided by the
if (unlikely(_err)) above.
Thanks,
Zhan Xusheng
next prev parent reply other threads:[~2026-08-06 12:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 9:02 Ryusuke Konishi
2026-08-06 12:58 ` Zhan Xusheng [this message]
2026-08-06 13:07 ` Ryusuke Konishi
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=20260806125841.966577-1-zhanxusheng@xiaomi.com \
--to=zhanxusheng1024@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+5957361606d7b750b874@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=zhanxusheng@xiaomi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®