Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

Zorro Lang <[email protected]> Mon, 20 Jul 2026 03:15:47 +0800
Newsgroups org.kernel.vger.fstests,org.kernel.vger.linux-fsdevel
Message-ID <al0d2btWzQaFmcI5@zlang-mailbox>
On Sun, Jul 19, 2026 at 12:52:50PM -0400, Theodore Tso wrote:
> On Sun, Jul 19, 2026 at 11:57:04PM -0500, Zorro Lang wrote:
> > Thank you for your reply. You are right. I was just listing some
> > possible options, and I did not mean we must change the kernel for
> > testing. Changing the kernel just for a _notrun is indeed not worth
> > it. If there is no simple way to implement the _require_* function,
> > we can `_exclude_fs hfs` directly :)
> 
> I wouldn't necessarily rule out changing the kernel so that file
> systems can declare whether they can support cgroupv2.  The advantage
> is that we wouldn't need to keep adding "_exclude_fs xxx" each time we
> try to make fstets work on the simpler file systems.  It also means
> that if a file system adds support for cgroupv2, we wouldn't need to
> change fstests --- also, if the patch gets backported to an older
> kernel (either an LTS or an enterprise distro kernel) we don't need to
> try to modulate the _exclude_fs using kernel version numbers (which
> isn't guaranteed to work given the backporting possibility).

Sure, hardcoding a _notrun based on FSTYP is a last resort, and it would
definitely be better if we had a more elegant way to trigger the _notrun.
As a test suite, I cannot enforce or dictate what features a specific
filesystem must export just for the convenience of testing :)

> 
> This is a philosophical issue, and reasonable people could disagree on
> this approach.  For my part, I created /sys/fs/ext4/features/*
> precisely so that userspace (and fstests) so we can test if a
> particular feature is available on a particular kernel.  Otherwise, a
> test to see whether a particular feature "works" might have a false
> positive if the feature is broken, and the way we test whether the
> feature is present is basically what was accidentally broken with by a
> regression.

/sys/fs/$FSTYP/features/ is indeed incredibly helpful! Just a couple of
days ago, I was actually discussing expanding _require_fs_sysfs to support
features/ checks there, since our current checks are limited to the
/sys/fs/$FSTYP/$device/ directory:

https://lore.kernel.org/fstests/aloCfjjqesxpzL9z@zlang-mailbox/T/#mc5a0492cc00550467256951042828bef5d7fa38d

Thanks,
Zorro

> 
> Cheers,
> 
> 					- Ted
>