Re: [9fans] create/create race

[Giacomo Tesio]

Thanks Charles! This is exactly the kind of info I was looking for.


Giacomo

2016-11-30 22:53 GMT+01:00 Charles Forsyth :

>
> On 30 November 2016 at 21:51, Charles Forsyth 
> wrote:
>
>> that the whole path name is re-evaluated 3 times
>
>
> That doesn't happen with the current implementation, because it walks to
> the parent directory, does the create/open etc at that point with a
> reference held.
>

Re: [9fans] create/create race

[Charles Forsyth]

On 30 November 2016 at 21:51, Charles Forsyth 
wrote:

> that the whole path name is re-evaluated 3 times


That doesn't happen with the current implementation, because it walks to
the parent directory, does the create/open etc at that point with a
reference held.

Re: [9fans] create/create race

[cinap_lenrek]

> Well not exactly: I will use the new create syscall (without OEXCL support)
> when I need such level of control and use ocreate with OEXCL when I do not
> care about the race and want a "create or truncate" default behaviour.

this makes no sense to me. the whole point of create with OEXCL is that
it is atomic and it will *NOT* try to truncate-open the file when it already
exist. OEXCL means just sending the Tcreate and nothing else. why is that not
already what you try todo with your new create syscall?

can you please state the problem that you are trying to fix?

--
cinap

Re: [9fans] create/create race

[Charles Forsyth]

On 30 November 2016 at 15:28, Giacomo Tesio  wrote:

> I will use the new create syscall (without OEXCL support) when I need such
> level of control and use ocreate with OEXCL


Perhaps I'm confused. I thought OEXCL was just the same as the 9P create,
which is what you were trying to get.
With OEXCL set, it tries Tcreate; if that fails, it stops, and doesn't try
open-with-truncate etc.

Re: [9fans] create/create race

[Giacomo Tesio]

2016-11-30 16:08 GMT+01:00 Charles Forsyth :

>
> On 30 November 2016 at 15:02, Giacomo Tesio  wrote:
>
>>
>> But reading that thread I can't actually see why the OEXCL path has been
>> taken instead of eliminating the race mapping the syscall to the 9p message.
>> I mean except backward compatibility.
>>
>
> I suppose you'll find out, but I'd expect that all but a handful of
> instances want the existing effect and are untroubled by any potential race.
> Given that OEXCL then seems to handle the handful, it seems a reasonable
> approach.
> The ocreate would just put the race in a different place, wouldn't it?
>

Well not exactly: I will use the new create syscall (without OEXCL support)
when I need such level of control and use ocreate with OEXCL when I do not
care about the race and want a "create or truncate" default behaviour.

But actually, I cannot see a use case where the create(2) default behaviour
can be *wanted*.
I just see many use case where it can be tollerated: the create can fail
anyway for other reasons so it does not add much complexity to the client...
But I'm probably missing something obvious: can you provide an example
where not having the truncate fallback in the syscall actually break the
program or introduce a bug. It's exactly what I'm looking for.


Giacomo

Re: [9fans] create/create race

[Charles Forsyth]

On 30 November 2016 at 15:02, Giacomo Tesio  wrote:

>
> But reading that thread I can't actually see why the OEXCL path has been
> taken instead of eliminating the race mapping the syscall to the 9p message.
> I mean except backward compatibility.
>

I suppose you'll find out, but I'd expect that all but a handful of
instances want the existing effect and are untroubled by any potential race.
Given that OEXCL then seems to handle the handful, it seems a reasonable
approach.
The ocreate would just put the race in a different place, wouldn't it?

Re: [9fans] create/create race

[Giacomo Tesio]

David it seem you walked my road already... :-)

I'm actually on a research project, so I do not care too much about the
issues on existing programs. I'm going to change/break them anyway.
Also, as far as I can foresee, it should be viable to fix such programs in
a partially automated way (eg via sed and a new "ocreate" library function
that mimic the current behaviour).

But reading that thread I can't actually see why the OEXCL path has been
taken instead of eliminating the race mapping the syscall to the 9p message.
I mean except backward compatibility.

Maybe it was found a performance issue in some more common use case?
Or a worse race prevented by the current semantic?


For example I've found pretty cryptic this message from David:
http://marc.info/?l=9fans=111558704718797=2

