>> (amongst other patches). Beware: pretty much experimental and likely to
>> make your linux-pc perform like a win95 platform.
> Well - I'm not sure that this is a good idea. When PIDs increase
> monotonically, chances are very small that the race condition implicit in
> sending any signal to a process results in killing the wrong process (ie,
a
> new process, but with the same PID) - you'd need to zoom through 32000
PIDs
> in a very short time to make this happen.
> With truly random PIDs, there is a much larger chance of a new process
> sitting on a recently used PID.
My code runs trough the whole task_list to see if a chosen pid is already
in use or not.
> What would work is to have cryptographically randomly generated PIDs which
> would then guarantee not to return a previously returned number within
32000
> tries, and also not be predictable - there must be algoritms out there
which
> do this.
That's also an option!
But for simplicity-sake, I used the get_random_bytes() function (from
the /dev/random-device) combined with a loop. It's a simplistic hack, but
it'll work for my paranoia mind :o)
Greetings,
Folkert van Heusden
-
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/