[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200609071031.33855.jdelvare@suse.de>
Date: Thu, 7 Sep 2006 10:31:33 +0200
From: Jean Delvare <jdelvare@...e.de>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrew Morton <akpm@...l.org>, Oleg Nesterov <oleg@...sign.ru>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-kernel@...r.kernel.org, ak@...e.de
Subject: Re: [PATCH] proc: readdir race fix (take 3)
On Thursday 7 September 2006 00:43, Eric W. Biederman wrote:
> Have you tested 2.6.18-rc6 without my patch?
Yes I did, it didn't crash after a couple hours. Of course it doesn't
prove anything as the crash appears to be the result of a race.
I'll now apply Oleg's fix and see if things get better.
> I guess the practical question is what was your test methodology to
> reproduce this problem? A couple of more people running the same
> test on a few more machines might at least give us confidence in what
> is going on.
"My" test program forks 1000 children who sleep for 1 second then look for
themselves in /proc, warn if they can't find themselves, and exit. So
basically the idea is that the process list will shrink very rapidly at
the same moment every child does readdir(/proc).
I attached the test program, I take no credit (nor shame) for it, it was
provided to me by IBM (possibly on behalf of one of their own customers)
as a way to demonstrate and reproduce the original readdir(/proc) race
bug.
--
Jean Delvare
View attachment "test.c" of type "text/x-csrc" (1152 bytes)
Powered by blists - more mailing lists