linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@mail.ru>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, devfs@oss.sgi.com
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: <200307082149.17918.arvidjaar@mail.ru> (raw)
In-Reply-To: <20030707140010.4268159f.akpm@osdl.org>

On Tuesday 08 July 2003 01:00, Andrew Morton wrote:
> Andrey Borzenkov <arvidjaar@mail.ru> 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.

-andrey

  reply	other threads:[~2003-07-08 17:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E198K0q-000Am8-00.arvidjaar-mail-ru@f23.mail.ru>
     [not found] ` <Pine.LNX.4.55.0304231157560.1309@marabou.research.att.com>
     [not found]   ` <Pine.LNX.4.55.0305050005230.1278@marabou.research.att.com>
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]         ` <20030706175405.518f680d.akpm@osdl.org>
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:
  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=200307082149.17918.arvidjaar@mail.ru \
    --to=arvidjaar@mail.ru \
    --cc=akpm@osdl.org \
    --cc=devfs@oss.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH][2.5.74] devfs lookup deadlock/stack corruption combined patch' \
    /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

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).