Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Feb 2013 13:55:00 +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:  <20130225115500.GW2454@kib.kiev.ua>
In-Reply-To: <20130225233603.49a5d4a5@bender>
References:  <201302211902.r1LJ2o5T033708@svn.freebsd.org> <20130225201313.2050da18@bender> <20130225085019.GU2454@kib.kiev.ua> <20130225233603.49a5d4a5@bender>

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

--GVLQrlG8+/jMfW4X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 25, 2013 at 11:36:03PM +1300, Andrew Turner wrote:
> On Mon, 25 Feb 2013 10:50:19 +0200
> Konstantin Belousov <kostikbel@gmail.com> wrote:
>=20
> > 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(). 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?
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > I tried amd64 netboot, and it worked fine.
>=20
> It looks like this change is not the issue, it just changed the
> symptom enough for me to not realise I was seeing an issue where
> it would crash the kernel before. I reinstated this change but only
> allowed the kernel to access half the memory and it booted correctly.
>=20
> The real issue appears to be related to something in the vm layer not
> working on ARM boards with too much memory (somewhere between 512MiB
> and 1GiB).

Hm, do you have r246926, r246929 and r247046 ?

--GVLQrlG8+/jMfW4X
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBAgAGBQJRK1ETAAoJEJDCuSvBvK1Bu9EP/2ymcl0cpBUfw1VGwy3++vJM
/A+0ON4aj/5mHCOyp526FUD5OMscS7wWMKWQuFdj4rueYFk7ctJjbmHM3xu4CJQZ
xUxCAr13YJvuTwpkMQerM/YtFF9UzeKOkUKag4K4ozfmVeDjuoyLZu3rdSJPzsjl
BPDww5dSr3UFUW2yQkMQMlrrhYIU0g79BUQsWgLJWH16dzRuGn4knMbor/l4bhyL
37Sb0huWawU1kaPzrJFahPyeov2AuQsDpGdv7eOdYCGLDtzYbMXAv4mo8b3Th7sX
E0ZG1eU/+kObUnI67zpRUl2jl/c5VrVfY21NBePW1PMfzpbze7jFoJtqs45G1NXU
fGfg1NLeX3H/8k/qj0BOE1gX+MI+FzRYgCW7M8YUIxQhGk3FyW06LqrGDLDUIaeW
E03UAJxhmVw7femVLmvpH+ZCOaBDXximEhIfH4c0DTwH+kSbTR3U+31tCXMrC08r
qXWbEAnOTDcWJvhIPmlrP2eI/z0MxYwFSBdClM2s/grPeQatFZbIvBzsdAxthw76
khK0GqmxGyrnYUi5wRrfBz5STpRqZxGiCe0tfOFvGmUj8Ba0xV8G0eDAdUbG9f1f
OMDs9jHSZkilDnX3uOTBpohXUS7ioERGCvsrjdyX9Z5duTZC8A2I99ks1VwiuagA
C747Nh4J7fKXXIVo0r8x
=STI5
-----END PGP SIGNATURE-----

--GVLQrlG8+/jMfW4X--



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