Date: Fri, 21 Aug 2009 23:09:57 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com>, bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: various vfs LORs Message-ID: <20090821200957.GC9623@deviant.kiev.zoral.com.ua> In-Reply-To: <Pine.GSO.4.63.0908211402510.14428@muncher.cs.uoguelph.ca> References: <20090819161817.GA89704@keira.kiwi-computer.com> <20090819175029.GA90205@keira.kiwi-computer.com> <Pine.GSO.4.63.0908211402510.14428@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--rKOd0RGqnoxbj4so Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 21, 2009 at 02:05:13PM -0400, Rick Macklem wrote: >=20 >=20 > On Wed, 19 Aug 2009, Rick C. Petty wrote: >=20 > > > >This LOR doesn't seem to be reported anywhere: > > > >>lock order reversal: > >> 1st 0xffffff00046de7f8 nfs (nfs) @ /usr/src/sys/kern/vfs_syscalls.c:40= 97 > >> 2nd 0xffffff80a5129968 bufwait (bufwait) @=20 > >> /usr/src/sys/kern/vfs_bio.c:1835 > >> 3rd 0xffffff00046de620 nfs (nfs) @ /usr/src/sys/nfsclient/nfs_node.c:1= 61 > >>KDB: stack backtrace: > >>db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >>_witness_debugger() at _witness_debugger+0x2e > >>witness_checkorder() at witness_checkorder+0x81e > >>__lockmgr_args() at __lockmgr_args+0xcf3 > >>nfs_nget() at nfs_nget+0x1c9 > >>nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc > >>nfs_doio() at nfs_doio+0x617 > >>nfs_bioread() at nfs_bioread+0xa9f > >>nfs_readdir() at nfs_readdir+0x85 > >>kern_getdirentries() at kern_getdirentries+0x12e > >>getdirentries() at getdirentries+0x23 > >>syscall() at syscall+0x1af > >>Xfast_syscall() at Xfast_syscall+0xe1 > >>--- syscall (196, FreeBSD ELF64, getdirentries), rip =3D 0x8009d11dc, r= sp =3D=20 > >>0x7fffffffc3a8, rbp =3D 0x1 --- >=20 > Since the 3rd one is locking a newly allocated nfs vnode (that isn't yet= =20 > in the mount point list, etc), I don't think this will cause a problem > and I don't see an easy way to avoid it. We could add LK_NOWITNESS to nfsclient/nfs_subr.c:161. --rKOd0RGqnoxbj4so Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqO/xUACgkQC3+MBN1Mb4j9iwCgiUQjQ7JZ1HFrBQmn4tSAluMQ ZjsAn24tzN3T7UY0uUU+gaRrICw3NQFq =t1dS -----END PGP SIGNATURE----- --rKOd0RGqnoxbj4so--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090821200957.GC9623>