Date: Thu, 30 Jul 2009 12:25:07 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Rene Ladan <rene@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: kern/136945: [ufs] [lor] filedesc structure/ufs (poll) Message-ID: <20090730092507.GF1884@deviant.kiev.zoral.com.ua> In-Reply-To: <e890cae60907300205v5d3d5586qe86969bd28fe8621@mail.gmail.com> References: <200907271400.n6RE05Rv056472@freefall.freebsd.org> <200907290742.20838.jhb@freebsd.org> <e890cae60907290820i65abae2fracbc5ab935465089@mail.gmail.com> <200907291135.17569.jhb@freebsd.org> <e890cae60907300205v5d3d5586qe86969bd28fe8621@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--tRjCiSMHexiP9I5N Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2009 at 11:05:32AM +0200, Rene Ladan wrote: > 2009/7/29 John Baldwin <jhb@freebsd.org>: > > On Wednesday 29 July 2009 11:20:21 am Rene Ladan wrote: > >> 2009/7/29 John Baldwin <jhb@freebsd.org>: > >> > On Wednesday 29 July 2009 5:52:24 am Rene Ladan wrote: > >> >> 2009/7/28 John Baldwin <jhb@freebsd.org>: > >> >> > On Tuesday 28 July 2009 10:03:40 am Rene Ladan wrote: > >> >> >> 2009/7/28 John Baldwin <jhb@freebsd.org>: > >> >> >> > On Monday 27 July 2009 10:00:05 am Rene Ladan wrote: > >> >> >> >> The following reply was made to PR kern/136945; it has been n= oted > > by > >> >> > GNATS. > >> >> >> >> > >> >> >> >> From: Rene Ladan <rene@freebsd.org> > >> >> >> >> To: John Baldwin <jhb@freebsd.org> > >> >> >> >> Cc: bug-followup@freebsd.org > >> >> >> >> Subject: Re: kern/136945: [ufs] [lor] filedesc structure/ufs = (poll) > >> >> >> >> Date: Mon, 27 Jul 2009 15:51:15 +0200 > >> >> >> >> > >> >> >> >> =9A2009/7/27 John Baldwin <jhb@freebsd.org>: > >> >> >> >> =9A> I would actually expect this to be the correct order for= these > > two > >> >> >> > locks.=3D > >> >> >> >> =9A =3DA0Can > >> >> >> >> =9A> you capture the output of the 'debug.witness.fullgraph' = sysctl > > to a > >> >> > file? > >> >> >> >> =9A> > >> >> >> >> =9AYes, see attachment. =9AI'm still running the same 8.0-BET= A2. > >> >> >> > > >> >> >> > Hmm, the attachment was eaten by a grue, can you post the file > >> > somewhere? > >> >> >> > > >> >> >> Yes, see ftp://rene-ladan.nl/pub/freebsd/kern_136945.txt > >> >> > > >> >> > Ok, it looks like it did encounter a UFS -> filedesc order at some > >> > point. =9ACan > >> >> > you patch sys/kern/subr_witness.c to add a section to the order_l= ists[] > >> > array > >> >> > after the 'ZFS locking list' and before the spin locks list that = looks > >> > like > >> >> > this: > >> >> > > >> >> > =9A =9A =9A =9A{ "filedesc structure", &lock_class_sx }, > >> >> > =9A =9A =9A =9A{ "ufs", &lock_class_lockmgr}, > >> >> > =9A =9A =9A =9A{ NULL, NULL }, > >> >> > > >> >> The LOR seems to be gone, previously it showed up only once right > >> >> after booting the system. > >> >> > >> >> But now a new LOR (according to the LOR page) seems pop up: > >> >> Trying to mount root from ufs:/dev/ad0s1a > >> >> lock order reversal: > >> >> =9A1st 0xffffff0002a4ad80 ufs (ufs) > > @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1465 > >> >> =9A2nd 0xffffff0002b29a48 filedesc structure (filedesc structure) @ > >> >> /usr/src/sys/kern/kern_descrip.c:2478 > >> >> KDB: stack backtrace: > >> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >> >> _witness_debugger() at _witness_debugger+0x49 > >> >> witness_checkorder() at witness_checkorder+0x7ea > >> >> _sx_xlock() at _sx_xlock+0x44 > >> >> mountcheckdirs() at mountcheckdirs+0x80 > >> >> vfs_donmount() at vfs_donmount+0xfbf > >> >> kernel_mount() at kernel_mount+0xa1 > >> >> vfs_mountroot_try() at vfs_mountroot_try+0x177 > >> >> vfs_mountroot() at vfs_mountroot+0x47d > >> >> start_init() at start_init+0x62 > >> >> fork_exit() at fork_exit+0x12a > >> >> fork_trampoline() at fork_trampoline+0xe > >> >> --- trap 0, rip =3D 0, rsp =3D 0xffffff800001ad30, rbp =3D 0 --- > >> >> > >> >> The output of `df' and `mount' looks ok. > >> > > >> > Yes, this is the "real" LOR as "filedesc" -> "ufs" in the poll() case > > should > >> > be the normal order. =9AI believe this should fix it. =9Amountcheckd= irs() > > doesn't > >> > need the vnodes locked, it just needs the caller to hold references = on > > them > >> > so they aren't recycled: > >> > > >> > --- //depot/projects/smpng/sys/kern/vfs_mount.c#96 > >> > +++ /home/jhb/work/p4/smpng/sys/kern/vfs_mount.c > >> > @@ -1069,9 +1069,10 @@ > >> > =9A =9A =9A =9A =9A =9A =9A =9Avfs_event_signal(NULL, VQ_MOUNT, 0); > >> > =9A =9A =9A =9A =9A =9A =9A =9Aif (VFS_ROOT(mp, LK_EXCLUSIVE, &newdp= )) > >> > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Apanic("mount: lost mo= unt"); > >> > + =9A =9A =9A =9A =9A =9A =9A VOP_UNLOCK(newdp, 0); > >> > + =9A =9A =9A =9A =9A =9A =9A VOP_UNLOCK(vp, 0); > >> > =9A =9A =9A =9A =9A =9A =9A =9Amountcheckdirs(vp, newdp); > >> > - =9A =9A =9A =9A =9A =9A =9A vput(newdp); > >> > - =9A =9A =9A =9A =9A =9A =9A VOP_UNLOCK(vp, 0); > >> > + =9A =9A =9A =9A =9A =9A =9A vrele(newdp); > >> > =9A =9A =9A =9A =9A =9A =9A =9Aif ((mp->mnt_flag & MNT_RDONLY) =3D= =3D 0) > >> > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aerror =3D vfs_allocat= e_syncvnode(mp); > >> > =9A =9A =9A =9A =9A =9A =9A =9Avfs_unbusy(mp); > >> > > >> The LOR is still present, but at a different place without the > >> mountcheckdirs() call (not on the LOR page either) : > > > > Ok, try this patch as well: > > > > --- //depot/projects/smpng/sys/kern/vfs_mount.c#97 > > +++ /home/jhb/work/p4/smpng/sys/kern/vfs_mount.c > > @@ -1481,6 +1481,8 @@ > > =9A =9A =9A =9Aif (VFS_ROOT(TAILQ_FIRST(&mountlist), LK_EXCLUSIVE, &roo= tvnode)) > > =9A =9A =9A =9A =9A =9A =9A =9Apanic("Cannot find root vnode"); > > > > + =9A =9A =9A VOP_UNLOCK(rootvnode, 0); > > + > > =9A =9A =9A =9Ap =3D curthread->td_proc; > > =9A =9A =9A =9AFILEDESC_XLOCK(p->p_fd); > > > > @@ -1496,8 +1498,6 @@ > > > > =9A =9A =9A =9AFILEDESC_XUNLOCK(p->p_fd); > > > > - =9A =9A =9A VOP_UNLOCK(rootvnode, 0); > > - > > =9A =9A =9A =9AEVENTHANDLER_INVOKE(mountroot); > > =9A} > > >=20 > Still no luck, I now get a LOR that is similar to LOR 281 right after boo= ting: >=20 > lock order reversal: > 1st 0xffffff0002c2c7f8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 > 2nd 0xffffff0002b2a248 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/vfs_syscalls.c:3776 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7ea > _sx_slock() at _sx_slock+0x44 > kern_mkdirat() at kern_mkdirat+0x201 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (136, FreeBSD ELF64, mkdir), rip =3D 0x800729dac, rsp =3D > 0x7fffffffec88, rbp =3D 0x7fffffffef66 --- Remove the FILEDESC_SLOCK()/FILEDESC_SUNLOCK() calls from kern_mkdirat(). --tRjCiSMHexiP9I5N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpxZvMACgkQC3+MBN1Mb4jYuwCfVFcNNfBmbW8V+8Xqb+Jfx6U4 /T4AnApBSyFpHdjgbkNzo+z8pSVmZi1p =CQtO -----END PGP SIGNATURE----- --tRjCiSMHexiP9I5N--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090730092507.GF1884>