Date: Sat, 11 May 2002 03:12:56 +0700 (NOVST) From: "Semen A. Ustimenko" <semenu@FreeBSD.org> To: freebsd-fs@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org, "Flood, Jim" <Jim.Flood@acirro.com> Subject: NULLFS-related possible deadlock + fix proposal Message-ID: <20020511005932.S1705-100000@def.the.net>
next in thread | raw e-mail | index | archive | help
Hi!
Preface:
Same directory is null-mounted to "/mnt" and "/mnt2". The directory
contain "dir/foofile". Two processes concurently lookup "/mnt/dir/foofile"
and "/mnt2/dir/foofile".
Action:
P1:
in lookup():
in VOP_LOOKUP(dvp (== "/mnt/dir"), "foofile"):
in null_lookup():
in null_node_create():
in malloc() | getnewvnode() | somewhere():
in tsleep() -> P1 is preempted by P2
(Note, that "foofile"'s lower vnode is locked by P1, "dir"'s lower
vnode is unlocked, thus "/mnt2/dir" is also unlocked)
P2:
in lookup():
in VOP_LOOKUP(dvp (== "/mnt2/dir"), "foofile):
in null_lookup():
in VOP_LOOKUP(lowerdvp, "foofile"):
in tsleep(), waiting for "foofile"'s lower vnode, held by P1
(Note, the "/mnt2/dir"'s vnode and thus its lower vnode is still locked by
P2, the "foofile"'s lower vnode is locked by P1)
P1:
in lookup():
in vrele(dvp (== "/mnt/dir")):
in vn_lock(dvp):
in tsleep(), waiting for "/mnt/dir"'s lower vnode, held by P2
DEADLOCK...
Analysis:
The lookup() routine can call vrele(), in its turn vrele() can vn_lock()
parent directory, while holding lock on file from this directory. This
isn't a problem for nonstacking FSes as vrele() will only vn_lock if it
were the last reference.
For NULLFS this is a problem because completely different vnodes can share
the lock structure.
Solution:
Make vn_lock() in vrele() lock vnode only LK_THISLAYER. Obviously, the
NULLFS and other stacking FSes will have to deal with this in their
VOP_INACTIVE() handlers. This changes won't touch real FSes as they ignore
the LK_THISLAYER, don't they?
Bye!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020511005932.S1705-100000>