Messages in this thread | | | Subject | Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9] | From | Andy Lutomirski <> | Date | Thu, 12 Jul 2018 17:24:36 -0700 |
| |
> On Jul 12, 2018, at 5:03 PM, David Howells <dhowells@redhat.com> wrote: > > Andy Lutomirski <luto@amacapital.net> wrote: > >>>> 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.
| |