From: "Theodore Ts'o" <tytso@mit.edu>
To: Dave Goel <deego3@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Linux] Linux PID algorithm is BRAINDEAD!
Date: Mon, 12 Oct 2015 11:04:38 -0400 [thread overview]
Message-ID: <20151012150438.GA32396@thunk.org> (raw)
In-Reply-To: <CAOCW0Dgi_qbCth6jjOaDSEK_YizaihB4mjEubqTqe=FN=xtvzA@mail.gmail.com>
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
next prev parent reply other threads:[~2015-10-12 15:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-10 2:00 [Linux] Linux PID algorithm is BRAINDEAD! Dave Goel
2015-10-10 3:20 ` yalin wang
2015-10-10 21:58 ` Theodore Ts'o
2015-10-11 3:51 ` Dave Goel
2015-10-11 17:44 ` Dave Goel
2015-10-12 15:04 ` Theodore Ts'o [this message]
2015-10-12 17:49 ` Dave Goel
2015-10-12 18:12 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151012150438.GA32396@thunk.org \
--to=tytso@mit.edu \
--cc=deego3@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox