archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <>
To: Andrey Borzenkov <>
Cc: Andrew Morton <>,,
Subject: Re: [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined patch
Date: Mon, 7 Jul 2003 17:41:40 -0400 (EDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

Pavel Roskin

  parent reply	other threads:[~2003-07-07 21:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2003-07-06 17:06     ` [PATCH][2.5.73] stack corruption in devfs_lookup Andrey Borzenkov
2003-07-06 19:03       ` Andrew Morton
     [not found]         ` <>
2003-07-07 19:06           ` [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined patch Andrey Borzenkov
2003-07-07 21:00             ` Andrew Morton
2003-07-08 17:49               ` Andrey Borzenkov
2003-07-09  1:20                 ` Herbert Poetzl
2003-07-09  1:26                   ` Andrew Morton
2003-07-09  2:09                     ` Herbert Poetzl
2003-07-09 10:34                       ` Thierry Vignaud
2003-07-07 21:41             ` Pavel Roskin [this message]
2003-07-26 14:58         ` [PATCH][2.6.0-test1] redesign - stack corruption in devfs_lookup Andrey Borzenkov

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined patch' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).