Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]

On Jul 12, 2018, at 5:03 PM, David Howells [off-list ref] wrote:

Andy Lutomirski [off-list ref] wrote:

quoted

quoted

quoted

I tend to think that this *should* fail using the new API.  The semantics
of the second mount request are bizarre at best.

You still have to support existing behaviour lest you break userspace.

I assume the existing behavior is that a bind mount is created?  If so, the
new mount(8) tool could do it in user code.

You have a race there.

Also you can't currently directly create a bind mount from userspace as you
can only bind from another path point - which you may not be able to access
(either by permission failure or because it's not in your mount namespace).

Are you trying to preserve the magic bind semantics with the new API?  If you are, I think it should be by explicit opt in only. Otherwise you risk having your shiny new way to specify fs options get ignored when the magic bind mount happens.