From owner-svn-src-head@FreeBSD.ORG Mon Feb 25 08:50:31 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35C16C7C; Mon, 25 Feb 2013 08:50:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 86831745; Mon, 25 Feb 2013 08:50:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1P8oJB7025501; Mon, 25 Feb 2013 10:50:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1P8oJB7025501 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1P8oJAC025500; Mon, 25 Feb 2013 10:50:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Feb 2013 10:50:19 +0200 From: Konstantin Belousov To: Andrew Turner Subject: Re: svn commit: r247116 - in head/sys: fs/nfs fs/nfsclient kern nfsclient sys tools Message-ID: <20130225085019.GU2454@kib.kiev.ua> References: <201302211902.r1LJ2o5T033708@svn.freebsd.org> <20130225201313.2050da18@bender> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eHrxbAcqt/LxKPZN" Content-Disposition: inline In-Reply-To: <20130225201313.2050da18@bender> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:50:31 -0000 --eHrxbAcqt/LxKPZN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2013 at 08:13:13PM +1300, Andrew Turner wrote: > On Thu, 21 Feb 2013 19:02:50 +0000 (UTC) > John Baldwin wrote: >=20 > > Author: jhb > > Date: Thu Feb 21 19:02:50 2013 > > New Revision: 247116 > > URL: http://svnweb.freebsd.org/changeset/base/247116 > >=20 > > Log: > > Further refine the handling of stop signals in the NFS client. The > > changes in r246417 were incomplete as they did not add explicit > > calls to sigdeferstop() around all the places that previously passed > > SBDRY to _sleep(). In addition, nfs_getcacheblk() could trigger a > > write RPC from getblk() resulting in sigdeferstop() recursing. > > Rather than manually deferring stop signals in specific places, > > change the VFS_*() and VOP_*() methods to defer stop signals for > > filesystems which request this behavior via a new VFCF_SBDRY flag. > > Note that this has to be a VFC flag rather than a MNTK flag so that > > it works properly with VFS_MOUNT() when the mount is not yet fully > > constructed. For now, only the NFS clients are set this new flag in > > VFS_SET().=20 > > A few other related changes: > > - Add an assertion to ensure that TDF_SBDRY doesn't leak to > > userland. > > - When a lookup request uses VOP_READLINK() to follow a symlink, > > mark the request as being on behalf of the thread performing the > > lookup (cnp_thread) rather than using a NULL thread pointer. This > > causes NFS to properly handle signals during this VOP on an > > interruptible mount. > > =20 > > PR: kern/176179 > > Reported by: Russell Cattelan (sigdeferstop() recursion) > > Reviewed by: kib > > MFC after: 1 month >=20 > This change is causing init to crash for me on armv6. I'm netbooting a > PandaBoard and it appears init is receiving a SIGABRT before it gets > into main(). >=20 > Do you have any idea where I could look to track down why it is doing > this? It is weird. SIGABRT sent by the kernel usually means that execve(2) already destroyed the previous address space of the process, but the new image cannot be activated, most likely due to image format error discovered too late, or resource shortage. Could it be that some NFS RPC fails after the patch, but I cannot imagine why. You would need to track this. Also, verify that the init binary is correct. I tried amd64 netboot, and it worked fine. --eHrxbAcqt/LxKPZN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRKyXKAAoJEJDCuSvBvK1BrzUQAKJaikkGdd3UCBbUCrf02xkq Fk5bIQGS6EAVwS+2LHH+CAjN9cSZE8QFsTdcZrcpPT7hKpbkjyrSo8vDD3RviERT 11mBtepm7JA8UQOnprnIUMCJny+JOLj9CRiG1+oGPp6Acm1/248wJwShqFC28O4W ApzoxsTacOZ9RO1/jpeR2WGkeB8ypjIsGh+TuFStVfBdkGQihuFl2eaRJPanQn9O esQ1eNkaokWfJD4nXQ0vAtyi6c3HyP1UwLJ4EohcpltIvKUMBWaT6CMwrOYBmLOs Xf9iYpBEsgMqww0ECpIExDIeN326njO36v9AndMsBiYdCfGZ+3eEmcBoohSqQZ8y dJRVIW2YJLN0zWc1c1UC5JnagxdrYzrB6ms2ZCTWdhh59HiTXqQXm+/6vO49I0Gb gWnD6H13JEzfv0sfBe/ZaIb3VFstRmCqtdDAOC9PYyF6t7dc+mzZd+CfkC6ShJbp /2C9nT+E8FbWdwHZ2Y7VOTmm2IZYs3M2P0nOKOfkfQMkAZ1OBrWLwJtclslIA+2e cS1enDYZ6DTmGNDKMqv10qqyOqpFhEnneTvwvRldtpSw76A5SgHJjncfpAEc1i34 qEJXKkMfCMvMzZFEj1kGu7gFcXmWGrRk25jSpMWFraBQ2g1jqiOOdT5MHAZe5AKi pRYiLhYfc70IvI4b3+YX =k2Fp -----END PGP SIGNATURE----- --eHrxbAcqt/LxKPZN--