From: Linus Heckemann <git@sphalerite.org>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] libmount: provide tree fd even when a mount helper is used
Date: Fri, 31 May 2024 16:32:21 +0200 [thread overview]
Message-ID: <yga4jaenjbe.fsf@localhost> (raw)
In-Reply-To: <20240531094125.r2nvmio47itrtzep@ws.net.home>
Karel Zak <kzak@redhat.com> writes:
> On Thu, May 30, 2024 at 08:00:34PM +0200, Linus Heckemann wrote:
>> Previously, the X-mount.subdir option would fail (mount exited with
>> code 0, but the target was not mounted) when a helper was used.
>
> Do you have any examples that can easily reproduce it?
I encountered this issue with bcachefs (create /foo in the root of a
bcachefs filesystem and then attempt to mount that same filesystem with
X-mount.subdir=foo) but the problem should be the same with any
other filesystem that uses a mount helper.
truncate -s 1G test.img
mkfs.bcachefs test.img
mount -o loop,X-mount.mkdir test.img /tmp/mnt
mkdir /tmp/mnt/foo
umount /tmp/mnt
mount -o loop,X-mount.subdir=foo test.img /tmp/mnt
Without my patch, this exits with status code 0 but does not result in
/tmp/mnt being mounted at all.
>> In addition to fixing X-mount.subdir, this allows dropping the
>> fallback behaviour previously implemented specifically by the
>> set_vfsflags and set_propagation hooks.
>>
>> I realise this patch is not acceptable as is, since I just exported
>> the previously private open_mount_tree symbol from hook_mount.c
>
> Perhaps it is unnecessary to only keep the API file descriptors in
> hook_mount.c. It is a generic feature and we may see more use
> cases where it would make sense to use it in other places.
>
> I can imagine having the file descriptors in the libmnt_context
> structure and initializing them through functions in context.c (which
> would involve renaming open_mount_tree() to something more
> appropriate). It could potentially be a public library function so
> that libmount applications can also utilize it.
>
> I will think about it :-)
Thanks! That sounds like it would make sense, though I'd expect (naively
-- I'm not super familiar with the overall code) it's generally not
desirable to use that function as opposed to using the mount fd from the
context once it's become available through the mount step? I don't see a
particularly strong case for using that and not open_tree directly.
next prev parent reply other threads:[~2024-05-31 14:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 18:00 [PATCH] libmount: provide tree fd even when a mount helper is used Linus Heckemann
2024-05-31 9:41 ` Karel Zak
2024-05-31 14:32 ` Linus Heckemann [this message]
2024-06-03 11:20 ` Karel Zak
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=yga4jaenjbe.fsf@localhost \
--to=git@sphalerite.org \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/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).