9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] create/create race
@ 2016-05-24 21:25 Giacomo Tesio
  2016-11-30 11:04 ` Giacomo Tesio
  0 siblings, 1 reply; 15+ messages in thread
From: Giacomo Tesio @ 2016-05-24 21:25 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 495 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-05-24 21:25 [9fans] create/create race Giacomo Tesio
@ 2016-11-30 11:04 ` Giacomo Tesio
  2016-11-30 11:19   ` cinap_lenrek
  2016-11-30 13:14   ` G. David Butler
  0 siblings, 2 replies; 15+ messages in thread
From: Giacomo Tesio @ 2016-11-30 11:04 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

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 <giacomo@tesio.it>:

> 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
>

[-- Attachment #2: Type: text/html, Size: 1888 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 11:04 ` Giacomo Tesio
@ 2016-11-30 11:19   ` cinap_lenrek
  2016-11-30 13:14   ` G. David Butler
  1 sibling, 0 replies; 15+ messages in thread
From: cinap_lenrek @ 2016-11-30 11:19 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 11:04 ` Giacomo Tesio
  2016-11-30 11:19   ` cinap_lenrek
@ 2016-11-30 13:14   ` G. David Butler
  2016-11-30 13:32     ` cinap_lenrek
  1 sibling, 1 reply; 15+ messages in thread
From: G. David Butler @ 2016-11-30 13:14 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

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 <giacomo@tesio.it> 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 <giacomo@tesio.it>:
>> 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
> 

[-- Attachment #2: Type: text/html, Size: 2630 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 13:14   ` G. David Butler
@ 2016-11-30 13:32     ` cinap_lenrek
  2016-11-30 13:53       ` Charles Forsyth
  0 siblings, 1 reply; 15+ messages in thread
From: cinap_lenrek @ 2016-11-30 13:32 UTC (permalink / raw)
  To: 9fans

> 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&m=111558704718788&w=2

--
cinap



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 13:32     ` cinap_lenrek
@ 2016-11-30 13:53       ` Charles Forsyth
  2016-11-30 15:02         ` Giacomo Tesio
  0 siblings, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2016-11-30 13:53 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On 30 November 2016 at 13:32, <cinap_lenrek@felloff.net> wrote:

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


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

[-- Attachment #2: Type: text/html, Size: 721 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 13:53       ` Charles Forsyth
@ 2016-11-30 15:02         ` Giacomo Tesio
  2016-11-30 15:08           ` Charles Forsyth
  0 siblings, 1 reply; 15+ messages in thread
From: Giacomo Tesio @ 2016-11-30 15:02 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

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&m=111558704718797&w=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 <charles.forsyth@gmail.com>:

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

[-- Attachment #2: Type: text/html, Size: 3372 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 15:02         ` Giacomo Tesio
@ 2016-11-30 15:08           ` Charles Forsyth
  2016-11-30 15:28             ` Giacomo Tesio
  0 siblings, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2016-11-30 15:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On 30 November 2016 at 15:02, Giacomo Tesio <giacomo@tesio.it> 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?

[-- Attachment #2: Type: text/html, Size: 1026 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 15:08           ` Charles Forsyth
@ 2016-11-30 15:28             ` Giacomo Tesio
  2016-11-30 15:34               ` Charles Forsyth
  2016-11-30 15:40               ` cinap_lenrek
  0 siblings, 2 replies; 15+ messages in thread
From: Giacomo Tesio @ 2016-11-30 15:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

2016-11-30 16:08 GMT+01:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 30 November 2016 at 15:02, Giacomo Tesio <giacomo@tesio.it> 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

[-- Attachment #2: Type: text/html, Size: 2343 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 15:28             ` Giacomo Tesio
@ 2016-11-30 15:34               ` Charles Forsyth
  2016-11-30 15:40               ` cinap_lenrek
  1 sibling, 0 replies; 15+ messages in thread
From: Charles Forsyth @ 2016-11-30 15:34 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On 30 November 2016 at 15:28, Giacomo Tesio <giacomo@tesio.it> 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.

[-- Attachment #2: Type: text/html, Size: 732 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 15:28             ` Giacomo Tesio
  2016-11-30 15:34               ` Charles Forsyth
@ 2016-11-30 15:40               ` cinap_lenrek
  2016-11-30 16:16                 ` Giacomo Tesio
  1 sibling, 1 reply; 15+ messages in thread
From: cinap_lenrek @ 2016-11-30 15:40 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 15:40               ` cinap_lenrek
@ 2016-11-30 16:16                 ` Giacomo Tesio
  2016-11-30 21:51                   ` Charles Forsyth
  0 siblings, 1 reply; 15+ messages in thread
From: Giacomo Tesio @ 2016-11-30 16:16 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

2016-11-30 16:40 GMT+01:00 <cinap_lenrek@felloff.net>:

> 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?
>

Well, describing the whole picture would take a while (and would move the
thread topic to other unusual aspects of its design), but one of the reason
that can explain my question is that I want to simplify the kernel code as
much as possible, moving to user space all that can be moved without
affecting the system security.
In the end I'd like to get few orthogonal syscalls, so that you cannot
obtain the exact effect of one in term of 2 or more other.

I know that this seem a bit theoretical, but it's just a starting point and
has a lot of really pragmatic implications in my research project.
Stated in a different way, I want to keep it simple, and user space code is
usually simpler than kernel space code.


Btw, actually, I'm not proposing a change to Plan 9 or debating about its
design.
I'm just asking about the reasoning behind this specific choice, because I
guess that it's deeper than it seem (so much that I cannot grasp it by
reading the code).


Also I'm looking for "instances that *want* the existing effect", as
Charles perfectly described them, something that break without it, so that
I can dive deeper into the matter.


Giacomo

[-- Attachment #2: Type: text/html, Size: 2333 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 16:16                 ` Giacomo Tesio
@ 2016-11-30 21:51                   ` Charles Forsyth
  2016-11-30 21:53                     ` Charles Forsyth
  0 siblings, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2016-11-30 21:51 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

On 30 November 2016 at 16:16, Giacomo Tesio <giacomo@tesio.it> wrote:

> Also I'm looking for "instances that *want* the existing effect", as
> Charles perfectly described them, something that break without it, so that
> I can dive deeper into the matter.


cat >x
x: already exists
rm x
cat >x
 # different race
mk x
cp x /tmp/x
x: already exists
rm x
 # this is getting tedious

ed x
1342
$a
hello world
.
w
?exists
!rm x
!
w
1354

basically, most programs or uses that save, copy or update data to a named
file are replacing the contents, so "make sure name exists and truncate it"
is the most common case, isn't it? There's no particular reason that
couldn't be done by a user-level library call,
create, that ran the three two or three primitive syscalls in sequence. The
applications just want the wretched thing there and empty.
(This is separate from some notion of file versioning, which could be done
by close, making the create/trunc+update replacement action atomic.)
Mind you, the 3 syscall version adds a more subtle race, which is that the
whole path name is re-evaluated 3 times, which opens
up the possibility of a name space change higher up changing the meaning a
different way. Still even that is not very likely in practice.

[-- Attachment #2: Type: text/html, Size: 3021 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 21:51                   ` Charles Forsyth
@ 2016-11-30 21:53                     ` Charles Forsyth
  2016-11-30 23:15                       ` Giacomo Tesio
  0 siblings, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2016-11-30 21:53 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

On 30 November 2016 at 21:51, Charles Forsyth <charles.forsyth@gmail.com>
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.

[-- Attachment #2: Type: text/html, Size: 592 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] create/create race
  2016-11-30 21:53                     ` Charles Forsyth
@ 2016-11-30 23:15                       ` Giacomo Tesio
  0 siblings, 0 replies; 15+ messages in thread
From: Giacomo Tesio @ 2016-11-30 23:15 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

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


Giacomo

2016-11-30 22:53 GMT+01:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 30 November 2016 at 21:51, Charles Forsyth <charles.forsyth@gmail.com>
> 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.
>

[-- Attachment #2: Type: text/html, Size: 1090 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2016-11-30 23:15 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-24 21:25 [9fans] create/create race Giacomo Tesio
2016-11-30 11:04 ` Giacomo Tesio
2016-11-30 11:19   ` cinap_lenrek
2016-11-30 13:14   ` G. David Butler
2016-11-30 13:32     ` cinap_lenrek
2016-11-30 13:53       ` Charles Forsyth
2016-11-30 15:02         ` Giacomo Tesio
2016-11-30 15:08           ` Charles Forsyth
2016-11-30 15:28             ` Giacomo Tesio
2016-11-30 15:34               ` Charles Forsyth
2016-11-30 15:40               ` cinap_lenrek
2016-11-30 16:16                 ` Giacomo Tesio
2016-11-30 21:51                   ` Charles Forsyth
2016-11-30 21:53                     ` Charles Forsyth
2016-11-30 23:15                       ` Giacomo Tesio

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).