[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: (ITS#6300) Issues with kqueue after fork

To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6300) Issues with kqueue after fork
From: quanah@symas.com
Date: Tue, 24 Apr 2018 21:45:52 +0000
Auto-submitted: auto-generated (OpenLDAP-ITS)
--==========C0CB1C4A269A2DB8FD87==========
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Date: Monday, October 23, 2017 12:43 AM -0700
From: Xin Li
To: Quanah Gibson-Mount

Hi Quanah,

I finally got some time to twiddle with OpenLDAP (again).  It looks like
the EBADF is expected, because fork(2) says:

           =E2=80=A2   The child process has its own copy of the parent's
               descriptors, except for descriptors returned by
               kqueue(2), which are not inherited from the parent
               process.

And slapd does have a fork() after the initial kqueue(), which rendered
it invalid.

The kqueue() is part of SLAP_SOCK_INIT(), which is part of
slapd_daemon_init().  Then, after that, fork() happen in lutil_detach(),
and doing this hack would (incorrectly) make slapd to start:

diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c
index c6464c038..f47d36548 100644
--- a/libraries/liblutil/detach.c
+++ b/libraries/liblutil/detach.c
@@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close )
 #ifdef HAVE_THR
                        pid =3D fork1();
 #else
-                       pid =3D fork();
+                       pid =3D rfork(RFPROC);
 #endif
                        switch ( pid )
                        {

It is incorrect because the code in slapd/main.c seems to expect the
child to write a "1" to it before exiting with EXIT_SUCCESS() and
obviously if the two processes shares the same file table, the parent
would consider the start was failed because read() would fail.

I think the right fix would be to move the lutil_detach() to before
slapd_daemon_init(), see attachment, but it seems that some code after
the initial daemon initialization is still trying to output to stderr, etc.

What do you think?

Cheers,

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

--==========C0CB1C4A269A2DB8FD87==========
Content-Type: message/rfc822;
 name="Re: kqueue in OpenLDAP for FreeBSD (fwd)"

Date: Tue, 24 Apr 2018 14:28:57 -0700
From: Quanah Gibson-Mount <quanah@symas.com>
Reply-To: Quanah Gibson-Mount <quanah@symas.com>
To: Howard Chu <hyc@symas.com>
Subject: Re: kqueue in OpenLDAP for FreeBSD (fwd)
Message-ID: <49431EE1A7D095C608D778A4@[192.168.1.10]>
X-Mailer: Mulberry/4.0.9a1 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="==========EF6328C82A1CE901E152=========="

--==========EF6328C82A1CE901E152==========
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

kqueue issues with slapd

--Quanah

------------ Forwarded Message ------------
Date: Monday, October 23, 2017 12:43 AM -0700
From: Xin Li <delphij@delphij.net>
To: Quanah Gibson-Mount <quanah@symas.com>, Xin LI <delphij@gmail.com>
Cc: d@delphij.net, Pietro Cerutti <gahr@gahr.ch>, Xin LI=20
<delphij@freebsd.org>
Subject: Re: kqueue in OpenLDAP for FreeBSD

Hi, Quanah,

I finally got some time to twiddle with OpenLDAP (again).  It looks like
the EBADF is expected, because fork(2) says:

           =E2=80=A2   The child process has its own copy of the parent's
               descriptors, except for descriptors returned by
               kqueue(2), which are not inherited from the parent
               process.

And slapd does have a fork() after the initial kqueue(), which rendered
it invalid.

The kqueue() is part of SLAP_SOCK_INIT(), which is part of
slapd_daemon_init().  Then, after that, fork() happen in lutil_detach(),
and doing this hack would (incorrectly) make slapd to start:

diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c
index c6464c038..f47d36548 100644
--- a/libraries/liblutil/detach.c
+++ b/libraries/liblutil/detach.c
@@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close )
 #ifdef HAVE_THR
                        pid =3D fork1();
 #else
