Re: [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined

[Pavel Roskin]

On Mon, 7 Jul 2003, Andrey Borzenkov wrote:

> To reproduce (2.5.74 UP or SMP - does not matter, single CPU system)
>
> ls /dev/foo & rm -f /dev/foo &
>
> or possibly in a loop but then it easily fills up process table. In my case it
> hangs 100% reliably - on 2.5 OR 2.4.

I've done some testing too.  I was using this script:

while :; do ls /dev/foo & rm -f /dev/foo & done

On Linux 2.5.74-bk5 without patches, running this script on a local
virtual console makes the system very slow.  I could not even login on
another virtual console.  However, I could interrupt the script by Ctrl-C.
After that I had a large number of processes in the D state.  Here's an
excerpt from the output of "ps ax":

31011 vc/1     D      0:00 ls /dev/foo
31012 vc/1     D      0:00 rm -f /dev/foo
31013 vc/1     D      0:00 ls /dev/foo
31014 vc/1     D      0:00 rm -f /dev/foo

I couldn't reboot the system cleanly.  My guess is that no new processes
could be run.

Linux 2.5.74-bk5 with the "combined" patch is OK.  Running the test
script doesn't prevent new logins.  There are no hanging processes after
interrupting the script.

> I have already sent the patch for 2.4 two times - please, could somebody
> finally either apply it or explain what is wrong with it. Richard is out of
> reach apparently and the bug is real and seen by many people.

I confirm seeing the bug on two systems with recent 2.4.x kernels with
probability over 50%.  Upgrading both systems to 2.5.x cured the problem
(of course, it's just a race condition that stopped happening).

Yes, it's an important problem to fix, and maybe we could remove the
"experimental" mark from CONFIG_DEVFS once it's done.  Maybe it's better
to have the patch accepted in the 2.5 series first just for "methodical"
reasons, but in practical terms, it's 2.4 kernels that need the deadlock
fix very badly.

-- 
Regards,
Pavel Roskin