Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:762 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16850 invoked from network); 7 Apr 2003 16:55:40 -0000 Received: from unknown (HELO mail.sogei.it) (195.223.91.164) by pb1.pair.com with SMTP; 7 Apr 2003 16:55:40 -0000 Received: from mailfilter01.domus.ad.sogei.it (mailfilter01.sogei.it [26.2.193.99]) by mail.sogei.it (8.11.4/8.8.4) with SMTP id h37DQNW26551 for ; Mon, 7 Apr 2003 15:26:23 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2FD26.8196DFA1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 7 Apr 2003 18:55:34 +0200 Message-ID: <7410A5117CDC9C4CA07FBC870D65A50D1B4BB0@MAILBOX01.domus.ad.sogei.it> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PATCH] OCI8 module - proposed patches (PART 1 of 2) Thread-Index: AcL9FGYKB+1ftQVUTnGHn6fRUqsb3AADaRbwAADyjyA= To: Subject: [PATCH] OCI8 module - proposed patches (PART 1 of 2) From: msquillace@sogei.it ("SQUILLACE MASSIMO") ------_=_NextPart_001_01C2FD26.8196DFA1 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C2FD26.8196DFA1" ------_=_NextPart_002_01C2FD26.8196DFA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I had to split the original message in two e-mails because it was longer than 30000 bytes. In this first message you'll find the commentary and the first attachment, the second message contains the second attachment. =20 Massimo =20 ------------------------------------------------------------------------ ------------------------------------------------ =20 Hi all,=20 =20 since posting bug #22674 resulted in no feedback to date and I believe OCI8 persistent session management should quickly be fixed, I studied the sources and came up with a solution to that particular bug and more. =20 The solutions have been working for a week now on two PHP 4.2.2 and two PHP 4.3.1 servers, so this weekend I downloaded the current CVS snapshot and applied them there. =20 Here follows a description of the problems and the proposed patches: =20 1) [Solves bug #22674, part 1] The sequence OCIPLOGON('user1', 'pwd1', 'db1') + OCILOGON('user2', 'pwd2', 'db1') creates two persistent session handles instead of one, because the OCILOGON session wrongly "inherits" the persistency attribute of the OCIPLOGON session; BOTH sessions can be reused. I fixed one assignment statement in oci_do_connect. =20 2) [Solves bug #22674, part 2] The sequence OCIPLOGON + OCILOGON + OCINLOGON (same dbname for all, same userid and password for the latter 2 calls) still creates two persistent session handles instead of one, but the session structure set up by OCILOGON is incorrectly freed when the module cleans up the OCINLOGON structures, so that while Oracle still sees the surplus session PHP cannot reuse it in subsequent scripts. This leads to a session build-up with Oracle eventually giving up. The problem lies in the way hashed_details is built: it is the same for OCILOGON and OCINLOGON, so when zend_hash_del is called during cleanup it deletes BOTH structures. I re-defined the hashed_details for OCINLOGON using gettimeofday(), so each OCINLOGON structure is now unique and different from any OCILOGON structure. =20 These first two patches are in the attached twobugs.txt file; if they are accepted bug #22674 may be closed. =20 I also attach a fourpatches.txt file, which contains the above solutions and two more patches I'd like to submit to your attention, since I believe they could help make the module more flexible: =20 3) More often than not Oracle installations do NOT provide for a user-defined "password verification function", so that userid, password and dbname are treated case-insensitively by the RDBMS, while the OCI8 module generates hashed_details that are case-sensitive. If the programmers mix case during development this leads to an excessive number of persistent sessions to Oracle. I introduced a php_ini boolean variable credentials_toupper which, when true (defaults to false), triggers uppercase conversion of userid, password and dbname before their use in oci_do_connect. =20 4) When the web servers are behind a firewall in a DMZ, the firewall truncates sessions when they reach a configurable but unavoidable inactivity timeout. This invalidates persistent sessions and in my experience (if the firewall doesn't specifically support SQL*NET) can't always be circumvented by a decrease in the tcp_keepalive_time; also, I'd rather leave such parameters at their default and let the firewall do its work which is dictated by security concerns. Idle persistent sessions are useless by themselves and should anyway be closed as soon as feasible to minimize load on the RDBMS. In past client-server (OS/2) applications I came up with a thread-based solution which automatically closed the client's Oracle connection after a configurable inactivity timeout, but since I don't know if this should be done in the current PHP implementation I simply decided to add a timestamp field in the oci_server structure and check in the PHP_RINIT_FUNCTION if a php_ini configurable connection_timeout (defaults to -1, or no timeout) has expired. In the affirmative, the expired server handle and all associated session handles are correcly closed. Since this happens at request init I am sure the check triggers for all PHP scripts, even though they don't access the database, as this helps to keep the number of connections down. On the other hand a heavily accessed server will never timeout persistent connections. My tests indicate that a 300s timeout is high enough to guarantee peak Oracle performance while being low enough to never create firewall problems. Especially when coupled with the solutions to bug #22674, the overhead induced by the up-front check is negligible. =20 As stated above, two new php_ini entries are proposed as follows: =20 [OCI8] ;if true, internally convert userid, password and dbname to uppercase ;oci8.credentials_toupper =3D false =20 ;inactivity timeout for persistent connections (seconds). -1 means no timeout. ;oci8.connection_timeout =3D -1 Hope this helps =20 Massimo Squillace ------_=_NextPart_002_01C2FD26.8196DFA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Messaggio
Hi, I had to split the = original=20 message in two e-mails because it was longer than 30000=20 bytes.
In this first message = you'll find=20 the commentary and the first attachment, the second message contains the = second=20 attachment.
 
