All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>,
	 "fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	 "slava@dubeyko.com" <slava@dubeyko.com>
Subject: Re: Should we consider disable generic/563 for file systems that do not support cgroup2?
Date: Mon, 20 Jul 2026 03:15:47 +0800	[thread overview]
Message-ID: <al0d2btWzQaFmcI5@zlang-mailbox> (raw)
In-Reply-To: <alz_HixXWhKTIfRV@mit.edu>

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
> 

  reply	other threads:[~2026-07-19 19:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 19:10 Should we consider disable generic/563 for file systems that do not support cgroup2? Viacheslav Dubeyko
2026-07-17 16:19 ` Zorro Lang
2026-07-17 17:42   ` Viacheslav Dubeyko
2026-07-19 14:02   ` Theodore Tso
2026-07-19 15:57     ` Zorro Lang
2026-07-19 16:52       ` Theodore Tso
2026-07-19 19:15         ` Zorro Lang [this message]
2026-07-20  8:07           ` Christoph Hellwig

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=al0d2btWzQaFmcI5@zlang-mailbox \
    --to=zlang@kernel.org \
    --cc=Slava.Dubeyko@ibm.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=tytso@mit.edu \
    /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.