Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Sep 2013 22:29:09 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Jilles Tjoelker <jilles@stack.nl>
Cc:        Tijl Coosemans <tijl@coosemans.org>, Russ Cox <rsc@swtch.com>, freebsd-current@FreeBSD.org
Subject:   Re: restarting SYSCALL system call on amd64 loses arguments
Message-ID:  <20130924192909.GO41229@kib.kiev.ua>
In-Reply-To: <20130924191949.GA12607@stack.nl>
References:  <20130923222613.548860a3@kalimero.tijl.coosemans.org> <20130923213730.GX41229@kib.kiev.ua> <20130924191949.GA12607@stack.nl>

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

--1Fyuj5/hnKieOVoO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 24, 2013 at 09:19:49PM +0200, Jilles Tjoelker wrote:
> On Tue, Sep 24, 2013 at 12:37:30AM +0300, Konstantin Belousov wrote:
> > On Mon, Sep 23, 2013 at 10:26:13PM +0200, Tijl Coosemans wrote:
> > > Has anyone taken a look at this PR yet?
>=20
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182161
>=20
> > This looks like a valid bug, but probably not a valid testcase.
>=20
> > Let me elaborate.  When a signal is delivered, return from the signal
> > handler is performed by the sigreturn(2), which reloads the whole
> > register file when crossing kernel->user boundary due to sys_sigreturn(=
9)
> > setting PCB_FULL_IRET flag.  As result, the whole trap frame at the
> > time of the syscall entry is restored, and ERESTART return is not
> > exercised.
>=20
> > I was not able to reproduce the issue with the supplied test program
> > on HEAD.  I suspect that the program actually exposed the bug in the
> > signal delivery in the threaded processes, which I introduced for 9.1
> > and fixed in r251047 & r251365.
>=20
> The ERESTART return happens if there is no signal or no longer a signal.
> The latter is how the bug in the PR occurs: a SIGCHLD delivery via
> handler in one thread races with a SIGCHLD acceptance in wait4() in
> another thread. Note wait4() returning a value in the other thread in
> the fourth line of the kdump output in the PR.
>=20
> For some reason, I can reproduce this easily on my local quad-core
> r255729 stable/9 system but not on ref9-amd64.freebsd.org or
> ref10-amd64.freebsd.org.
>=20
> I can also reproduce the bug on my local system by racing signal
> delivery via handler with acceptance in sigtimedwait().

So, could you, please, check the r255844 on your machine ?

--1Fyuj5/hnKieOVoO
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJSQegFAAoJEJDCuSvBvK1BTtYP/R3Q7xLegWQZUco+26L1XZ1I
mQca1BHv4HByPwSVqhCdOYQ1MMCfy3//is+28ZSdjZKzmIb/Pr+xWSrRMWE4JltY
hM2pUwWg703hTb+tXCo9y4hXKgUNj3KxfEAb1hkdB8bzuoxWOPrrmnIH0jEFwytI
b3KkMa9qFuuXZDkS/zVRf5a/tz0XM3TEfqtgNSRMczZ8Qou49TLqq3FMKKd3vEV4
yYV0O6ktsG9h0r0GH1ZI+Iwbn/2mQoESg9o/wTpStRJbrPGaoakirtPQqwwRiy76
ANXH+neg2H1U3lPodLEkHfDTJTz15xbsa2bmM6JJaefSVo/i3CnSrpfzJyV0nKHS
UZHy+jeVGOvMFh99ewX0yD1Ru1wCr45AaZfhe2DUEQ7riSDEKciHJwjTQdyFDeW4
F7sU/LK93kvYZBYMYCuUq7rieRUmEJVKd1by/0mpjxfl46GbsaP80veG8rEz4gOO
/8meAZ1nYtEGdiDD7Z35A4cbawvoQ0lEnkuFpefvvVX0JcEwpRX8jcun6aVhjl3n
CLMYIK+XOQXU+n46kXdKUv84Wn3lCndd0MCAywss6p/rSOhEaWfcRpha3gTmenpH
P4h62Cfc/kucJkEnbMs8TQQk9KZZAJqZAxWvE1bJEXSc7Ef2Si7yFV+9zie29vWI
oCC68eviuVx8iwDfXbY3
=Ssnb
-----END PGP SIGNATURE-----

--1Fyuj5/hnKieOVoO--



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