On Wed, Jun 05, 2024 at 03:28:55AM +0100, Al Viro wrote: > dup2(old, new) has an unpleasant corner case - when new has been > already reserved by e.g. open() from another thread, but that open() > still didn't get to installing an opened file to that descriptor. > > It's outside of POSIX scope and any userland code that might > run into it is buggy. However, we need to make sure that nothing breaks > kernel-side. We used to have interesting bugs in that area and so did > *BSD kernels. > > Current solution is to have dup2() fail with -EBUSY. However, > there's an approach that might avoid that wart. I'm not sure whether > it's worth bothering with - it will have a cost, but then it might reduce > the pingpong on current->files->file_lock. Fwiw, doesn't seem worth the trouble and would likely just complicate things for something that we've never really heard being a problem.
