> On Jul 12, 2018, at 5:03 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > > Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
