From owner-freebsd-fs@FreeBSD.ORG Tue Jul 26 14:22:00 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 809B9106564A; Tue, 26 Jul 2011 14:22:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1EABA8FC19; Tue, 26 Jul 2011 14:21:59 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6QELuVH036984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 17:21:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6QELubY077960; Tue, 26 Jul 2011 17:21:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6QELuP2077959; Tue, 26 Jul 2011 17:21:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Jul 2011 17:21:56 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20110726142156.GJ17489@deviant.kiev.zoral.com.ua> References: <20110726090441.GD17489@deviant.kiev.zoral.com.ua> <429452924.1012322.1311689248782.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b4Xfh4GKY2byHbNw" Content-Disposition: inline In-Reply-To: <429452924.1012322.1311689248782.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD FS , attilio@freebsd.org Subject: Re: Does msodsfs_readdir() require a exclusively locked vnode X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:22:00 -0000 --b4Xfh4GKY2byHbNw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 26, 2011 at 10:07:28AM -0400, Rick Macklem wrote: > Kostik Belousov wrote: > > On Mon, Jul 25, 2011 at 07:22:40PM -0400, Rick Macklem wrote: > > > Hi, > > > > > > Currently both NFS servers set the vnode lock LK_SHARED > > > and so do the local syscalls (at least that's how it looks > > > by inspection?). > > > > > > Peter Holm just posted me this panic, where a test for an > > > exclusive vnode lock fails in msdosfs_readdir(). > > > KDB: stack backtrace: > > > db_trace_self_wrapper(c0efa6f6,c71627f8,c79230b0,c0f2ef29,f19154b8,..= .) > > > at db_trace_self_wrapper+0x26 > > > kdb_backtrace(c7f20b38,f19154fc,c0d586d5,f191550c,c7f20ae0,...) at > > > kdb_backtrace+0x2a > > > vfs_badlock(c101b180,f191550c,c1055580,c7f20ae0) at vfs_badlock+0x23 > > > assert_vop_elocked(c7f20ae0,c0ee5f4f,c09f3213,8,0,...) at > > > assert_vop_elocked+0x55 > > > pcbmap(c7966e00,0,f191560c,f1915618,f191561c,...) at pcbmap+0x45 > > > msdosfs_readdir(f1915960,c0f4b343,c7f20ae0,f1915940,0,...) at > > > msdosfs_readdir+0x528 > > > VOP_READDIR_APV(c101b180,f1915960,2,f1915a68,c7923000,...) at > > > VOP_READDIR_APV+0xc5 > > > nfsrvd_readdir(f1915b64,0,c7f20ae0,c7923000,f1915a68,...) at > > > nfsrvd_readdir+0x38e > > > nfsrvd_dorpc(f1915b64,0,c7923000,c842a200,4,...) at > > > nfsrvd_dorpc+0x1f79 > > > nfssvc_program(c7793800,c842a200,c0f24d67,492,0,...) at > > > nfssvc_program+0x40f > > > svc_run_internal(f1915d14,c09d9a98,c73dfa80,f1915d28,c0ef1130,...) > > > at svc_run_internal+0x952 > > > svc_thread_start(c73dfa80,f1915d28,c0ef1130,3a5,c7e4b2c0,...) at > > > svc_thread_start+0x10 > > > fork_exit(c0bed7d0,c73dfa80,f1915d28) at fork_exit+0xb8 > > > fork_trampoline() at fork_trampoline+0x8 > > > --- trap 0x804c12e, eip =3D 0xc, esp =3D 0x33, ebp =3D 0x1 --- > > > pcbmap: 0xc7f20ae0 is not exclusive locked but should be > > > KDB: enter: lock violation > > > > > > So, does anyone know if the msdosfs_readdir() really requires a > > > LK_EXCLUSIVE > > > locked vnode or is the ASSERT_VOP_ELOCKED() too strong in pcbmap()? > >=20 > > Yes, msdosfs currently requires all vnode locks to be exclusive. One > > of > > the reasons is that each denode (the msdosfs-private vnode data) > > carries > > the fat entries cache, and this cache is updated even by the > > operations > > that do not modify vnode from the VFS POV. > >=20 > > The locking regime is enforced by the getnewvnode() initializing the > > vnode > > lock with LK_NOSHARE flag, and msdosfs code not calling > > VN_LOCK_ASHARE() > > on the newly instantiated vnode. > >=20 > > My question is, was the vnode in question locked at all ? > I think the problem is that I do a LK_DOWNGRADE. From a quick > look at __lockmgr_args(), it doesn't check LK_NOSHARE for a > LK_DOWNGRADE. >=20 > Maybe __lockmgr_args() should have something like: > if (op =3D=3D LK_DOWNGRADE && (lk->lock_object.lo_flags & LK_NOSHARE)) > return (0); /* noop */ > after the > if (op =3D=3D LK_SHARED && (lk->lock_object.lo_flags & LK_NOSHARE)) > op =3D LK_EXCLUSIVE; > lines? The RELENG_7 lockmgr does not check the NOSHARE flag on downgrade, but I agree with the essence of your proposal. >=20 > Anyhow, I'll get pho@ to test a patch without the LK_DOWNGRADE in > it. (It was pretty useless and would go away soon anyhow, once the > lkflags argument to VFS_FHTOVP() gets used.) >=20 > Thanks for the info, rick --b4Xfh4GKY2byHbNw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4uzYQACgkQC3+MBN1Mb4jUqwCfd0psq10eFKVOBjT6Ih4XKH55 THAAoPXF5vfaXy/LPtnjRmSK9i2d4IdK =TV5Y -----END PGP SIGNATURE----- --b4Xfh4GKY2byHbNw--