* Re: [PATCH][RESEND] 2.4 devfs deadlock on concurrent lookups on non-existent entry
@ 2003-06-22 19:30 Fr�d�ric L. W. Meunier
0 siblings, 0 replies; 2+ messages in thread
From: Fr�d�ric L. W. Meunier @ 2003-06-22 19:30 UTC (permalink / raw)
To: linux-kernel
Andrey Borzenkov wrote:
> Unfortunately, I do not know who is current active devfs
> maintainer.
I thought it was Richard Gooch. When 2.4.20 was released I
asked him if I could apply the latest patch from
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/
. 2.4.21 was released, but again without the 199.17 patch.
Anything wrong with it or nobody submitted it to Marcelo ?
^ permalink raw reply [flat|nested] 2+ messages in thread
* [PATCH][RESEND] 2.4 devfs deadlock on concurrent lookups on non-existent entry
@ 2003-06-22 18:06 Andrey Borzenkov
0 siblings, 0 replies; 2+ messages in thread
From: Andrey Borzenkov @ 2003-06-22 18:06 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]
I resend this patch on request of Pavel Roskin. Unfortunately, I do not know
who is current active devfs maintainer.
It appears, so far no negative effects with this patch was observed; the patch
is used in unofficial Mandrake Club kernel as well. The problem is real,
recently there was increased number of complaints on a.o.l.m
Original message follows:
============================
This problem has first been reported for over two years ago. Usually it
happened during system boot using RH initscripts with two minilogds hanging
on access to /dev/log and blocking rc.sysinit; this condition was triggered
by unrelated bug in minilogd.
Pavel Roskin provided detailed debug info for this problem; details including
stack are available at
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85621>. It turned out a
deadlock between devfs_lookup and devfs_d_revalidate_wait for cases when
->d_revalidate was called under parent->i_sem (mostly all places where
lookup_hash was used). The deadlock looked like:
path_lookup("dev/log", LOOKUP_PARENT, &nd);
-> yields dentry for </dev>
path_lookup("dev/log", LOOKUP_PARENT, &nd);
-> yields dentry for </dev>
down(</dev>->i_sem) holds i_sem
down(</dev>->i_sem) - sleeps
lookup_hash("log", </dev>) .
devfs_lookup(</dev>, "log") .
MISS .
try_modload
set "log"->d_op to &devfs_wait_dops; .
init "log"->wait_queue .
up(</dev>->i_sem) .
.
obtains i_sem
lookup_hash("log", </dev>);
cached_lookup(</dev>, "log", 0)
devfs_d_revalidate_wait("log", 0)
wait on "log"->wait_queue
... waits to be waked up by devfs_lookup
down(</dev>->i_sem)
the patch fixes it by moving i_sem re-acquire after
wake_up(&lookup_info.wait_queue). It does not look like it adds any
additional races. Please check.
Pavel said it applies unchanged to 2.5 tree. Which may indicate it has the
same race condition. I do not have 2.5 available.
please consider for 2.4.21
regards
-andrey
[-- Attachment #2: devfs.minilogd.patch --]
[-- Type: text/x-diff, Size: 841 bytes --]
--- linux-2.4.21-0.13mdk/fs/devfs/base.c.minilogd 2002-11-29 02:53:15.000000000 +0300
+++ linux-2.4.21-0.13mdk/fs/devfs/base.c 2003-05-06 00:41:35.000000000 +0400
@@ -3038,7 +3038,6 @@ static struct dentry *devfs_lookup (stru
revalidation */
up (&dir->i_sem);
wait_for_devfsd_finished (fs_info); /* If I'm not devfsd, must wait */
- down (&dir->i_sem); /* Grab it again because them's the rules */
de = lookup_info.de;
/* If someone else has been so kind as to make the inode, we go home
early */
@@ -3068,6 +3067,7 @@ out:
write_lock (&parent->u.dir.lock);
wake_up (&lookup_info.wait_queue);
write_unlock (&parent->u.dir.lock);
+ down (&dir->i_sem); /* Grab it again because them's the rules */
devfs_put (de);
return retval;
} /* End Function devfs_lookup */
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-06-22 19:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-22 19:30 [PATCH][RESEND] 2.4 devfs deadlock on concurrent lookups on non-existent entry Fr�d�ric L. W. Meunier
-- strict thread matches above, loose matches on Subject: below --
2003-06-22 18:06 Andrey Borzenkov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.