Date: Fri, 22 Oct 2010 21:47:37 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Linda Messerschmidt <linda.messerschmidt@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Lock Order Reversal in nmount/unmount of devfs on NFS Message-ID: <20101022184737.GI2392@deviant.kiev.zoral.com.ua> In-Reply-To: <AANLkTik%2By7Z_U3HvYe1v3j6X%2BQq9VxduDCEJWr3mhO0j@mail.gmail.com> References: <AANLkTik%2By7Z_U3HvYe1v3j6X%2BQq9VxduDCEJWr3mhO0j@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--/U3josVVZTqzPL34 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 22, 2010 at 01:46:54PM -0400, Linda Messerschmidt wrote: > When mounting a devfs filesystem on top of a directory in an NFS > filesystem under 8.1-RELEASE-p1 r213075M, the following lock order > reversal is reported: >=20 > lock order reversal: > 1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058 > 2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090 > KDB: stack backtrace: > X_db_sym_numargs(c032f02b,d58f6810,c0108c55,c00f906b,c0331eb2,...) at > X_db_sym_numargs+0x146 > kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdd08,d58f686c,...) at > kdb_backtrace+0x29 > witness_display_spinlock(c0331eb2,c264bce8,c0321549,c22bdd08,c033918e,...) > at witness_display_spinlock+0x75 > witness_checkorder(c264bce8,9,c033918e,82a,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c264bce8,80100,c264bd04,0,0,...) at __lockmgr_args+0x7f5 > vop_stdlock(d58f6988,c01089fb,c032177a,80100,c264bc90,...) at vop_stdlock= +0x62 > VOP_LOCK1_APV(c0364b00,d58f6988,c24e2824,c0395920,c264bc90,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c264bc90,80100,c033918e,82a,8,...) at _vn_lock+0x5e > vget(c264bc90,80100,c24e2780,15e,c032169c,...) at vget+0xb9 > devfs_allocv(c262d280,c24c6508,d58f6a20,9d,c0508b7c,...) at devfs_allocv+= 0x102 > devfs_rules_apply(c24c6508,80000,d58f6c40,430,0,...) at devfs_rules_apply= +0x14a > vfs_donmount(c24e2780,0,c262d380,c262d380,bf7fdde9,...) at vfs_donmount+0= x14c2 > nmount(c24e2780,d58f6d08,0,c,c265e2a8,...) at nmount+0x75 > syscall(d58f6d48) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x22 > --- syscall (378, FreeBSD ELF32, nmount), eip =3D 0x280e724b, esp =3D > 0xbf7fddbc, ebp =3D 0xbf7fe318 --- >=20 > If I then try to umount the defvs, even if the unmount fails because > the path is busy, I get a similar one: >=20 > lock order reversal: > 1st 0xc2673488 nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1204 > 2nd 0xc2673270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2203 > KDB: stack backtrace: > X_db_sym_numargs(c032f02b,d596ba48,c0108c55,c00f906b,c0331eb2,...) at > X_db_sym_numargs+0x146 > kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdea8,d596baa4,...) at > kdb_backtrace+0x29 > witness_display_spinlock(c0331eb2,c2673270,c033930d,c22bdea8,c033918e,...) > at witness_display_spinlock+0x75 > witness_checkorder(c2673270,9,c033918e,89b,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c2673270,80100,c267328c,0,0,...) at __lockmgr_args+0x7f5 > vop_stdlock(d596bbc0,0,c033918e,80100,c2673218,...) at vop_stdlock+0x62 > VOP_LOCK1_APV(c0378cc0,d596bbc0,c00b6e03,c0395920,c2673218,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c2673218,80100,c033918e,89b,0,...) at _vn_lock+0x5e > insmntque(d596bc64,c014e0ce,c2673218,0,c03389a0,...) at insmntque+0x288 > vrele(c2673218,0,c03389a0,4f9,c036dfa0,...) at vrele+0x10 > dounmount(c2677508,8000000,c2777a00,47e,2,...) at dounmount+0x3ce > unmount(c2777a00,d596bd08,0,c,c27757f8,...) at unmount+0x2ff > syscall(d596bd48) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x22 > --- syscall (22, FreeBSD ELF32, unmount), eip =3D 0x280d870f, esp =3D > 0xbf7fe58c, ebp =3D 0xbf7fe658 --- >=20 > Both seem to occur only once per boot. I've tried both multiply > mounting/unmounting the same filesystem and mounting/unmounting > multiple devfs mounts on various different NFS mounts, but I've never > gotten more than one report for nmount and one for unmount. >=20 > It doesn't seem to hurt anything; should I bug report it? If so, is > there anything I can do to help with it, as far as further diagnostics > or fixing it? The LORs are believed to be harmless. --/U3josVVZTqzPL34 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzB3EkACgkQC3+MBN1Mb4hbXgCfSwCrHN5DxzxXYaBxvkkSeMYd NEwAn3Ke9i17HyATQFH4rNhF1ai7Sbr6 =SAew -----END PGP SIGNATURE----- --/U3josVVZTqzPL34--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101022184737.GI2392>