Date: Thu, 9 Mar 2017 16:59:06 -0800 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: current@FreeBSD.org Subject: Re: r314708: panic: tdsendsignal: ksi on queue Message-ID: <767b31de-835f-8fa6-85fb-34b276452479@FreeBSD.org> In-Reply-To: <b7068678-e593-f4ed-647c-036ff0bc0576@FreeBSD.org> References: <d510a9da-8293-ba22-a1e6-75b3ea7ffa1d@FreeBSD.org> <20170309144646.GB16105@kib.kiev.ua> <20170309231151.GA49720@stack.nl> <5e56d3d6-9e92-1b50-f720-ff16c58b74dd@FreeBSD.org> <b7068678-e593-f4ed-647c-036ff0bc0576@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--QP1GQLRuUmbkwqKSWM5oobCc7o11aUVeO
Content-Type: multipart/mixed; boundary="uugKUSaHPc74QvJ52oEUpSqha7TPvbl5X";
protected-headers="v1"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: current@FreeBSD.org
Message-ID: <767b31de-835f-8fa6-85fb-34b276452479@FreeBSD.org>
Subject: Re: r314708: panic: tdsendsignal: ksi on queue
References: <d510a9da-8293-ba22-a1e6-75b3ea7ffa1d@FreeBSD.org>
<20170309144646.GB16105@kib.kiev.ua> <20170309231151.GA49720@stack.nl>
<5e56d3d6-9e92-1b50-f720-ff16c58b74dd@FreeBSD.org>
<b7068678-e593-f4ed-647c-036ff0bc0576@FreeBSD.org>
In-Reply-To: <b7068678-e593-f4ed-647c-036ff0bc0576@FreeBSD.org>
--uugKUSaHPc74QvJ52oEUpSqha7TPvbl5X
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 3/9/2017 3:57 PM, Bryan Drewery wrote:
> On 3/9/2017 3:47 PM, Bryan Drewery wrote:
>> On 3/9/2017 3:11 PM, Jilles Tjoelker wrote:
>>> On Thu, Mar 09, 2017 at 04:46:46PM +0200, Konstantin Belousov wrote:
>>>> Yes, there is a race, apparently, with the child zombie still not fi=
nishing
>>>> sending the SIGCHLD to the parent and parent exiting. The following=
should
>>>> fix the issue, but I do not think that reproducing the problem is ea=
sy.
>>>
>>>> diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c
>>>> index c524fe5df37..ba5ff84e9de 100644
>>>> --- a/sys/kern/kern_exit.c
>>>> +++ b/sys/kern/kern_exit.c
>>>> @@ -189,6 +189,7 @@ exit1(struct thread *td, int rval, int signo)
>>>> {
>>>> struct proc *p, *nq, *q, *t;
>>>> struct thread *tdt;
>>>> + ksiginfo_t ksi;
>>>> =20
>>>> mtx_assert(&Giant, MA_NOTOWNED);
>>>> KASSERT(rval =3D=3D 0 || signo =3D=3D 0, ("exit1 rv %d sig %d", rv=
al, signo));
>>>> @@ -456,7 +457,12 @@ exit1(struct thread *td, int rval, int signo)
>>>> proc_reparent(q, q->p_reaper);
>>>> if (q->p_state =3D=3D PRS_ZOMBIE) {
>>>> PROC_LOCK(q->p_reaper);
>>>> - pksignal(q->p_reaper, SIGCHLD, q->p_ksi);
>>>> + if (q->p_ksi !=3D NULL) {
>>>> + ksiginfo_init(&ksi);
>>>> + ksiginfo_copy(q->p_ksi, &ksi);
>>>> + }
>>>> + pksignal(q->p_reaper, SIGCHLD, q->p_ksi !=3D
>>>> + NULL ? &ksi : NULL);
>>>> PROC_UNLOCK(q->p_reaper);
>>>> }
>>>> } else {
>>
>> I just got something weird with this patch that wasn't happening befor=
e:
>>
>> /usr/bin/time -l src/bin/poudriere -e /usr/local/etc testport -j
>> exp-10amd64 -p commit -z test devel/ccache
>> [poudriere runs and completes with exit status 0]
>>> time: command terminated abnormally =
=20
>>> 28.08 real 9.92 user 10.38 sys =
=20
>>> 23464 maximum resident set size =
=20
>>> 4996 average shared memory size =
=20
>>> 88 average unshared data size =
=20
>>> 127 average unshared stack size =
=20
>>> 282705 page reclaims =
=20
>>> 5623 page faults =
=20
>>> 0 swaps =
=20
>>> 2673 block input operations =
=20
>>> 4836 block output operations =
=20
>>> 33 messages sent =
=20
>>> 0 messages received =
=20
>>> 37 signals received =
=20
>>> 11226 voluntary context switches =
=20
>>> 780 involuntary context switches =
=20
>>> zsh: alarm /usr/bin/time -l src/bin/poudriere -e /usr/local/etc =
testport -j exp-10amd64
>> exit status: 142 (SIGALRM).
>>
>> I don't see time(1) using SIGALRM or proc reaper at all.
>>
>> Rerunning it, and trying other simpler test cases, does not produce th=
e
>> same result. It may be some race unrelated to this patch, dunno.
>>
>=20
> I'm consistently getting foreground processes getting the wrong signals=
> now. I'm removing this patch for now.
It wasn't this patch doing this. Something else is very wrong with
signal handling right now.
>=20
>>
>>>
>>> This patch introduces a subtle correctness bug. A real SIGCHLD ksigin=
fo
>>> should always be the zombie's p_ksi; otherwise, the siginfo may be lo=
st
>>> if there are too many signals pending for the target process or in th=
e
>>> system. If the siginfo is lost and the reaper normally passes si_pid =
to
>>> waitpid() or similar (instead of passing WAIT_ANY or P_ALL), a zombie=
>>> will remain until the reaper terminates.
>>>
>>> Conceptually the siginfo is sent to one process at a time only, so th=
e
>>> bug is an artifact of the implementation. Perhaps the piece of code
>>> added in r309886 can be moved or the ksiginfo can be removed from the=
>>> parent's queue.
>>>
>>> If such a fix is not possible, it may be better to send a bare SIGCHL=
D
>>> (si_code is SI_KERNEL or 0, depending on how many signals are pending=
)
>>> in this situation and document that reapers must use WAIT_ANY or P_AL=
L.
>>> (However, compared to the pre-r309886 situation they can still use
>>> SIGCHLD to get notified when to call waitpid() or similar.)
>>>
>>
>>
>=20
>=20
--=20
Regards,
Bryan Drewery
--uugKUSaHPc74QvJ52oEUpSqha7TPvbl5X--
--QP1GQLRuUmbkwqKSWM5oobCc7o11aUVeO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJYwfpaAAoJEDXXcbtuRpfPZYoH/iLLdrNbPyPRsrRoXn512hYa
4DTOuBVfQTS6eH7t1d8OGIqpWCNfEF3orYvwy3dIjPSXoWpT3y0JqWs3pk3ppugf
3TLGB3A/L+dNeefaJ/2MlOdbGsNKFVr7JtAnuycP2LYaydbSaRV2V5j5oUAS0+sg
IVXgyefSMzGGLDyhUmHC9V8a/cF4+XWJYr11pUN2xg5A40jWvz18TLhWTtZaUKpi
WBFii1dsiDtgF4aKzs4FQOtupE5okxGugAFvpD/5EHlgkHzXv+yvxAG1Vh/bvjA7
XQ5OG/a/uLsvT6eqr17aX+86ozJjk6lJDkhU1TqXfPf5k7HrlcioPh34MARLxuc=
=C+7A
-----END PGP SIGNATURE-----
--QP1GQLRuUmbkwqKSWM5oobCc7o11aUVeO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?767b31de-835f-8fa6-85fb-34b276452479>