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 01:57:02 +0800 [thread overview]
Message-ID: <ameajJf8iiAQYWA3@zlang-mailbox> (raw)
In-Reply-To: <a081f7cf-bd47-459d-baee-de772d816af4@kernel.org>
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.
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"
> >>>
> >>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Zorro Lang via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Chao Yu <chao@kernel.org>
Cc: jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net,
"Darrick J. Wong" <djwong@kernel.org>,
fstests@vger.kernel.org, Anand Suveer Jain <asj@kernel.org>
Subject: Re: [f2fs-dev] [PATCH v2] common/rc: support f2fs in _require_fanotify_ioerrors()
Date: Tue, 28 Jul 2026 01:57:02 +0800 [thread overview]
Message-ID: <ameajJf8iiAQYWA3@zlang-mailbox> (raw)
In-Reply-To: <a081f7cf-bd47-459d-baee-de772d816af4@kernel.org>
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.
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"
> >>>
> >>
>
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2026-07-27 17:57 UTC|newest]
Thread overview: 24+ 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-06 6:43 ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-07-07 10:13 ` Anand Suveer Jain via Linux-f2fs-devel
2026-07-07 10:13 ` Anand Suveer Jain
2026-07-08 3:25 ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
2026-07-08 3:25 ` Chao Yu
2026-07-08 6:03 ` [f2fs-dev] " Anand Suveer Jain via Linux-f2fs-devel
2026-07-08 6:03 ` Anand Suveer Jain
2026-07-17 10:47 ` [f2fs-dev] " Zorro Lang via Linux-f2fs-devel
2026-07-17 10:47 ` Zorro Lang
2026-07-21 23:56 ` Anand Suveer Jain
2026-07-21 23:56 ` [f2fs-dev] " Anand Suveer Jain via Linux-f2fs-devel
2026-07-27 17:50 ` Zorro Lang
2026-07-27 17:50 ` [f2fs-dev] " Zorro Lang via Linux-f2fs-devel
2026-07-23 9:09 ` Chao Yu via Linux-f2fs-devel
2026-07-23 9:09 ` Chao Yu
2026-07-27 17:57 ` Zorro Lang [this message]
2026-07-27 17:57 ` [f2fs-dev] " Zorro Lang via Linux-f2fs-devel
2026-07-28 2:24 ` Chao Yu via Linux-f2fs-devel
2026-07-28 2:24 ` Chao Yu
2026-07-28 6:49 ` [f2fs-dev] " Zorro Lang via Linux-f2fs-devel
2026-07-28 6:49 ` Zorro Lang
2026-07-29 9:50 ` Chao Yu
2026-07-29 9:50 ` [f2fs-dev] " Chao Yu via Linux-f2fs-devel
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=ameajJf8iiAQYWA3@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 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.