Date: Thu, 7 Feb 2008 14:52:52 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: Marcel Moolenaar <marcelm@juniper.net>, current@freebsd.org Subject: Re: Old LOR between devfs & devfsmount resurfacing? Message-ID: <20080207125252.GC57756@deviant.kiev.zoral.com.ua> In-Reply-To: <3bbf2fe10802070421m3a3152a3m6c9aa67d649107e4@mail.gmail.com> References: <B269B28B-C66E-4AC6-A4D9-FBA378466F89@juniper.net> <20080207045015.GW57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070216idd5206ey7a66c0873311e66c@mail.gmail.com> <20080207104354.GY57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070304r29cb8d2u1210fe285c917424@mail.gmail.com> <20080207110901.GZ57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070421m3a3152a3m6c9aa67d649107e4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--mLKJPRsbAVeTlcYc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 07, 2008 at 01:21:09PM +0100, Attilio Rao wrote: > 2008/2/7, Kostik Belousov <kostikbel@gmail.com>: > > On Thu, Feb 07, 2008 at 12:04:28PM +0100, Attilio Rao wrote: > > > 2008/2/7, Kostik Belousov <kostikbel@gmail.com>: > > > > On Thu, Feb 07, 2008 at 11:16:08AM +0100, Attilio Rao wrote: > > > > > 2008/2/7, Kostik Belousov <kostikbel@gmail.com>: > > > > > > On Wed, Feb 06, 2008 at 11:11:06AM -0800, Marcel Moolenaar wr= ote: > > > > > > > All, > > > > > > > > > > > > > > I just ran into the following LOR after upgrading my Power= PC box: > > > > > > > > > > > > > > lock order reversal: > > > > > > > 1st 0xdbee94 devfs (devfs) @ /nfs/freebsd/8.x/src/sys/ker= n/ > > > > > > > vfs_subr.c:2061 > > > > > > > 2nd 0xdfb014 devfsmount (devfsmount) @ /nfs/freebsd/8.x/s= rc/sys/fs/ > > > > > > > devfs/devfs_vnops.c:201 > > > > > > > KDB: stack backtrace: > > > > > > > 0xdc0febc8: at kdb_backtrace+0x4c > > > > > > > 0xdc0febd8: at witness_checkorder+0x704 > > > > > > > 0xdc0fec28: at _sx_xlock+0x8c > > > > > > > 0xdc0fec48: at devfs_allocv+0x138 > > > > > > > 0xdc0fec88: at devfs_root+0x5c > > > > > > > 0xdc0fecb8: at set_rootvnode+0x44 > > > > > > > 0xdc0fece8: at vfs_mountroot+0x344 > > > > > > > 0xdc0fed48: at start_init+0x88 > > > > > > > 0xdc0feda8: at fork_exit+0xb4 > > > > > > > 0xdc0fedc8: at fork_trampoline+0xc > > > > > > > KDB: enter: witness_checkorder > > > > > > > [thread pid 1 tid 100001 ] > > > > > > > Stopped at 0x28ee68: addi r0, r0, 0x0 > > > > > > > > > > > > > > It seems that this is a LOR reported in 2006 and fixed > > > > > > > in 2006 as well. Do other people see this too, or should > > > > > > > I suspect my sources? > > > > > > > > > > > > > > > > > > I believe this is a false positive, caused by the way the wit= ness works. > > > > > > Attilio recently added the witness support for the lockmgr, = that caused > > > > > > this and at least two more LORs to be printed on startup. > > > > > > > > > > > > Correct lock order is devfs vnode -> devfs mount sx lock. Wh= en > > > > > > allocating new devfs vnode, see devfs_allocv(), the newly cr= eated > > > > > > vnode is locked while devfs mount lock already held (see lin= e 250 of > > > > > > fs/devfs/devfs_vnops.c). Nonetheless, this cannot cause dead= lock since > > > > > > no other thread can find the new vnode, and thus perform the= other lock > > > > > > order for this vnode lock. > > > > > > > > > > > > The fix is to shut the witness in this particular case. Atti= lio, how to > > > > > > do this ? > > > > > > > > > > Just add LK_NOWITNESS for one of the lock involved in the locki= nit(). > > > > > > > > > > > > Then, we loss the useful reports of the actual LORs later, isn't i= t ? > > > > > > Another solution would be to rewamp BLESSING option which allow to > > > 'bless' some LORs. > > > jhb and me, btw, didn't want to enable it because it could lead some > > > less experienced developer to hide LORs under this label and this is > > > something we want to avoid. > > > > > > This LOR shall not be ignored globally. When real, it caused the easily > > reproducable lockup of the machine. > > > > It would be better to introduce some lockmgr flag to ignore _this_ loc= king. >=20 > flag to pass where? To the lockmgr itself at the point of aquisition, like lockmgr(&lk, LK_EXCLUSIVE | LK_INTERLOCK | LK_NOWARN, &interlk, ...); > Really I think this will need some witness tweaking. > After all a mechanism for ignoring specific LOR (happening at > specified file-line) is not a bad idea. >=20 > Attilio >=20 >=20 > --=20 > Peace can only be achieved by understanding - A. Einstein --mLKJPRsbAVeTlcYc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkeq/yQACgkQC3+MBN1Mb4i7uQCgwgEHi52Wo25ES48q0NSE/S+x Ra0An3jgbF8W196mrauRdKI0pE3g+Tf1 =0P3z -----END PGP SIGNATURE----- --mLKJPRsbAVeTlcYc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080207125252.GC57756>