lkml.org 
[lkml]   [2018]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From
Date


> 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.
\
 
 \ /
  Last update: 2018-07-15 22:06    [W:0.099 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site