archive mirror
 help / color / mirror / Atom feed
From: Andrey Borzenkov <>
To: Andrew Morton <>
Subject: Re: [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined patch
Date: Tue, 8 Jul 2003 21:49:17 +0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tuesday 08 July 2003 01:00, Andrew Morton wrote:
> Andrey Borzenkov <> wrote:
> > I finally hit a painfully trivial way to reproduce another long standing
> > devfs problem - deadlock between devfs_lookup and
> > devfs_d_revalidate_wait.
> uh.
> > The current fix is to move re-acquire of i_sem after all
> > devfs_d_revalidate_wait waiters have been waked up.
> Directory modifications appear to be under write_lock(&dir->u.dir.lock); so
> that obvious problem is covered.  Your patch might introduce a race around
> _devfs_get_vfs_inode() - two CPUs running that against the same inode at
> the same time?

Actually it just makes it marginally more probable.

Normal open without O_CREATE runs ->d_revalidate outside of i_sem i.e. neither 
devfs_lookup vs. devfs_d_revalidate_wait nor devfs_d_revalidate_wait vs. 
itself are protected  by i_sem and this is (should be) the most common case 
for /dev access.

This race happens under non-trivial conditions. devfsd descendant (i.e. some 
action) should be involved; and action triggered by devfs_lookup does not 
race with it by definition because devfs_lookup waits for action to finish. 
I.e. it needs another devfsd action that would access /dev entry after it 
just has been created or two concurrent lookups in LOOKUP action itself. 
Quite unlikely in real life and race window is very small.

I do not want to sound like it has to be ignored - but devfs code is so messy 
that no trivial fix exists that would not make code even more messy. So I 
would still apply original fixes and let this problem be solved later - it is 
not so important as to delay two other.


  reply	other threads:[~2003-07-08 17:44 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 [this message]
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
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).