-                       pid =3D fork();
+                       pid =3D rfork(RFPROC);
 #endif
                        switch ( pid )
                        {

It is incorrect because the code in slapd/main.c seems to expect the
child to write a "1" to it before exiting with EXIT_SUCCESS() and
obviously if the two processes shares the same file table, the parent
would consider the start was failed because read() would fail.

I think the right fix would be to move the lutil_detach() to before
slapd_daemon_init(), see attachment, but it seems that some code after
the initial daemon initialization is still trying to output to stderr, etc.

What do you think?

Cheers,

On 10/20/17 09:00, Quanah Gibson-Mount wrote:
> --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount
> <quanah@symas.com> wrote:
>
>> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd =
to as
>> minimal a build as possible with my configure:
>>
>> ./configure --without-tls --without-cyrus-sasl --enable-ldap
>> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite
>> --enable-rwm --prefix=3D/tmp/q
>
>
> I've updated my configure to:
>
> CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED
> -fno-strict-aliasing" \
> ./configure \
> --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl =
--disable-dependency-tracking \
> --enable-dynamic --without-cyrus-sasl \
> --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \
> --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \
> --enable-monitor --disable-seqmod --enable-syncprov \
> --enable-mdb --without-fetch \
> --prefix=3D/tmp/q
>
>
> And I still have no issues.=C2=A0 I'm unable to get the freebsd version =
of
> libtool to build shared libraries, so I can't test dynamic modules.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>

---------- End Forwarded Message ----------



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

--==========EF6328C82A1CE901E152==========
Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD"

Return-Path: delphij@delphij.net
Received: from 127.37.197.104.bc.googleusercontent.com (LHLO
 zmcc-5-mta-1.zmailcloud.com) (104.197.37.127) by
 zmcc-5-mailbox-1.zmailcloud.com with LMTP; Mon, 23 Oct 2017 01:43:19 -0500
 (CDT)
Received: from localhost (localhost [127.0.0.1])
	by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 57E10C0814
	for <qgibson-mount@symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT)
X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com
Authentication-Results: zmcc-5-mta-1.zmailcloud.com (amavisd-new);
	dkim=fail (1024-bit key) reason="fail (message has been altered)"
	header.d=delphij.net
Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1])
	by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Wrlpf0yr3bg2 for <qgibson-mount@symas.com>;
	Mon, 23 Oct 2017 01:43:19 -0500 (CDT)
Received: from mailstronghold-1.zmailcloud.com (254.215.154.104.bc.googleusercontent.com [104.154.215.254])
	by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 36497C06D2
	for <quanah@symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT)
Received: from mailstronghold-1.zmailcloud.com (localhost.localdomain [127.0.0.1])
	by mailstronghold-1.zmailcloud.com (8.13.8/8.13.8) with ESMTP id v9N4CeHI010656
	for <quanah@symas.com>; Mon, 23 Oct 2017 01:43:18 -0500
X-Haraka-RcptSummary: valid=1 invalid=0 unverified=0 relay=0 norelay=0
Received-SPF: Pass (mailstronghold-1.zmailcloud.com: domain of delphij.net designates 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=mailfrom; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij@delphij.net>
Received-SPF: None (mailstronghold-1.zmailcloud.com: domain of anubis.delphij.net does not designate 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=helo; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij@delphij.net>
Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212])
	by mailstronghold-1.zmailcloud.com (Haraka/2.2.8) with ESMTPS id 44429DF9-9A11-41FD-AF40-A85A1E9CCAE7.1
	envelope-from <delphij@delphij.net>
	(version=TLSv1/SSLv3 cipher=AES256-SHA verify=OK);
	Mon, 23 Oct 2017 01:43:14 -0500
Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:c09f:c4b5:916b:f99])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by anubis.delphij.net (Postfix) with ESMTPSA id 7315321847;
	Sun, 22 Oct 2017 23:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net;
	s=anubis; t=1508740990; x=1508755390;
	bh=lHOLEU7RrRbdsqZiIrERFdjtGcmjK0d4J65y4NciNAE=;
	h=Cc:Subject:To:References:From:Date:In-Reply-To;
	b=pSf21voW+1hi95e1Gk7n0Etfo4WpoqUlF4m7Ukgp6+Sw1OreGQEjQPiBMq0Wo6htG
	 P/+uPZswNtPxpr/6yGE9Fsrxku8Bygk6Qv/o3pR9rRe0bKhvrh+jqAcM0KvcjgG9cV
	 geciuENhFuihiQm9Jh/4383kqyrcrgnufON8XY4Q=
Cc: d@delphij.net, Pietro Cerutti <gahr@gahr.ch>, Xin LI <delphij@freebsd.org>
Subject: Re: kqueue in OpenLDAP for FreeBSD
To: Quanah Gibson-Mount <quanah@symas.com>, Xin LI <delphij@gmail.com>
From: Xin Li <delphij@delphij.net>
Date: Sun, 22 Oct 2017 23:43:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <77291973D4E980CDD2C6B12D@[192.168.1.30]>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ"
X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N
X-Haraka-GeoIP: US
X-Haraka-GeoIP-Received: 64.62.153.212:US
X-Haraka-rDNS: anubis.delphij.net
X-Haraka-FCrDNS: anubis.delphij.net
X-Haraka-HostID: delphij.net
X-Haraka-SenderAuth: 64.62.153.212 delphij.net
X-Haraka-Domain-Info: domain="delphij.net" last_update=176 primary_ns="ns-us.delphij.net" serial=2017043060 refresh=7200 retry=3600 expiration=604800 minimum=14400 flags=""
X-Haraka-Watermark: references:WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com
References: <1EEAC653239F6692643DB632@192.168.1.30>
 <058DB23288D5009E6DBB5BCD@192.168.1.30>
 <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg@mail.gmail.com>
 <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!@mailstronghold-2.zmailcloud.com>
 <6C1DC7E9BE41FA3CD93838AC@192.168.1.30>
 <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA@mail.gmail.com>
 <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!@mailstronghold-3.zmailcloud.com>
 <62041328E5AFD06BBFCFDF96@[192.168.1.30]>
 <D8979E6E67B623588F99E3B7@[192.168.1.30]>
 <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4@delphij.net>
 <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com>
 <A3DFF2D02CD1C134AAC9771D@[192.168.1.30]>
 <77291973D4E980CDD2C6B12D@[192.168.1.30]>
 <cff1e448-975f-f832-4ced-7c68108abf49@delphij.net>
Message-Id: <WM!ff18dbc4fd0ca98069f4da171165aabfe0351a19a07c5c098b191f5850c1c079bf8b820779722c14189597ab2ab2028a!@mailstronghold-1.zmailcloud.com>
X-FSL-MailScanner-Information: Please contact postmaster@zmailcloud.com for more information
X-FSL-MailScanner-ID: v9N4CeHI010656
X-FSL-MailScanner: Found to be clean
X-Dirty-Status: 
X-FSL-MailScanner-From: delphij@delphij.net

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ
Content-Type: multipart/mixed; boundary="SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl";
 protected-headers="v1"
From: Xin Li <delphij@delphij.net>
To: Quanah Gibson-Mount <quanah@symas.com>, Xin LI <delphij@gmail.com>
Cc: d@delphij.net, Pietro Cerutti <gahr@gahr.ch>, Xin LI <delphij@freebsd.org>
Message-ID: <cff1e448-975f-f832-4ced-7c68108abf49@delphij.net>
Subject: Re: kqueue in OpenLDAP for FreeBSD
References: <1EEAC653239F6692643DB632@192.168.1.30>
 <WM!652ba1f610b07a3646a24508aa83d70e7fbfbbbf4a02ab2f4f5c75bea4ea7433084f5a08cbd2551d01ebcc1be8bfada2!@mailstronghold-3.zmailcloud.com>
 <806290B685E4C0A58E186335@192.168.1.30>
 <a77bd491-68e1-d071-90d1-f081685137cd@delphij.net>
 <WM!9301149f169acc8af0f3fbefd6be96ab8874fd401aaf6373e9390d058b5fc3a788bd3202b6db71ad2dcfda2aec5e5b59!@mailstronghold-3.zmailcloud.com>
 <058DB23288D5009E6DBB5BCD@192.168.1.30>
 <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg@mail.gmail.com>
 <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!@mailstronghold-2.zmailcloud.com>
 <6C1DC7E9BE41FA3CD93838AC@192.168.1.30>
 <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA@mail.gmail.com>
 <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!@mailstronghold-3.zmailcloud.com>
 <62041328E5AFD06BBFCFDF96@[192.168.1.30]>
 <D8979E6E67B623588F99E3B7@[192.168.1.30]>
 <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4@delphij.net>
 <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com>
 <A3DFF2D02CD1C134AAC9771D@[192.168.1.30]>
 <77291973D4E980CDD2C6B12D@[192.168.1.30]>
In-Reply-To: <77291973D4E980CDD2C6B12D@[192.168.1.30]>

--SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl
Content-Type: multipart/mixed;
 boundary="------------617F49AD045D5D9CF20DDEA9"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------617F49AD045D5D9CF20DDEA9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi, Quanah,

I finally got some time to twiddle with OpenLDAP (again).  It looks like
the EBADF is expected, because fork(2) says:

           =E2=80=A2   The child process has its own copy of the parent's=

               descriptors, except for descriptors returned by
               kqueue(2), which are not inherited from the parent
               process.

And slapd does have a fork() after the initial kqueue(), which rendered
it invalid.

The kqueue() is part of SLAP_SOCK_INIT(), which is part of
slapd_daemon_init().  Then, after that, fork() happen in lutil_detach(),
and doing this hack would (incorrectly) make slapd to start:

diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c
index c6464c038..f47d36548 100644
--- a/libraries/liblutil/detach.c
+++ b/libraries/liblutil/detach.c
@@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close )
 #ifdef HAVE_THR
                        pid =3D fork1();
 #else
-                       pid =3D fork();
+                       pid =3D rfork(RFPROC);
 #endif
                        switch ( pid )
                        {

It is incorrect because the code in slapd/main.c seems to expect the
child to write a "1" to it before exiting with EXIT_SUCCESS() and
obviously if the two processes shares the same file table, the parent
would consider the start was failed because read() would fail.

I think the right fix would be to move the lutil_detach() to before
slapd_daemon_init(), see attachment, but it seems that some code after
the initial daemon initialization is still trying to output to stderr, et=
c.

What do you think?

Cheers,

On 10/20/17 09:00, Quanah Gibson-Mount wrote:
> --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount
> <quanah@symas.com> wrote:
>=20
>> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd=
 to as
>> minimal a build as possible with my configure:
>>
>> ./configure --without-tls --without-cyrus-sasl --enable-ldap
>> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite
>> --enable-rwm --prefix=3D/tmp/q
>=20
>=20
> I've updated my configure to:
>=20
> CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED
> -fno-strict-aliasing" \
> ./configure \
> --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl --disable-dependency-=
tracking \
> --enable-dynamic --without-cyrus-sasl \
> --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \
> --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \
> --enable-monitor --disable-seqmod --enable-syncprov \
> --enable-mdb --without-fetch \
> --prefix=3D/tmp/q
>=20
>=20
> And I still have no issues.=C2=A0 I'm unable to get the freebsd version=
 of
> libtool to build shared libraries, so I can't test dynamic modules.
>=20
> --Quanah
>=20
>=20
> --=20
>=20
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>=20

--------------617F49AD045D5D9CF20DDEA9
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
 name="slapd-workaround.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="slapd-workaround.patch"

ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvbWFpbi5jIGIvc2VydmVycy9zbGFwZC9tYWlu
LmMKaW5kZXggMGEwNTNjM2VlLi4xOGQ4NDBjNWEgMTAwNjQ0Ci0tLSBhL3NlcnZlcnMvc2xh
cGQvbWFpbi5jCisrKyBiL3NlcnZlcnMvc2xhcGQvbWFpbi5jCkBAIC02OTIsNiArNjkyLDkg
QEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJYmVyX3NldF9vcHRpb24oTlVMTCwgTEJFUl9PUFRf
REVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGFwX3NldF9vcHRpb24oTlVMTCwgTERB
UF9PUFRfREVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGlmX2RlYnVnID0gc2xhcF9k
ZWJ1ZzsKKwlpZiAoIGNoZWNrICE9IENIRUNLX05PTkUgKSB7CisJCW5vX2RldGFjaCA9IDE7
CisJfQogCiAJaWYgKCB2ZXJzaW9uICkgewogCQlmcHJpbnRmKCBzdGRlcnIsICIlc1xuIiwg
VmVyc2lvbnN0ciApOwpAQCAtNzM5LDYgKzc0MiwyOSBAQCB1bmhhbmRsZWRfb3B0aW9uOjsK
IAlnbG9iYWxfaG9zdCA9IGxkYXBfcHZ0X2dldF9mcWRuKCBOVUxMICk7CiAJYmVyX3N0cjJi
diggZ2xvYmFsX2hvc3QsIDAsIDAsICZnbG9iYWxfaG9zdF9idiApOwogCisjaWZuZGVmIEhB
VkVfV0lOU09DSworCWlmICggIW5vX2RldGFjaCApIHsKKwkJaWYgKCBsdXRpbF9wYWlyKCB3
YWl0ZmRzICkgPCAwICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQkJCSJtYWlu
OiBsdXRpbF9wYWlyIGZhaWxlZDogJWRcbiIsCisJCQkJMCwgMCwgMCApOworCQkJcmMgPSAx
OworCQkJZ290byBkZXN0cm95OworCQl9CisJCXBpZCA9IGx1dGlsX2RldGFjaCggbm9fZGV0
YWNoLCAwICk7CisJCWlmICggcGlkICkgeworCQkJY2hhciBidWZbNF07CisJCQlyYyA9IEVY
SVRfU1VDQ0VTUzsKKwkJCWNsb3NlKCB3YWl0ZmRzWzFdICk7CisJCQlpZiAoIHJlYWQoIHdh
aXRmZHNbMF0sIGJ1ZiwgMSApICE9IDEgKQorCQkJCXJjID0gRVhJVF9GQUlMVVJFOworCQkJ
X2V4aXQoIHJjICk7CisJCX0gZWxzZSB7CisJCQljbG9zZSggd2FpdGZkc1swXSApOworCQl9
CisJfQorI2VuZGlmIC8qIEhBVkVfV0lOU09DSyAqLworCiAJaWYoIGNoZWNrID09IENIRUNL
X05PTkUgJiYgc2xhcGRfZGFlbW9uX2luaXQoIHVybHMgKSAhPSAwICkgewogCQlyYyA9IDE7
CiAJCVNFUlZJQ0VfRVhJVCggRVJST1JfU0VSVklDRV9TUEVDSUZJQ19FUlJPUiwgMTYgKTsK
QEAgLTkxMSwyOSArOTM3LDYgQEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJKHZvaWQpIFNJR05B
TCggU0lHQlJFQUssIHNsYXBfc2lnX3NodXRkb3duICk7CiAjZW5kaWYKIAotI2lmbmRlZiBI
QVZFX1dJTlNPQ0sKLQlpZiAoICFub19kZXRhY2ggKSB7Ci0JCWlmICggbHV0aWxfcGFpcigg
d2FpdGZkcyApIDwgMCApIHsKLQkJCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKLQkJCQkibWFp
bjogbHV0aWxfcGFpciBmYWlsZWQ6ICVkXG4iLAotCQkJCTAsIDAsIDAgKTsKLQkJCXJjID0g
MTsKLQkJCWdvdG8gZGVzdHJveTsKLQkJfQotCQlwaWQgPSBsdXRpbF9kZXRhY2goIG5vX2Rl
dGFjaCwgMCApOwotCQlpZiAoIHBpZCApIHsKLQkJCWNoYXIgYnVmWzRdOwotCQkJcmMgPSBF
WElUX1NVQ0NFU1M7Ci0JCQljbG9zZSggd2FpdGZkc1sxXSApOwotCQkJaWYgKCByZWFkKCB3
YWl0ZmRzWzBdLCBidWYsIDEgKSAhPSAxICkKLQkJCQlyYyA9IEVYSVRfRkFJTFVSRTsKLQkJ
CV9leGl0KCByYyApOwotCQl9IGVsc2UgewotCQkJY2xvc2UoIHdhaXRmZHNbMF0gKTsKLQkJ
fQotCX0KLSNlbmRpZiAvKiBIQVZFX1dJTlNPQ0sgKi8KLQogI2lmZGVmIENTUklNQUxMT0MK
IAltYWxfbGVha3RyYWNlKDEpOwogI2VuZGlmCg==
--------------617F49AD045D5D9CF20DDEA9--

--SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl--

--5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZ7Y99AAoJEJW2GBstM+nstpMP/0zXWEdlSWycZyYU8ukkLUju
Bd+3oVJyhwuVFhVHp4mts+nApF6+yPzMTlhT930cyD+LJ5TLrfaR9bVoVkix0LMk
YX7KF7jHWZU/B7+o4VR1l/oMFoRr4qSXQ+hiFgiDZg+id8s9CxnndzmbWK+vgRSp
j2ynuh7aQbLBkkao8mfHG/UbDvTvre8BVw9WF/vidwieDGOITo28088ZbX8XgjTO
9e7WFw+ftnFKkv63o/GDOCo+1zFm7n+F7gv4DmZYrt3ZdHCcSRkHMXPltf/4/IRX
pFve1h24mPsq0sqit1wsDj2k3f3cJRN4rEShIBfiZm1y4rmCFC8ogDyllBdEbqRd
RoN2ol6nh2k38qR4WAHhMFRyCUgUnqYevC7L+AlUAXiweSgzUKfVZt0bpiVnZPDT
NiuAX1fBBQIySWzF/iM4d3VPIZdPmcme72kRCLcpbViTW+u4/n+RJEdKl4QRSSrw
5DzVwZDLgl16Ch+YLUYoaSyyk8strbe62owDf6GOb4Pnwy3wBf5o1oIsn/tcu6mh
JA2IIVQ9mS3rwDgnL9O7GxrAmWFgpzZmBEC9mYbOToW4EMzDMBj4M7cwrLAVpae7
8KDX5xWX8swr56W8/8PQayLf574lPBhx9QZorKnoIzycHXCI/NkXbW9NBJTr/LLk
0etBpNlk83eCTvtejbbR
=dl/v
-----END PGP SIGNATURE-----

--5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ--

--==========EF6328C82A1CE901E152==========--

--==========C0CB1C4A269A2DB8FD87==========--
Prev by Date: Re: (ITS#8840) domainScope control is not properly implemented
Next by Date: (ITS#8725) Disable cleanup of extended operations if they are asynchronous
Index(es):
- Chronological
- Thread