I'm surprised I haven't yet seen "What about union directories?"
>
> If create(2) is changed then it could succeed even though a
> file with that name exists in the union.  Then the above:
>
> if ((fd = create(file, mode, perm)) < 0) {
>   error...
> }
>
> Would need to become:
>
> if ((fd = open(file, mode|OTRUNC)) < 0 ||
> (fd = create(file, mode, perm)) < 0 ||
> (fd = open(file, mode|OTRUNC)) < 0 ||
>   error...
> }
>
> This is precisely the current create(2) call and the nasty
> race is clear.
>
>
Why the initial open() would be needed if create(2) always send a Tcreate?


Giacomo


2016-11-30 14:53 GMT+01:00 Charles Forsyth :

>
> On 30 November 2016 at 13:32,  wrote:
>
>> interesting, the thread starts here:
>>
>> http://marc.info/?l=9fans=111558704718788=2
>>
>
>
> I suspect the discussion predated 9P2000 and the introduction of the OEXCL
> option.
>

Re: [9fans] create/create race

[Charles Forsyth]

On 30 November 2016 at 13:32,  wrote:

> interesting, the thread starts here:
>
> http://marc.info/?l=9fans=111558704718788=2
>


I suspect the discussion predated 9P2000 and the introduction of the OEXCL
option.

Re: [9fans] create/create race

[cinap_lenrek]

> Wow, this is a sore subject. Check the archives of this list for a
> long version of this discussion.
>
> David

interesting, the thread starts here:

http://marc.info/?l=9fans=111558704718788=2

--
cinap

Re: [9fans] create/create race

[G. David Butler]

Wow, this is a sore subject. Check the archives of this list for a long version 
of this discussion.

David

Sent from my phone. Please excuse misspellings and terseness.


> On Nov 30, 2016, at 5:04 AM, Giacomo Tesio  wrote:
> 
> Hi guys, I know this is a noob question, but I'd really like to understand 
> this aspect of the kernel design.
> 
> I'm planning to experiment on the topic, modifying chan.c so that the 
> semantics of create(2) match those of create(5) about existing files. I guess 
> that the number of callers to fix is manageable.
> 
> But since I can't see any good reason for the race being there in the first 
> place (except maybe backward compatibility with unix, but that was not a 
> problem for Plan 9 designers), I'm pretty sure I'm missing something obvious.
> 
> 
> So, please, do you know why the create syscall does not simply return an 
> error if the file already exists?
> You might save me a few headache... 
> 
> 
> Thanks for your help!
> 
> 
> Giacomo
> 
> 
> 
> 2016-05-24 23:25 GMT+02:00 Giacomo Tesio :
>> I'm pretty curious about the create(2)/create(5) race described in a comment 
>> in namec (see 
>> https://github.com/brho/plan9/blob/master/sys/src/9/port/chan.c#L1564-L1603)
>> 
>> Does anyone know or remember the reasoning behind this design?
>> 
>> What was wrong about using the create(5) semantics for the create(2) syscall?
>> 
>> 
>> Giacomo
> 

Re: [9fans] create/create race

[cinap_lenrek]

it is not clear to me what your issue is. the manual clearly states
that you can pass OEXCL to create to get atomic create operation so
in what way are you trying to change the system calls?

  Since create may succeed even if the file exists, a special
  mechanism is necessary for those applications that require
  an atomic create operation.  If the OEXCL (0x1000) bit is
  set in the mode for a create, the call succeeds only if the
  file does not already exist; see open(5) for details.

--
cinap

Re: [9fans] create/create race

[Giacomo Tesio]

Hi guys, I know this is a noob question, but I'd really like to understand
this aspect of the kernel design.

I'm planning to experiment on the topic, modifying chan.c so that the
semantics of create(2) match those of create(5) about existing files. I
guess that the number of callers to fix is manageable.

But since I can't see any good reason for the race being there in the first
place (except maybe backward compatibility with unix, but that was not a
problem for Plan 9 designers), I'm pretty sure I'm missing something
obvious.


So, please, do you know why the create syscall does not simply return an
error if the file already exists?
You might save me a few headache...


Thanks for your help!


Giacomo



2016-05-24 23:25 GMT+02:00 Giacomo Tesio :

> I'm pretty curious about the create(2)/create(5) race described in a
> comment in namec (see https://github.com/brho/plan9/
> blob/master/sys/src/9/port/chan.c#L1564-L1603)
>
> Does anyone know or remember the reasoning behind this design?
>
> What was wrong about using the create(5) semantics for the create(2)
> syscall?
>
>
> Giacomo
>