Messages in this thread | | | Date | Thu, 10 Jun 2010 14:04:25 -0700 | Subject | Re: [PATCH] Fix a race in pid generation that causes pids to be reused immediately. | From | Salman Qazi <> |
| |
On Thu, Jun 10, 2010 at 1:38 PM, <tytso@mit.edu> wrote: > On Thu, Jun 10, 2010 at 01:09:11PM -0700, Salman wrote: >> A program that repeatedly forks and waits is susceptible to having the >> same pid repeated, especially when it competes with another instance of the >> same program. This is really bad for bash implementation. Furthermore, many shell >> scripts assume that pid numbers will not be used for some length of time. > > This should probably get wrapped at column 74 or so.... > >> +static int pid_before(int base, int a, int b) >> +{ >> + /* >> + * This is the same as saying >> + * >> + * (a - base + MAXUINT) % MAXUINT < (b - base + MAXUINT) % MAXUINT >> + * and that mapping orders 'a' and 'b' with respect to 'base'. >> + * >> + */ >> + return (unsigned)(a - base) < (unsigned)(b - base); >> +} > > Does this work though if /proc/sys/kernel/pid_max is not set to > MAXUINT?
Yes it does. It should work for all values of pid_max. > > I like the optimization, but it looks like pid_max defaults to 4096 if > CONFIG_BASE_SMALL is set, and 32768 otherwise. > > Am I missing something?
Yes.
(a - base + pid_max) % pid_max < (b - base + max_pid) % pid_max iff (a - base + MAXUINT) % MAXUINT < (b - base + MAXUINT) % MAXUINT for all pid_max <= MAXUINT.
The values of 'a' (or 'b') in the range [base, pid_max) gets mapped to [0, pid_max - base) and the range [0, base) gets mapped to [MAXUINT, MAXUINT - base). So, the order is essentially maintained by this mapping.
> > - Ted > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |