linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Karel Zak <kzak@redhat.com>
Cc: "Amir Goldstein" <amir73il@gmail.com>,
	"Zorro Lang" <zlang@redhat.com>,
	linux-unionfs@vger.kernel.org, fstests@vger.kernel.org,
	"André Almeida" <andrealmeid@igalia.com>
Subject: Re: [PATCH 1/4] overlay: workaround libmount failure to remount,ro
Date: Wed, 28 May 2025 11:56:48 +0200	[thread overview]
Message-ID: <CAJfpegtJ3SDKmC80B4AfWiC3JmtWdW2+78fRZVtsuhe-wSRPvg@mail.gmail.com> (raw)
In-Reply-To: <rjqagpvze4mwnil6tck6jnyqfbcgqszy5bjgu4fqzdtq7e3idq@uizmifogsqyf>

On Wed, 28 May 2025 at 10:47, Karel Zak <kzak@redhat.com> wrote:

> Anyway, I agree that this semantics sucks, and from my point of view,
> the best approach would be to introduce a new mount(8) command line
> semantics to reflect the new kernel API, something like:
>
>    mount modify [--clear noexec] [--set nodev,ro] [--make-private] [--recursive] /mnt
>    mount reconfigure data=journal,errors=continue,foo,bar /mnt
>
> and do not include options from fstab in this by default.

But there's no fstab entry in the testcase.  The no-fstab case likely
gets way more use in real life then remounting something in fstab.
And this should not need to get the current options from the kernel,
since the kernel is the source of the current options.

With the KISS principle in mind the non-fstab "mount -oremount,ro
/mnt/foo" should just be translated into:

fd = fspick(AT_FDCWD, "/mnt/foo", 0);
fsconfig(fd, FSCONFIG_SET_FLAG, "ro", NULL, 0);
fsconfig(fd, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0);

and the kernel should take care of the rest.  I assume this doesn't
generally work, which is a pity, but I'd still think about salvaging
the concept.

> So, you do not need LIBMOUNT_FORCE_MOUNT2= workaround, use
> "--options-mode ignore" or source and target ;-)

Yeah, that's definitely a better workaround.

I wouldn't call it a fix, since "mount -oremount,ro /overlay" still
doesn't work the way it is supposed to, and the thought of adding code
to the kernel to work around the current libmount behavior makes me go
bleah.

Thanks,
Miklos

  reply	other threads:[~2025-05-28  9:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-26 14:34 [PATCH 0/4] fstests overlay fixes for v2025.05.25 Amir Goldstein
2025-05-26 14:34 ` [PATCH 1/4] overlay: workaround libmount failure to remount,ro Amir Goldstein
2025-05-27 14:48   ` Miklos Szeredi
2025-05-28  6:54     ` Amir Goldstein
2025-05-28  8:47       ` Karel Zak
2025-05-28  9:56         ` Miklos Szeredi [this message]
2025-05-28 10:54           ` Karel Zak
2025-05-28 11:47             ` Miklos Szeredi
2025-05-28 13:13               ` Karel Zak
2025-05-28 13:27                 ` Miklos Szeredi
2025-05-28 10:58           ` Amir Goldstein
2025-05-26 14:34 ` [PATCH 2/4] overlay: fix regression in _repair_overlay_scratch_fs Amir Goldstein
2025-05-26 14:34 ` [PATCH 3/4] generic/604: do not run with overlayfs Amir Goldstein
2025-05-26 14:34 ` [PATCH 3/4] generic/604: opt-out " Amir Goldstein
2025-05-26 14:35 ` [PATCH 4/4] generic/623: do not run " Amir Goldstein
2025-05-26 17:05 ` [PATCH 0/4] fstests overlay fixes for v2025.05.25 André Almeida
2025-05-27  9:11   ` Amir Goldstein

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=CAJfpegtJ3SDKmC80B4AfWiC3JmtWdW2+78fRZVtsuhe-wSRPvg@mail.gmail.com \
    --to=miklos@szeredi.hu \
    --cc=amir73il@gmail.com \
    --cc=andrealmeid@igalia.com \
    --cc=fstests@vger.kernel.org \
    --cc=kzak@redhat.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).