Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Feb 2013 10:50:19 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Andrew Turner <andrew@fubar.geek.nz>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@FreeBSD.org>
Subject:   Re: svn commit: r247116 - in head/sys: fs/nfs fs/nfsclient kern nfsclient sys tools
Message-ID:  <20130225085019.GU2454@kib.kiev.ua>
In-Reply-To: <20130225201313.2050da18@bender>
References:  <201302211902.r1LJ2o5T033708@svn.freebsd.org> <20130225201313.2050da18@bender>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <jhb@FreeBSD.org> 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130225085019.GU2454>