dup3 syscall - atomic set O_CLOEXEC with dup2

[Eitan Adler]

Thank you for your comments. I will hopefully have version 2 of the
diff tonight.

On Thu, Jan 12, 2012 at 4:56 AM, Ed Schouten <ed at 80386.nl> wrote:
> I suspect that not long after we add dup3(), some random person asks us
> to implement F_DUP3FD. Any chance you can implement this without using a
> system call, but through fcntl()?

The goal is to be atomic with the duplication.


On Thu, Jan 12, 2012 at 5:08 AM, Kostik Belousov <kostikbel at gmail.com> wrote:
> makesyscalls.sh. This makes me seriosly wonder was the patch compiled at
> all.

It was compiled and tested in a virtual machine. I did however
generate this diff differently than the one I tested (I applied my git
diff against svn and used the svn diff here) so I may have missed
something when doing that.

>> +
>> +     return (do_dup(td, dupflags, (int)uap->from, (int)uap->to,
>> +                 td->td_retval));
> Why casting arguments to int ?

I stole this line from sys_dup2.

>> +     return (0);
> Isn't this line never executed ?

Yes, this was leftover of some previous version.

>> +}
>> +
>> +/*
>>   * Duplicate a file descriptor to a particular value.
>>   *
>>   * Note: keep in mind that a potential race condition exists when closing
>> @@ -912,6 +945,9 @@
>>               fdp->fd_lastfile = new;
>>       *retval = new;
>>
>> +     if (flags & DUP_CLOEXEC)
>> +             fdp->fd_ofileflags[new] |= UF_EXCLOSE;
>> +
> It is better to handle UF_EXCLOSE at the time of assignment to
> fdp->fd_ofileflags[new] just above, instead of clearing UF_EXCLOSE
> and then setting it.
>

> That said, I am not sure that we shall copy the O_CLOEXEC crusade from
> Linux until it is standartized. And, if copying, I think we shall copy
> all bits of the new API, like SOCK_CLOEXEC etc, and not just dup3.

If it is standardized I can't see how it will have semantics that
differ from the current Linux version and IMHO this is a worthwhile
thing to add.

> Oh, and it misses the versioning for the new syscall symbols in libc.
> The symbols not listed in the Symbol.maps are made local during the
> final linkage.

Cut me a bit slack, this is my first attempt at adding a syscall ;)




-- 
Eitan Adler