From: Salman <sqazi@google.com>
To: peterz@infradead.org, linux-kernel@vger.kernel.org,
tytso@google.com, akpm@linux-foundation.org, walken@google.com,
torvalds@linux-foundation.org, mingo@elte.hu
Subject: [PATCH] Fix a race in pid generation that causes pids to be reused immediately.
Date: Thu, 10 Jun 2010 14:24:51 -0700 [thread overview]
Message-ID: <20100610212412.26415.4579.stgit@bumblebee1.mtv.corp.google.com> (raw)
[Fixed lines > 80-column]
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.
Race Description:
A B
// pid == offset == n // pid == offset == n + 1
test_and_set_bit(offset, map->page)
test_and_set_bit(offset, map->page);
pid_ns->last_pid = pid;
pid_ns->last_pid = pid;
// pid == n + 1 is freed (wait())
// Next fork()...
last = pid_ns->last_pid; // == n
pid = last + 1;
Code to reproduce it (Running multiple instances is more effective):
#include <errno.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
// The distance mod 32768 between two pids, where the first pid is expected
// to be smaller than the second.
int PidDistance(pid_t first, pid_t second) {
return (second + 32768 - first) % 32768;
}
int main(int argc, char* argv[]) {
int failed = 0;
pid_t last_pid = 0;
int i;
printf("%d\n", sizeof(pid_t));
for (i = 0; i < 10000000; ++i) {
if (i % 32786 == 0)
printf("Iter: %d\n", i/32768);
int child_exit_code = i % 256;
pid_t pid = fork();
if (pid == -1) {
fprintf(stderr, "fork failed, iteration %d, errno=%d", i, errno);
exit(1);
}
if (pid == 0) {
// Child
exit(child_exit_code);
} else {
// Parent
if (i > 0) {
int distance = PidDistance(last_pid, pid);
if (distance == 0 || distance > 30000) {
fprintf(stderr,
"Unexpected pid sequence: previous fork: pid=%d, "
"current fork: pid=%d for iteration=%d.\n",
last_pid, pid, i);
failed = 1;
}
}
last_pid = pid;
int status;
int reaped = wait(&status);
if (reaped != pid) {
fprintf(stderr,
"Wait return value: expected pid=%d, "
"got %d, iteration %d\n",
pid, reaped, i);
failed = 1;
} else if (WEXITSTATUS(status) != child_exit_code) {
fprintf(stderr,
"Unexpected exit status %x, iteration %d\n",
WEXITSTATUS(status), i);
failed = 1;
}
}
}
exit(failed);
}
Thanks to Ted Tso for the key ideas of this implementation.
Signed-off-by: Salman Qazi <sqazi@google.com>
---
kernel/pid.c | 42 +++++++++++++++++++++++++++++++++++++++++-
1 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/kernel/pid.c b/kernel/pid.c
index e9fd8c1..e8da445 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -122,6 +122,22 @@ static void free_pidmap(struct upid *upid)
atomic_inc(&map->nr_free);
}
+/*
+ * If we started walking pids at 'base', is 'a' seen before 'b'?
+ *
+ */
+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);
+}
+
static int alloc_pidmap(struct pid_namespace *pid_ns)
{
int i, offset, max_scan, pid, last = pid_ns->last_pid;
@@ -153,8 +169,32 @@ static int alloc_pidmap(struct pid_namespace *pid_ns)
if (likely(atomic_read(&map->nr_free))) {
do {
if (!test_and_set_bit(offset, map->page)) {
+ int prev;
+ int last_write = last;
atomic_dec(&map->nr_free);
- pid_ns->last_pid = pid;
+
+ /*
+ * We might be racing with someone else
+ * trying to set pid_ns->last_pid.
+ * We want the winner to have the
+ * "later" value, because if the
+ * "earlier" value prevails, then
+ * a pid may get reused immediately.
+ *
+ * Since pids rollover, it is not
+ * sufficent to just pick the bigger
+ * value. We have to consider
+ * where we started counting from.
+ */
+ do {
+ prev = last_write;
+ last_write = cmpxchg(
+ &pid_ns->last_pid,
+ prev, pid);
+ } while ((prev != last_write) &&
+ (pid_before(last, last_write,
+ pid)));
+
return pid;
}
offset = find_next_offset(map, offset);
next reply other threads:[~2010-06-10 21:25 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 21:24 Salman [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-06-11 17:17 Salman
2010-06-11 17:44 ` Linus Torvalds
2010-06-11 22:49 ` Salman
2010-06-11 23:07 ` Linus Torvalds
2010-06-14 23:58 ` Andrew Morton
2010-06-15 0:56 ` tytso
2010-06-15 1:55 ` Andrew Morton
2010-06-15 3:26 ` Paul Mackerras
2010-06-15 4:21 ` Andrew Morton
2010-06-15 4:38 ` Eric Dumazet
2010-06-15 6:57 ` Benjamin Herrenschmidt
2010-06-15 7:25 ` Paul Mackerras
2010-06-15 12:56 ` tytso
2010-06-15 13:06 ` Kyle McMartin
2010-06-15 14:35 ` Peter Zijlstra
2010-06-15 19:37 ` Andrew Morton
2010-06-10 20:09 Salman
2010-06-10 20:38 ` tytso
2010-06-10 21:04 ` Salman Qazi
2010-06-09 21:00 Salman
2010-06-09 21:21 ` Linus Torvalds
2010-06-09 21:33 ` Peter Zijlstra
2010-06-09 22:20 ` Linus Torvalds
2010-06-09 22:27 ` Linus Torvalds
2010-06-10 0:08 ` Salman Qazi
2010-06-10 0:20 ` Linus Torvalds
[not found] ` <AANLkTilXJ0X2qxD9cNTlLayKzySEZu1HEZUWu--Go8kw@mail.gmail.com>
2010-06-10 5:55 ` Salman Qazi
2010-06-10 16:39 ` Linus Torvalds
2010-06-09 6:24 Salman
2010-06-09 6:53 ` Andi Kleen
2010-06-09 9:48 ` Ingo Molnar
2010-06-09 15:39 ` Linus Torvalds
2010-06-09 15:50 ` tytso
2010-06-09 16:06 ` Linus Torvalds
2010-06-09 17:10 ` tytso
2010-06-09 17:23 ` Linus Torvalds
2010-06-09 17:25 ` Linus Torvalds
2010-06-09 17:34 ` tytso
2010-06-09 17:43 ` Linus Torvalds
2010-06-09 17:47 ` tytso
2010-06-09 18:09 ` Salman Qazi
2010-06-09 11:49 ` Michel Lespinasse
2010-06-09 12:37 ` tytso
2010-06-09 12:17 ` tytso
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=20100610212412.26415.4579.stgit@bumblebee1.mtv.corp.google.com \
--to=sqazi@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@google.com \
--cc=walken@google.com \
/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
Powered by JetHome