From: Karel Zak <kzak@redhat.com>
To: Thomas Deutschmann <whissi@whissi.de>
Cc: util-linux@vger.kernel.org
Subject: Re: util-linux 2.39 doesn't work with <linux-5.12: mount(2) system call failed: Function not implemented
Date: Mon, 22 May 2023 16:55:45 +0200 [thread overview]
Message-ID: <20230522145545.s5q3h4kefman36on@ws.net.home> (raw)
In-Reply-To: <d9b49d0a-c7eb-e110-ca71-e621df4a52cf@whissi.de>
On Mon, May 22, 2023 at 04:09:28PM +0200, Thomas Deutschmann wrote:
> Hi,
>
> On 2023-05-22 09:43, Thomas Weißschuh wrote:
> > I was finally able to reproduce the issue.
> >
> > Could you test https://github.com/util-linux/util-linux/pull/2248 again?
>
> This fixes the issue for me, thank you!
>
> Just one comment regarding the design of the fix:
>
> Due to the introduction of mount_setattr_is_supported(), util-linux will now
> "waste" one syscall on every mount -- even on a modern system -- right?
>
> A more "natural" approach like calling new API first but when this will fail
> with ENOSYS then fallback to old API (so we would only spend an additional
> call on old systems which is fine because we assume that their number will
> decrease over time) cannot be implemented due to the way how the hook system
> works, right?
>
> But maybe this "wasted" call isn't much to think about. I was just wondering
> when I saw a call like
>
> mount_setattr(-1, NULL, 0, NULL, 0)
>
> even on modern systems.
The problem is that the new API is not 1:1 with the old API. The new
API is more complex and requires open mount node/fs, preparing mount
options differently, more syscalls, etc. IMHO, it will be a
maintenance nightmare to use "if (ENOSYS) old_way()" for all use
cases.
Maybe it's not optimal for performance, but I have split libmount to
separate modules and legacy mount and new mount API are completely
separated. There is always a "prepare" stage when the module analyzes
the mount options, initializes resources (open_tree(), etc.) and if
the new API is unsuccessful (ENOSYS) in this sage, then it disables
the whole module, and the legacy module can detect it and start to
play its role.
The extra syscall (for remount in this case) is not a big problem (I
think).
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
prev parent reply other threads:[~2023-05-22 14:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-20 0:54 util-linux 2.39 doesn't work with <linux-5.12: mount(2) system call failed: Function not implemented Thomas Deutschmann
2023-05-20 4:51 ` Thomas Weißschuh
2023-05-20 15:23 ` Thomas Deutschmann
2023-05-20 23:39 ` Thomas Weißschuh
2023-05-21 22:13 ` Thomas Deutschmann
2023-05-22 7:43 ` Thomas Weißschuh
2023-05-22 14:09 ` Thomas Deutschmann
2023-05-22 14:55 ` Karel Zak [this message]
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=20230522145545.s5q3h4kefman36on@ws.net.home \
--to=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
--cc=whissi@whissi.de \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).