All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
	Jan Kara <jack@suse.cz>, Allison Karlitskaya <lis@redhat.com>
Subject: Re: [PATCH 1/2] mount: fix detached mount regression
Date: Wed, 11 Jun 2025 18:29:45 +0100	[thread overview]
Message-ID: <20250611172945.GK299672@ZenIV> (raw)
In-Reply-To: <20250611-denkpause-wegrand-6eb6647dab77@brauner>

On Wed, Jun 11, 2025 at 11:36:43AM +0200, Christian Brauner wrote:

> Sigh. There's no need to get all high and mighty about this. For once I
> actually do write extensive selftests and they do actually catch a lot
> of bugs. It's a joke how little selftests we have given the importance
> of our apis. Nobody ever gives a flying fsck to review selftests when
> they're posted because nobody seems to actually care.

Not quite - for me the problem is more on the logistics side; xfstests
is a lot more convenient in that respect.  To be serious, the main
problems are
	1) many selftests have non-trivial dependencies on config
and spew a lot of noise when run on different configs.
	2) very much oriented to case when kernel tree (with build already
done) sitting on the box where they are going to be run.  Sure, I can
tar c .|ssh kvm.virt "mkdir /tmp/linux; cd /tmp/linux; tar x ." and
then make kselftest there, but it's still a headache.
	3) unlike e.g. xfstests and ltp, you don't get a convenient
summary of the entire run.

None of that is fatal, obviously, just bloody annoying to deal with at 4am...
Yes, I know how to use TARGETS, etc., but IME a test in xfstests is less
of a headache on my setup.

> > IMO that kind of stuff should be dealt with by creating a temporary directory
> > somewhere in /tmp, mounting tmpfs on it, then doing all creations, etc.
> > inside that.  Then umount -l /tmp/<whatever>; rmdir /tmp/<whatever> will
> > clean the things up.
> 
> Sorry, that's just wishful thinking at best and out of touch with how
> these apis are used. The fact that you need a private assembly in some
> hidden away directory followed by a umount is a complete waste of system
> calls for a start. It's also inherently unclean unless you also bring
> mount namespaces into the mix. Being able to use detached mount trees is
> simple and clean especially for the overlayfs layer case.

Huh?  I'm talking about the easy-of-teardown for reproducers, nothing else.
And the way I'd described above _is_ trivial to set up and tear down cleanly...

  reply	other threads:[~2025-06-11 17:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05 12:50 [PATCH 0/2] mount: fix detached mount regression Christian Brauner
2025-06-05 12:50 ` [PATCH 1/2] " Christian Brauner
2025-06-06  4:54   ` Al Viro
2025-06-06  5:14     ` Al Viro
2025-06-06  7:01       ` Al Viro
2025-06-06  7:58         ` Christian Brauner
2025-06-06 17:45           ` Al Viro
2025-06-07  5:20             ` Al Viro
2025-06-11  9:36               ` Christian Brauner
2025-06-11 17:29                 ` Al Viro [this message]
2025-06-12 12:16                   ` Christian Brauner
2025-06-05 12:50 ` [PATCH 2/2] selftests/mount_setattr: adapt detached mount propagation test Christian Brauner

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=20250611172945.GK299672@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lis@redhat.com \
    --cc=miklos@szeredi.hu \
    /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.