Massimo
 
----------------------------------------------= -------------------------------------------------------------------------= -
 
Hi all, 
 
since posting bug #22674 resulted in no = feedback=20 to date and I believe OCI8 persistent session management should  = quickly be=20 fixed, I studied the sources and came up with a solution to that = particular bug=20 and more.
 
The solutions have been working for a week = now on two=20 PHP 4.2.2 and two PHP 4.3.1 servers, so this weekend I downloaded the = current=20 CVS snapshot and applied them there.
 
Here follows a description of the problems = and the=20 proposed patches:
 
1) [Solves bug #22674, part 1] The sequence=20 OCIPLOGON('user1', 'pwd1', 'db1') + OCILOGON('user2', 'pwd2', 'db1') = creates two=20 persistent session handles instead of one, because the OCILOGON session = wrongly=20 "inherits" the persistency attribute of the OCIPLOGON session; BOTH = sessions can be reused.  I fixed one assignment statement in=20 oci_do_connect.
 
2) [Solves bug #22674, part 2] The sequence = OCIPLOGON +=20 OCILOGON + OCINLOGON (same dbname for all, same userid=20 and password for the latter 2 calls) still creates two = persistent=20 session handles instead of one, but the session structure set up by = OCILOGON is=20 incorrectly freed when the module cleans up the OCINLOGON structures, so = that=20 while Oracle still sees the surplus session PHP cannot reuse it in=20 subsequent scripts. This leads to a session build-up with Oracle = eventually=20 giving up. The problem lies in the way hashed_details is built: it is = the same=20 for OCILOGON and OCINLOGON, so when zend_hash_del is called during = cleanup=20 it deletes BOTH structures. I re-defined the hashed_details for = OCINLOGON=20 using gettimeofday(), so each OCINLOGON structure is now unique and = different=20 from any OCILOGON structure.
 
These first two patches are in the attached = twobugs.txt=20 file; if they are accepted bug #22674 may be closed.
 
I also attach a fourpatches.txt file, which = contains=20 the above solutions and two more patches I'd like to submit to your = attention,=20 since I believe they could help make the module more=20 flexible:
 
3) More often than not Oracle installations = do NOT=20 provide for a user-defined "password verification function", so that = userid,=20 password and dbname are treated case-insensitively by the RDBMS, while = the OCI8=20 module generates hashed_details that are case-sensitive. If = the programmers=20 mix case during development this leads to an excessive number of = persistent=20 sessions to Oracle. I introduced a php_ini boolean variable = credentials_toupper=20 which, when true (defaults to false), triggers uppercase conversion of = userid,=20 password and dbname before their use in = oci_do_connect.
 
