From: Zorro Lang <zlang@kernel.org>
To: Chao Yu <chao@kernel.org>
Cc: Anand Suveer Jain <asj@kernel.org>,
fstests@vger.kernel.org, jaegeuk@kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
"Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH v2] common/rc: support f2fs in _require_fanotify_ioerrors()
Date: Tue, 28 Jul 2026 14:49:19 +0800 [thread overview]
Message-ID: <amhKovVDjwawoWdQ@zlang-mailbox> (raw)
In-Reply-To: <99220f8b-05d4-427f-998d-7f15a84c8805@kernel.org>
On Tue, Jul 28, 2026 at 10:24:10AM +0800, Chao Yu wrote:
> On 7/28/26 01:57, Zorro Lang wrote:
> > On Thu, Jul 23, 2026 at 05:09:12PM +0800, Chao Yu wrote:
> > > On 7/17/26 18:47, Zorro Lang wrote:
> > > > On Wed, Jul 08, 2026 at 11:25:37AM +0800, Chao Yu wrote:
> > > > > On 7/7/26 18:13, Anand Suveer Jain wrote:
> > > > > > On 6/7/26 14:43, Chao Yu wrote:
> > > > > > > f2fs has supported to report fserror, this patch adds support for f2fs
> > > > > > > in _require_fanotify_ioerrors(), so that we can run generic/791 on f2fs.
> > > > > > >
> > > > > > > Cc: Darrick J. Wong <djwong@kernel.org>
> > > > > > > Signed-off-by: Chao Yu <chao@kernel.org>
> > > > > > > ---
> > > > > > > common/rc | 3 +++
> > > > > > > 1 file changed, 3 insertions(+)
> > > > > > >
> > > > > > > diff --git a/common/rc b/common/rc
> > > > > > > index 494725547..f51ad59f3 100644
> > > > > > > --- a/common/rc
> > > > > > > +++ b/common/rc
> > > > > > > @@ -6257,6 +6257,9 @@ _require_fanotify_ioerrors()
> > > > > > > x="$(_get_fs_sysfs_attr $TEST_DEV err_report_sec)"
> > > > > > > test -n "$x" && return 0
> > > > > > > ;;
> > > > > >
> > > > > >
> > > > > > > + f2fs)
> > > > > > > + x="$(cat /sys/fs/f2fs/features/fserror)"
> > > > > > > + test -n "$x" && return 0
> > > > > >
> > > > > > Don't we need to check if /sys/fs/f2fs/features/fserror
> > > > > > is present in the running kernel (there are helpers)
> > > > >
> > > > > Hi Anand,
> > > > >
> > > > > You mean _has_fs_sysfs_attr()? however, it forces to check first parameter $dev
> > > > > w/ block device type:
> > > > >
> > > > > if [ ! -b "$dev" -o -z "$attr" ];then
> > > > > _fail "Usage: _has_fs_sysfs_attr <mounted_device> <attr>"
> > > > > fi
> > > >
> > > > Hi Chao and Anand,
> > > >
> > > > The *_fs_sysfs related helpers were brought in by me in:
> > > > commit 2a7b77abcd1dde735186b363da24540706c43b73
> > > > Author: Zorro Lang <zlang@redhat.com>
> > > > Date: Tue Jul 5 17:30:24 2016 +0800
> > > >
> > > > xfs: configurable behavior on errors at unmount time
> > > >
> > > > At that time, I didn't think about the "features/" directory.
> > > >
> > > > Now, let me rethink this set of helpers. I feel that the *_fs_sysfs
> > > > family of functions shouldn't be restricted to the $dev directory,
> > > > we should remove this restriction.
> > > >
> > > > Following that, we bring in *_fs_sysfs_device (appending the _device suffix)
> > > > helpers which call *_fs_sysfs(). Also change the test cases who call these
> > > > functions.
> > > >
> > > > Finally, we can introduce the *_fs_sysfs_features functions (or simply use
> > > > *_fs_sysfs directly).
> > > >
> > > > Also, we have both *_fs_sysfs_attr and *_fs_sysfs, and the logic between
> > > > them is somewhat confusing and easy to mix up.
> > >
> > > Zorro,
> > >
> > > It makes sense, and good news to their user. Thanks for the proposal.
> > >
> > > >
> > > > I need to write a series of patches to clean up these logic. For this current
> > > > patch, we can start with a small-scale change first. What do you think?
> > >
> > > So I will use this first:
> > >
> > > f2fs)
> > > local feat_file="/sys/fs/f2fs/features/fserror"
> > > if [ -f "$feat_file" ] && [ "$(cat "$feat_file")" = "supported" ]; then
> > > return 0
> > > fi
> > > ;;
> > >
> > > And then waiting for your cleanup? or if you want to clean up this, please do it
> > > directly while merging.
> >
> > If f2fs wants to test this feature right away, I can merge your patch now and
> > clean it up later. If it's not urgent, I'll take care of it all together.
>
> Zorro,
>
> Could you please help to merge it first? so that we can test 791 w/ last
> upstream code, and also in case we missed to track its status to lose it. :P
Sure, I'm good to have this first. Could you send a new patch version, if you'd
like to change it?
Thanks,
Zorro
>
> Thanks,
>
> >
> > Thanks,
> > Zorro
> >
> > >
> > > Thanks,
> > >
> > > >
> > > > Thanks,
> > > > Zorro
> > > >
> > > > >
> > > > >
> > > > > > before reading it?
> > > > >
> > > > > How about this?
> > > > >
> > > > > f2fs)
> > > > > local feat_file="/sys/fs/f2fs/features/fserror"
> > > > > if [ -f "$feat_file" ] && [ "$(cat "$feat_file")" = "supported" ]; then
> > > > > return 0
> > > > > fi
> > > > > ;;
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > esac
> > > > > > > _notrun "$FSTYP does not support fanotify ioerrors"
> > > > > >
> > > > >
> > >
> > >
>
next prev parent reply other threads:[~2026-07-28 6:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 6:43 [PATCH v2] common/rc: support f2fs in _require_fanotify_ioerrors() Chao Yu
2026-07-07 10:13 ` Anand Suveer Jain
2026-07-08 3:25 ` Chao Yu
2026-07-08 6:03 ` Anand Suveer Jain
2026-07-17 10:47 ` Zorro Lang
2026-07-21 23:56 ` Anand Suveer Jain
2026-07-27 17:50 ` Zorro Lang
2026-07-23 9:09 ` Chao Yu
2026-07-27 17:57 ` Zorro Lang
2026-07-28 2:24 ` Chao Yu
2026-07-28 6:49 ` Zorro Lang [this message]
2026-07-29 9:50 ` Chao Yu
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=amhKovVDjwawoWdQ@zlang-mailbox \
--to=zlang@kernel.org \
--cc=asj@kernel.org \
--cc=chao@kernel.org \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/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