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:


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



--001a11448a3203fd0705428600a9--