UFS snapshot deadlocks
Kirk McKusick
mckusick at mckusick.com
Wed Jun 16 04:34:48 GMT 2004
Good sleuthing job. You have correctly analyzed the problem and
your fix is correct. You have my blessing to check it in. And thanks
for taking the time to figure this out when I did not have the time
to do so.
Kirk McKusick
=-=-=-=-=-=
Date: Wed, 16 Jun 2004 12:38:18 +0900
From: Jun Kuriyama <kuriyama at imgsrc.co.jp>
To: Frode Nordahl <frode at nordahl.net>
Cc: Kirk McKusick <mckusick at mckusick.com>, freebsd-current at freebsd.org
Subject: Re: UFS snapshot deadlocks
X-ASK-Info: Whitelist match
At Fri, 4 Jun 2004 15:06:55 +0000 (UTC),
Frode Nordahl wrote:
> tty1:
> while (1)
> ls -la /usr/.snap
> end
>
> tty2:
> dump -0af /some/where -C 32 -L /dev/ad0s1f
I did diagnose about this.
L1. ls(1) issues lstat(2) during walking inside directory.
L2. lstat(2) calls namei().
L3. namei() tries to lock VREG /usr/.snap/dump_snapshot after locking
VDIR /usr/.snap.
D1. dump(8) calls mount(2) via mksnap_ffs(8).
D2. mount(2) calls ffs_snapshot().
D3. ffs_snapshot() locks /usr/.snap/dump_snapshot after VOP_CREATE().
D4. ffs_snapshot() searches active but unlinked files from
mnt_nvnodelist.
D5. when it founds /usr/.snap vnode, tries to lock it.
My question is:
1. should ordering of such locks be parent dir vnode first, and file
in that dir vnode second?
2. is comparing vnode pointer like this to skip /usr/.snap safe?
Index: ffs_snapshot.c
===================================================================
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_snapshot.c,v
retrieving revision 1.81
diff -u -r1.81 ffs_snapshot.c
--- ffs_snapshot.c 16 Jun 2004 00:26:30 -0000 1.81
+++ ffs_snapshot.c 16 Jun 2004 03:34:44 -0000
@@ -424,6 +424,11 @@
MNT_ILOCK(mp);
continue;
}
+ if (xvp == nd.ni_dvp) {
+ VI_UNLOCK(xvp);
+ MNT_ILOCK(mp);
+ continue;
+ }
if (vn_lock(xvp, LK_EXCLUSIVE | LK_INTERLOCK, td) != 0) {
MNT_ILOCK(mp);
goto loop;
I did repeated test like as Frode did, but I cannot see any deadlocks
after this patch.
--
Jun Kuriyama <kuriyama at imgsrc.co.jp> // IMG SRC, Inc.
<kuriyama at FreeBSD.org> // FreeBSD Project
More information about the freebsd-current
mailing list