4) When the web servers are behind a firewall = in a DMZ,=20 the firewall truncates sessions when they reach a configurable but = unavoidable=20 inactivity timeout. This invalidates persistent sessions and in my = experience=20 (if the firewall doesn't specifically support SQL*NET) can't always be=20 circumvented by a decrease in the tcp_keepalive_time; also, I'd rather = leave=20 such parameters at their default and let the firewall do its work which = is=20 dictated by security concerns. Idle persistent sessions are useless by=20 themselves and should anyway be closed as soon as feasible to minimize = load on=20 the RDBMS. In past client-server (OS/2) applications I came up with a=20 thread-based solution which automatically closed the client's Oracle = connection=20 after a configurable inactivity timeout, but since I don't know = if this=20 should be done in the current PHP implementation I simply decided to add = a=20 timestamp field in the oci_server structure and check in the = PHP_RINIT_FUNCTION=20 if a php_ini configurable connection_timeout (defaults to -1, or no = timeout) has=20 expired. In the affirmative, the expired server handle and all = associated=20 session handles are correcly closed. Since this happens at request init = I am=20 sure the check triggers for all PHP scripts, even though they don't = access the=20 database, as this helps to keep the number of connections down. On the = other=20 hand a heavily accessed server will never timeout persistent = connections. My=20 tests indicate that a 300s timeout is high enough to guarantee peak = Oracle=20 performance while being low enough to never create firewall problems. = Especially=20 when coupled with the solutions to bug #22674, the overhead induced by = the=20 up-front check is negligible.
 
As stated above, two new php_ini entries are = proposed=20 as follows:
 
[OCI8]
;if true, internally convert userid, password = and=20 dbname to uppercase
;oci8.credentials_toupper =3D = false
 
;inactivity timeout for persistent = connections=20 (seconds). -1 means no timeout.
;oci8.connection_timeout =3D = -1
Hope this helps
 
Massimo = Squillace
=00 ------_=_NextPart_002_01C2FD26.8196DFA1-- ------_=_NextPart_001_01C2FD26.8196DFA1 Content-Type: text/plain; name="twobugs.txt" Content-Transfer-Encoding: base64 Content-Description: twobugs.txt Content-Disposition: attachment; filename="twobugs.txt" PyB0d29idWdzLnBhdGNoCkluZGV4OiBvY2k4LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG9z aXRvcnkvcGhwNC9leHQvb2NpOC9vY2k4LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjA1CmRp ZmYgLXUgLXIxLjIwNSBvY2k4LmMKLS0tIG9jaTguYwkxOCBNYXIgMjAwMyAxMjowNjowMCAtMDAw MAkxLjIwNQorKysgb2NpOC5jCTYgQXByIDIwMDMgMTY6NTI6MTMgLTAwMDAKQEAgLTIxNTMsMzAg KzIxNTMsMzIgQEAKIAlvY2lfc2Vzc2lvbiAqc2Vzc2lvbiA9IDAsICpwc2Vzc2lvbiA9IDA7CiAJ T0NJU3ZjQ3R4ICpzdmNocCA9IDA7CiAJY2hhciAqaGFzaGVkX2RldGFpbHM7CisJc3RydWN0IHRp bWV2YWwgdHY7CisJaW50IHNlYywgdXNlYzsKICNpZmRlZiBIQVZFX09DSTkKIAl1YjIgY2hhcnNl dGlkOwogI2VuZGlmCiAJVFNSTUxTX0ZFVENIKCk7CiAKLQkvKiAKKwkvKgogCSAgIGNoZWNrIGlm IHdlIGFscmVhZHkgaGF2ZSB0aGlzIHVzZXIgYXV0aGVudGljYXRlZAogCi0JICAgd2Ugd2lsbCBy ZXVzZSBhdXRoZW50aWNhdGVkIHVzZXJzIHdpdGhpbiBhIHJlcXVlc3Qgbm8gbWF0dGVyIGlmIHRo ZSB1c2VyIHJlcXVlc3RlZCBhIHBlcnNpc3RlbnQgCisJICAgd2Ugd2lsbCByZXVzZSBhdXRoZW50 aWNhdGVkIHVzZXJzIHdpdGhpbiBhIHJlcXVlc3Qgbm8gbWF0dGVyIGlmIHRoZSB1c2VyIHJlcXVl c3RlZCBhIHBlcnNpc3RlbnQKIAkgICBjb25uZWN0aW9ucyBvciBub3QhCi0JICAgCi0JICAgYnV0 IG9ubHkgYXMgcGVzaXN0ZW50IHJlcXVlc3RlZCBjb25uZWN0aW9ucyB3aWxsIGJlIGtlcHQgYmV0 d2VlbiByZXF1ZXN0cyEKLQkqLwogCi0JaGFzaGVkX2RldGFpbHMgPSAoY2hhciAqKSBtYWxsb2Mo c3RybGVuKFNBRkVfU1RSSU5HKHVzZXJuYW1lKSkrCi0JCQkJCQkJCQkgc3RybGVuKFNBRkVfU1RS SU5HKHBhc3N3b3JkKSkrCi0JCQkJCQkJCQkgc3RybGVuKFNBRkVfU1RSSU5HKHNlcnZlci0+ZGJu YW1lKSkrMSk7Ci0JCi0Jc3ByaW50ZihoYXNoZWRfZGV0YWlscywiJXMlcyVzIiwKLQkJCVNBRkVf U1RSSU5HKHVzZXJuYW1lKSwKLQkJCVNBRkVfU1RSSU5HKHBhc3N3b3JkKSwKLQkJCVNBRkVfU1RS SU5HKHNlcnZlci0+ZGJuYW1lKSk7CisJICAgYnV0IG9ubHkgYXMgcGVyc2lzdGVudCByZXF1ZXN0 ZWQgY29ubmVjdGlvbnMgd2lsbCBiZSBrZXB0IGJldHdlZW4gcmVxdWVzdHMhCisJKi8KIAogCWlm ICghIGV4Y2x1c2l2ZSkgeworCQloYXNoZWRfZGV0YWlscyA9IChjaGFyICopIG1hbGxvYyhzdHJs ZW4oU0FGRV9TVFJJTkcodXNlcm5hbWUpKSsKKwkJCQkJCQkJCQkgc3RybGVuKFNBRkVfU1RSSU5H KHBhc3N3b3JkKSkrCisJCQkJCQkJCQkJIHN0cmxlbihTQUZFX1NUUklORyhzZXJ2ZXItPmRibmFt ZSkpKzEpOworCisJCXNwcmludGYoaGFzaGVkX2RldGFpbHMsIiVzJXMlcyIsCisJCQkJU0FGRV9T VFJJTkcodXNlcm5hbWUpLAorCQkJCVNBRkVfU1RSSU5HKHBhc3N3b3JkKSwKKwkJCQlTQUZFX1NU UklORyhzZXJ2ZXItPmRibmFtZSkpOworCiAJCXplbmRfaGFzaF9maW5kKE9DSSh1c2VyKSwgaGFz aGVkX2RldGFpbHMsIHN0cmxlbihoYXNoZWRfZGV0YWlscykrMSwgKHZvaWQgKiopICZzZXNzaW9u KTsKIAogCQlpZiAoc2Vzc2lvbikgewpAQCAtMjE5MSw2ICsyMTkzLDE0IEBACiAJCQkJLyogYnJl YWt0aHJ1IHRvIG9wZW4gKi8KIAkJCX0KIAkJfQorCX0gZWxzZSB7CisJCWdldHRpbWVvZmRheSgo c3RydWN0IHRpbWV2YWwgKikgJnR2LCAoc3RydWN0IHRpbWV6b25lICopIE5VTEwpOworCQlzZWMg PSAoaW50KSB0di50dl9zZWM7CisJCXVzZWMgPSAoaW50KSAodHYudHZfdXNlYyAlIDEwMDAwMDAp OworCQkvKiBUaGUgbWF4IHZhbHVlIHVzZWMgY2FuIGhhdmUgaXMgMHhGNDIzRiwgc28gd2UgdXNl IG9ubHkgZml2ZSBoZXgKKwkJICAgZGlnaXRzIGZvciB1c2VjIGFuZCBlaWd0aCBoZXggZGlnaXRz IGZvciBzZWMuICovCisJCWhhc2hlZF9kZXRhaWxzID0gKGNoYXIgKikgbWFsbG9jKDgrNSsxKTsg LyogYWx3YXlzIGVub3VnaCAqLworCQlzcHJpbnRmKGhhc2hlZF9kZXRhaWxzLCAiJTA4eCUwNXgi LCB0di50dl9zZWMsIHR2LnR2X3VzZWMpOwogCX0KIAogCXNlc3Npb24gPSBjYWxsb2MoMSxzaXpl b2Yob2NpX3Nlc3Npb24pKTsKQEAgLTIyMTcsMTYgKzIyMjcsMTYgQEAKIAkJQ0FMTF9PQ0lfUkVU VVJOKGNoYXJzZXRpZCwgT0NJTmxzQ2hhclNldE5hbWVUb0lkKAogCQkJCQkJCU9DSShwRW52KSwK IAkJCQkJCQljaGFyc2V0KSk7Ci0JCQorCiAJCXNlc3Npb24tPmNoYXJzZXRJZCA9IGNoYXJzZXRp ZDsKIAkJb2NpX2RlYnVnKCJvY2lfZG9fY29ubmVjdDogdXNpbmcgY2hhcnNldCBpZD0lZCIsY2hh cnNldGlkKTsKIAl9Ci0JCisKIAkvKiBjcmVhdGUgYW4gZW52aXJvbm1lbnQgdXNpbmcgdGhlIGNo YXJhY3RlciBzZXQgaWQsIE9yYWNsZSA5aSsgT05MWSAqLwogCUNBTExfT0NJKE9DSUVudk5sc0Ny ZWF0ZSgKIAkJCQkmc2Vzc2lvbi0+cEVudiwKLQkJCQlPQ0lfREVGQVVMVCwgCi0JCQkJMCwgCisJ CQkJT0NJX0RFRkFVTFQsCisJCQkJMCwKIAkJCQlOVUxMLAogCQkJCU5VTEwsCiAJCQkJTlVMTCwK QEAgLTIyNDUsMTIgKzIyNTUsMTIgQEAKIAogCS8qIGFsbG9jYXRlIHRlbXBvcmFyeSBTZXJ2aWNl IENvbnRleHQgKi8KIAlDQUxMX09DSV9SRVRVUk4oT0NJKGVycm9yKSwgT0NJSGFuZGxlQWxsb2Mo Ci0JCQkJc2Vzc2lvbi0+cEVudiwgCi0JCQkJKGR2b2lkICoqKSZzdmNocCwgCi0JCQkJT0NJX0hU WVBFX1NWQ0NUWCwgCi0JCQkJMCwgCisJCQkJc2Vzc2lvbi0+cEVudiwKKwkJCQkoZHZvaWQgKiop JnN2Y2hwLAorCQkJCU9DSV9IVFlQRV9TVkNDVFgsCisJCQkJMCwKIAkJCQlOVUxMKSk7Ci0JCisK IAlpZiAoT0NJKGVycm9yKSAhPSBPQ0lfU1VDQ0VTUykgewogCQlvY2lfZXJyb3IoT0NJKHBFcnJv ciksICJfb2NpX29wZW5fc2Vzc2lvbjogT0NJSGFuZGxlQWxsb2MgT0NJX0hUWVBFX1NWQ0NUWCIs IE9DSShlcnJvcikpOwogCQlnb3RvIENMRUFOVVA7CkBAIC0yMjU4LDEwICsyMjY4LDEwIEBACiAK IAkvKiBhbGxvY2F0ZSBwcml2YXRlIHNlc3Npb24taGFuZGxlICovCiAJQ0FMTF9PQ0lfUkVUVVJO KE9DSShlcnJvciksIE9DSUhhbmRsZUFsbG9jKAotCQkJCXNlc3Npb24tPnBFbnYsIAotCQkJCShk dm9pZCAqKikmc2Vzc2lvbi0+cFNlc3Npb24sIAotCQkJCU9DSV9IVFlQRV9TRVNTSU9OLCAKLQkJ CQkwLCAKKwkJCQlzZXNzaW9uLT5wRW52LAorCQkJCShkdm9pZCAqKikmc2Vzc2lvbi0+cFNlc3Np b24sCisJCQkJT0NJX0hUWVBFX1NFU1NJT04sCisJCQkJMCwKIAkJCQlOVUxMKSk7CiAKIAlpZiAo T0NJKGVycm9yKSAhPSBPQ0lfU1VDQ0VTUykgewpAQCAtMjI2OSwxMSArMjI3OSwxMSBAQAogCQln b3RvIENMRUFOVVA7CiAJfQogCi0JLyogU2V0IHRoZSBzZXJ2ZXIgaGFuZGxlIGluIHNlcnZpY2Ug aGFuZGxlICovIAorCS8qIFNldCB0aGUgc2VydmVyIGhhbmRsZSBpbiBzZXJ2aWNlIGhhbmRsZSAq LwogCUNBTExfT0NJX1JFVFVSTihPQ0koZXJyb3IpLCBPQ0lBdHRyU2V0KAotCQkJCXN2Y2hwLCAK LQkJCQlPQ0lfSFRZUEVfU1ZDQ1RYLCAKLQkJCQlzZXJ2ZXItPnBTZXJ2ZXIsIAorCQkJCXN2Y2hw LAorCQkJCU9DSV9IVFlQRV9TVkNDVFgsCisJCQkJc2VydmVyLT5wU2VydmVyLAogCQkJCTAsCiAJ CQkJT0NJX0FUVFJfU0VSVkVSLAogCQkJCU9DSShwRXJyb3IpKSk7CkBAIC0yMjg1LDExICsyMjk1 LDExIEBACiAKIAkvKiBzZXQgdGhlIHVzZXJuYW1lIGluIHVzZXIgaGFuZGxlICovCiAJQ0FMTF9P Q0lfUkVUVVJOKE9DSShlcnJvciksIE9DSUF0dHJTZXQoCi0JCQkJKGR2b2lkICopIHNlc3Npb24t PnBTZXNzaW9uLCAKLQkJCQkodWI0KSBPQ0lfSFRZUEVfU0VTU0lPTiwgCi0JCQkJKGR2b2lkICop IHVzZXJuYW1lLCAKLQkJCQkodWI0KSBzdHJsZW4odXNlcm5hbWUpLCAKLQkJCQkodWI0KSBPQ0lf QVRUUl9VU0VSTkFNRSwgCisJCQkJKGR2b2lkICopIHNlc3Npb24tPnBTZXNzaW9uLAorCQkJCSh1 YjQpIE9DSV9IVFlQRV9TRVNTSU9OLAorCQkJCShkdm9pZCAqKSB1c2VybmFtZSwKKwkJCQkodWI0 KSBzdHJsZW4odXNlcm5hbWUpLAorCQkJCSh1YjQpIE9DSV9BVFRSX1VTRVJOQU1FLAogCQkJCU9D SShwRXJyb3IpKSk7CiAKIAlpZiAoT0NJKGVycm9yKSAhPSBPQ0lfU1VDQ0VTUykgewpAQCAtMjI5 OSwxMSArMjMwOSwxMSBAQAogCiAJLyogc2V0IHRoZSBwYXNzd29yZCBpbiB1c2VyIGhhbmRsZSAq LwogCUNBTExfT0NJX1JFVFVSTihPQ0koZXJyb3IpLCBPQ0lBdHRyU2V0KAotCQkJCShkdm9pZCAq KSBzZXNzaW9uLT5wU2Vzc2lvbiwgCi0JCQkJKHViNCkgT0NJX0hUWVBFX1NFU1NJT04sIAotCQkJ CShkdm9pZCAqKSBwYXNzd29yZCwgCi0JCQkJKHViNCkgc3RybGVuKHBhc3N3b3JkKSwgCi0JCQkJ KHViNCkgT0NJX0FUVFJfUEFTU1dPUkQsIAorCQkJCShkdm9pZCAqKSBzZXNzaW9uLT5wU2Vzc2lv biwKKwkJCQkodWI0KSBPQ0lfSFRZUEVfU0VTU0lPTiwKKwkJCQkoZHZvaWQgKikgcGFzc3dvcmQs CisJCQkJKHViNCkgc3RybGVuKHBhc3N3b3JkKSwKKwkJCQkodWI0KSBPQ0lfQVRUUl9QQVNTV09S RCwKIAkJCQlPQ0kocEVycm9yKSkpOwogCiAJaWYgKE9DSShlcnJvcikgIT0gT0NJX1NVQ0NFU1Mp IHsKQEAgLTIzMTIsMTAgKzIzMjIsMTAgQEAKIAl9CiAKIAlDQUxMX09DSV9SRVRVUk4oT0NJKGVy cm9yKSwgT0NJU2Vzc2lvbkJlZ2luKAotCQkJCXN2Y2hwLCAKLQkJCQlPQ0kocEVycm9yKSwgCi0J CQkJc2Vzc2lvbi0+cFNlc3Npb24sIAotCQkJCSh1YjQpIE9DSV9DUkVEX1JEQk1TLCAKKwkJCQlz dmNocCwKKwkJCQlPQ0kocEVycm9yKSwKKwkJCQlzZXNzaW9uLT5wU2Vzc2lvbiwKKwkJCQkodWI0 KSBPQ0lfQ1JFRF9SREJNUywKIAkJCQkodWI0KSBPQ0lfREVGQVVMVCkpOwogCiAJaWYgKE9DSShl cnJvcikgIT0gT0NJX1NVQ0NFU1MpIHsKQEAgLTIzMjUsNyArMjMzNSw3IEBACiAKIAkvKiBGcmVl IFRlbXBvcmFyeSBTZXJ2aWNlIENvbnRleHQgKi8KIAlDQUxMX09DSShPQ0lIYW5kbGVGcmVlKAot CQkJCShkdm9pZCAqKSBzdmNocCwgCisJCQkJKGR2b2lkICopIHN2Y2hwLAogCQkJCSh1YjQpIE9D SV9IVFlQRV9TVkNDVFgpKTsKIAogCWlmIChleGNsdXNpdmUpIHsKQEAgLTIzMzMsNyArMjM0Myw3 IEBACiAJfSBlbHNlIHsKIAkJemVuZF9oYXNoX3VwZGF0ZShPQ0kodXNlciksCiAJCQkJCQkgc2Vz c2lvbi0+aGFzaGVkX2RldGFpbHMsCi0JCQkJCQkgc3RybGVuKHNlc3Npb24tPmhhc2hlZF9kZXRh aWxzKSsxLCAKKwkJCQkJCSBzdHJsZW4oc2Vzc2lvbi0+aGFzaGVkX2RldGFpbHMpKzEsCiAJCQkJ CQkgKHZvaWQgKilzZXNzaW9uLAogCQkJCQkJIHNpemVvZihvY2lfc2Vzc2lvbiksCiAJCQkJCQkg KHZvaWQqKikmcHNlc3Npb24pOwpAQCAtMjY3Niw3ICsyNjg2LDcgQEAKIAkJcGVyc2lzdGVudCA9 IDA7CiAJfSBlbHNlIHsKIAkJLyogaWYgb3VyIHNlcnZlci1jb250ZXh0IGlzIG5vdCBwZXJzaXN0 ZW50IHdlIGNhbid0ICovCi0JCXBlcnNpc3RlbnQgPSBzZXJ2ZXItPnBlcnNpc3RlbnQ7IAorCQlw ZXJzaXN0ZW50ID0gKHNlcnZlci0+cGVyc2lzdGVudCkgPyBwZXJzaXN0ZW50IDogMDsKIAl9CiAK IAlzZXNzaW9uID0gX29jaV9vcGVuX3Nlc3Npb24oc2VydmVyLHVzZXJuYW1lLHBhc3N3b3JkLHBl cnNpc3RlbnQsZXhjbHVzaXZlLGNoYXJzZXQpOwpAQCAtMjY5Myw3ICsyNzAzLDcgQEAKIAkJCQlj b25uZWN0aW9uLT5zZXNzaW9uLT5wRW52LCAKIAkJCQkoZHZvaWQgKiopJmNvbm5lY3Rpb24tPnBF cnJvciwgCiAJCQkJT0NJX0hUWVBFX0VSUk9SLCAKLQkJCQkwLCAKKwkJCQkwLAogCQkJCU5VTEwp KTsKIAogCWlmIChPQ0koZXJyb3IpICE9IE9DSV9TVUNDRVNTKSB7Cg== ------_=_NextPart_001_01C2FD26.8196DFA1--