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@xxxxxxxxxx> http://karelzak.blogspot.com
