On Wed, Jan 16, 2019 at 02:06:49PM -0800, Matthew Wilcox wrote: > On Wed, Jan 16, 2019 at 02:42:32PM -0700, Jason Gunthorpe wrote: > > On Wed, Jan 16, 2019 at 01:12:27PM -0800, Matthew Wilcox wrote: > > > > > > I don't think the comment explaining why the aglorithm is so special > > > > should be deleted :) > > > > > > Fair, but I think it's in the wrong place. It should be up with the > > > definition of RESERVED_PIDS, and it should probably say why! How about this: > > > > > > /* > > > * We avoid reusing PIDs below this to prevent user processes receiving > > > * signals which are intended for system daemons. > > > */ > > > #define RESERVED_PIDS 300 > > > > This is better, yes.. I assume this old behavior is to support old > > init systems that rely on pid files and might experience a race when a > > daemon dies if a new process is re-spawned into the old pid? > > Possibly ... I always heard it was for the purpose of signals, but some > greybeard might be able to enlighten us. signals based on pid files, I think :) > > > /* Allow allocation below RESERVED_PID the first time */ > > > if (min > tmp->last_pid) > > > min = tmp->last_pid; > > > > Not min = 1? > > I don't think it matters, does it? Just seems clearer for the reader that this range is 1 based and not rely on a tricky initialization of last_pid = 1 at the start to know this. Jason
