--==========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"
--5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ--
--==========EF6328C82A1CE901E152==========--
--==========C0CB1C4A269A2DB8FD87==========--