Linux-f2fs-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: 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: [f2fs-dev] [PATCH v2] common/rc: support f2fs in _require_fanotify_ioerrors()
Date: Wed, 29 Jul 2026 17:50:49 +0800	[thread overview]
Message-ID: <0b5f2dc2-ae67-4d3e-b5ea-9edf43b4f357@kernel.org> (raw)
In-Reply-To: <amhKovVDjwawoWdQ@zlang-mailbox>

On 7/28/26 14:49, Zorro Lang wrote:
> 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?

Have sent v3, please take a look. :)

Thanks,

> 
> 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"
>>>>>>>
>>>>>>
>>>>
>>>>
>>



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

      reply	other threads:[~2026-07-29  9:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06  6:43 [f2fs-dev] [PATCH v2] common/rc: support f2fs in _require_fanotify_ioerrors() Chao Yu via Linux-f2fs-devel
2026-07-07 10:13 ` Anand Suveer Jain via Linux-f2fs-devel
2026-07-08  3:25   ` Chao Yu via Linux-f2fs-devel
2026-07-08  6:03     ` Anand Suveer Jain via Linux-f2fs-devel
2026-07-17 10:47     ` Zorro Lang via Linux-f2fs-devel
2026-07-21 23:56       ` Anand Suveer Jain via Linux-f2fs-devel
2026-07-27 17:50         ` Zorro Lang via Linux-f2fs-devel
2026-07-23  9:09       ` Chao Yu via Linux-f2fs-devel
2026-07-27 17:57         ` Zorro Lang via Linux-f2fs-devel
2026-07-28  2:24           ` Chao Yu via Linux-f2fs-devel
2026-07-28  6:49             ` Zorro Lang via Linux-f2fs-devel
2026-07-29  9:50               ` Chao Yu via Linux-f2fs-devel [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=0b5f2dc2-ae67-4d3e-b5ea-9edf43b4f357@kernel.org \
    --to=linux-f2fs-devel@lists.sourceforge.net \
    --cc=asj@kernel.org \
    --cc=chao@kernel.org \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=jaegeuk@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox