Date: Thu, 1 Jun 2006 10:25:38 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Cc: Howard Leadmon <howard@leadmon.net>, 'Rong-en Fan' <grafan@gmail.com>, freebsd-stable@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: [patch, try 1] Re: Trouble with NFSd under 6.1-Stable, any ideas? Message-ID: <20060601072538.GZ54541@deviant.kiev.zoral.com.ua> In-Reply-To: <20060530223342.G2710@atlantis.atlantis.dp.ua> References: <001401c67f56$b02975e0$071872cf@Leadmon.local> <003001c67fae$27a88370$071872cf@Leadmon.local> <20060525051926.GB97976@xor.obsecurity.org> <20060525145809.GP54541@deviant.kiev.zoral.com.ua> <20060530223342.G2710@atlantis.atlantis.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--gvPGo+RAdjC9O5ul
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 01, 2006 at 01:06:44AM +0300, Dmitry Pryanishnikov wrote:
>=20
> Hello!
>=20
> On Thu, 25 May 2006, Konstantin Belousov wrote:
> > KASSERT(!(debug_mpsafenet =3D=3D 1 && mtx_owned(&Giant)),
> > ("nfssvc_nfsd(): debug.mpsafenet=3D1 && Giant"));
> >
> >from nfsserver/nfs_syscalls.c, line 570.
> >
> >As I understand the problem, kern/vfs_lookup.c:lookup() could
> >aquire additional locks on Giant, indicating this by GIANTHELD
> >flag in nd. All processing in nfsserver already goes with Giant held,
> >so, I just dropped that excessive locks after return from lookup.
> >System with patch applied survived smoke test (client did
> >du on mounted dir, patch was generated from exported fs, etc.).
> >nfsd eats no more than 25% of CPU (with INVARIANTS).
> >
> >Please, users who reported the problem and willing to help,
> >try the patch (generated against STABLE) and give the feedback.
>=20
> Thank you very much. Your patch actually fixes "nfssvc_nfsd():=20
> debug.mpsafenet=3D1 && Giant" panic during NFS mount of server's "/usr".
> Oddly enough, NFS mount of server's "/" doesn't panic the server.
Because conditions leading to Giant leak usually hold true for
lookup of ".." :)
--gvPGo+RAdjC9O5ul
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFEfpZxC3+MBN1Mb4gRAmlCAKC7xgGsRqzi9uVZbGXUN2qjBbGBTQCgmKI3
mLEOIFTYO6qpb9fwSBo4XO4=
=MzgR
-----END PGP SIGNATURE-----
--gvPGo+RAdjC9O5ul--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060601072538.GZ54541>