On Sun, Oct 11, 2015 at 01:44:02PM -0400, Dave Goel wrote:
>
> Here's a method to achieve the same goal (no immediate pid re-use),
> but without using any queues whatsoever:
>
> All freshly available PIDs are entered into PoolA.
>
> Every N seconds, a timer moves PoolA->PoolB, and PoolB->Free PIDs.
>
> And, the current PID allocation algo continues its allocation just the
> way it is.
>
> Then, a PID will wait between N and 2N seconds before getting re-allocated.
>
> N could be 5? This method seems to be to eliminate any queues, nor
> cause any additional bottlenecks or locks?
This won't help your temp cleaner. Consider: the pid wraps after 4
hours, then 10 seconds before the temp cleaner runs, a process exits,
the pid gets reused, and you still have the a race between the temp
cleaner testing whether or not a process exists, and the temp cleaner
deciding whether it's OK to delete the file with the form
prefix.<pid>.
Now, there are bunch of things you can do avoid the race, such as
having the shell script periodically touching the file, and simply
having temp cleaner avoid deleting a file that has a recent mtime.
But you can do that without making any changes to the kernel. Or you
can have the bash script keep a file descriptor open on the file, and
then delete the file, and then pass around the filename
/proc/$$/fd/<fd>. Then when the shell script dies, the file(s)
automatically go away, and you don't need the temp cleaner, or the
kernel changes, at all.
I can imagine solutions such as hacks where after a process existence
is tested using a kill 0 signal, that pid is prevented from being
reused for N seconds. But now you open up denial of service attacks
where some tries sending a kill 0 signal to the entire pidspace.
Ultimately, the question is trying to solve the problem in kernel is
worth the effort, especially when there are userspace solution which
don't require you to have a temp cleaner scanning the entire file
system.
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
