Re: [RFC] Subtle race in dup2() and permissions on /proc/<pid>/fd/<n>

Alexander Viro (viro@math.psu.edu)
Thu, 24 Jun 1999 21:46:39 -0400 (EDT)


On Fri, 25 Jun 1999, Guest section DW wrote:

> Such things are not forbidden.
>
> The Rationale says:
>
> The dup2() function is not intended for use in critical regions as a
> synchronization mechanism.
>
> and
>
> Least obvious is the possible effect of a signal-catching function that could
> be invoked between steps and allocate or deallocate file descriptors.

OK. I'm taking the 'implementation dependent' as permission to
make it atomic. It's more sensible behaviour and we can trivially do it
(moreover, doing it that way makes SMP-safe version much easier). So if
doing the thing atomic is not prohibited I'll go for it. Clearly program
can't *rely* on (heavily timing-dependent) race taking place ;-) So that
will not break anything.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/