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 >