On Tue, Nov 6, 2018 at 1:05 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Mon 05-11-18 13:22:05, Daniel Colascione wrote: >> State explicitly that holding a /proc/pid file descriptor open does >> not reserve the PID. Also note that in the event of PID reuse, these >> open file descriptors refer to the old, now-dead process, and not the >> new one that happens to be named the same numeric PID. > > This sounds quite obvious Many people *on* *LKML* were wrong about this behavior. If it's not obvious to experienced kernel developers, it's certainly not obvious to the public. > otherwise anybody could simply DoS the system > by consuming all available pids. People can do that today using the instrument of terror widely known as fork(2). The only thing standing between fork(2) and a full process table is RLIMIT_NPROC. In a world where we really did reserve a numeric PID through the lifetime of any struct pid to which it refers (i.e., where "cd /proc/$PID" held $PID), we could charge these struct pid reservations against RLIMIT_NPROC and achieve behavior as safe as what we have today. The details would be subtle (you'd have to take pains to avoid double-counting, for example), but it could be made to work. Other people, on the various lkml threads about my process API improvement proposals, have proposed fixing the longstanding PID race problem by making struct pid behave the way people mistakenly believe it behaves today. It's a serious idea worth actual consideration.
