Hi guys, I know this is a noob qu= estion, but I'd really like to understand this aspect of the kernel des= ign.

I'm planning to experiment on the topic, modifying ch= an.c so that the semantics of create(2) match those of create(5) about exis= ting 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 i= n 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 missin= g something obvious.

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

Thanks for y= our help!

Giacomo

2016-05-24 23:25 GMT+02:00 Giacomo Tesio <giacomo@tesio.it>:

I= 9;m pretty curious about the create(2)/create(5) race described in a commen= t in namec (see https://github.com/brho/plan= 9/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) sysc= all?

Giacomo

--001a114a9a30774710054282aca5-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 30 Nov 2016 12:19:21 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af7368ba-ead9-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "G. David Butler" Content-Type: multipart/alternative; boundary=Apple-Mail-A8425A18-E6D6-4412-920A-06BB00CAC476 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 30 Nov 2016 07:14:59 -0600 Message-Id: References:

In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af77af9c-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-A8425A18-E6D6-4412-920A-06BB00CAC476 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Wow, this is a sore subject. Check the archives of this list for a long vers= ion of this discussion. David Sent from my phone. Please excuse misspellings and terseness. > On Nov 30, 2016, at 5:04 AM, Giacomo Tesio wrote: >=20 > Hi guys, I know this is a noob question, but I'd really like to understand= this aspect of the kernel design. >=20 > I'm planning to experiment on the topic, modifying chan.c so that the sema= ntics of create(2) match those of create(5) about existing files. I guess th= at the number of callers to fix is manageable. >=20 > But since I can't see any good reason for the race being there in the firs= t place (except maybe backward compatibility with unix, but that was not a p= roblem for Plan 9 designers), I'm pretty sure I'm missing something obvious.= >=20 >=20 > So, please, do you know why the create syscall does not simply return an e= rror if the file already exists? > You might save me a few headache...=20 >=20 >=20 > Thanks for your help! >=20 >=20 > Giacomo >=20 >=20 >=20 > 2016-05-24 23:25 GMT+02:00 Giacomo Tesio : >> I'm pretty curious about the create(2)/create(5) race described in a comm= ent in namec (see https://github.com/brho/plan9/blob/master/sys/src/9/port/c= han.c#L1564-L1603) >>=20 >> Does anyone know or remember the reasoning behind this design? >>=20 >> What was wrong about using the create(5) semantics for the create(2) sysc= all? >>=20 >>=20 >> Giacomo >=20 --Apple-Mail-A8425A18-E6D6-4412-920A-06BB00CAC476 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

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

Dav= id

Sent from my phone. Please excuse misspel= lings 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 semantic= s of create(2) match those of create(5) about existing files. I guess that t= he number of callers to fix is manageable.

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

So, p= lease, 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...
<= br>
Thanks for your help!

Giacomo<= br>

2016-05-24 23:25 GMT+02:00 Giacomo Tesio <gia= como@tesio.it>:
I'm pretty curious about the create(2)/create(5) race des= cribed in a comment in namec (see https://gith= ub.com/brho/plan9/blob/master/sys/src/9/port/chan.c#L1564-L1603)

Does anyone know or remember the reasoning behind this desig= n?

What was wrong about using the create(5) semantics for the c= reate(2) syscall?

=
Giacomo

= --Apple-Mail-A8425A18-E6D6-4412-920A-06BB00CAC476-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <725518204b6f4564c0a2569e655ac310@felloff.net> Date: Wed, 30 Nov 2016 14:32:28 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af7c03f8-ead9-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <725518204b6f4564c0a2569e655ac310@felloff.net> References: <725518204b6f4564c0a2569e655ac310@felloff.net> From: Charles Forsyth Date: Wed, 30 Nov 2016 13:53:58 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0115ee3c61344e054285097b Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af801bbe-ead9-11e9-9d60-3106f5b1d025 --089e0115ee3c61344e054285097b Content-Type: text/plain; charset=UTF-8 On 30 November 2016 at 13:32, 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. --089e0115ee3c61344e054285097b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

interesting, the thread starts here:

http://marc.info/?l=3D9fans&m=3D111558704718788&w=3D2

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

--089e0115ee3c61344e054285097b-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <725518204b6f4564c0a2569e655ac310@felloff.net> From: Giacomo Tesio Date: Wed, 30 Nov 2016 16:02:56 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11448a3203fd0705428600a9 Subject: Re: [9fans] create/create race Topicbox-Message-UUID: af859062-ead9-11e9-9d60-3106f5b1d025 --001a11448a3203fd0705428600a9 Content-Type: text/plain; charset=UTF-8 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 : > > On 30 November 2016 at 13:32, 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. > --001a11448a3203fd0705428600a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

I'm actually o= n a research project, so I do not care too much about the issues on existin= g 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 "ocre= ate" 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 e= xcept backward compatibility.

Maybe it was found a performance issu= e in some more common use case?
Or a worse race prevented by the curren= t semantic?

For example I'v= e found pretty cryptic this message from David: http://marc.info/?l=3D9fans&= amp;m=3D111558704718797&w=3D2

I'm surprised I haven't yet seen "Wh=
at 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 =3D create(file, mode, perm)) < 0) {
	error...
}

Would need to become:

if ((fd =3D open(file, mode|OTRUNC)) < 0 ||
    (fd =3D create(file, mode, perm)) < 0 ||
    (fd =3D open(file, mode|OTRUNC)) < 0 ||
	error...
}

This is precisely the current create(2) call and the nasty
race is clear.

Why t= he initial open() would be needed if create(2) always send a Tcreate?

Gia= como

2016-11-30 14:53 GMT+01:00 Charles Forsyt= h <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=3D9fans&m=3D11<= wbr>1558704718788&w=3D2

I su= spect the discussion predated 9P2000 and the introduction of the OEXCL opti= on.