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