MIME-Version: 1.0
References: 
 <CAMrLSE4JrhPB2XYMOMzbPSsgE+6kmDaKHKiF34NWdnbQts=Cpw@mail.gmail.com>
 <adk8Z0HGDaXSRIgF@nathan> <adk9IiZYGam6OltO@nathan>
In-Reply-To: <adk9IiZYGam6OltO@nathan>
From: CharSyam <charsyam@gmail.com>
Date: Sat, 11 Apr 2026 10:17:07 +0900
Message-ID: 
 <CAMrLSE5DHxxBxhSMCnimZoMdsUjKagDF4PzgMoFMsZcp_=24cg@mail.gmail.com>
Subject: Re: [PATCH] Use cached hash to skip unnecessary key comparisons in
 dshash
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="000000000000c98b92064f250244"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMrLSE5DHxxBxhSMCnimZoMdsUjKagDF4PzgMoFMsZcp_%3D24cg%40mail.gmail.com>
Precedence: bulk

--000000000000c98b92064f250244
Content-Type: multipart/alternative; boundary="000000000000c98b91064f250242"

--000000000000c98b91064f250242
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for the thoughtful review. I've attached an updated patch (v2)
  addressing your feedback.

  1. Comment added

  I've added a comment in find_in_bucket() explaining the hash pre-check
  assumption:

    /*
     * If the hash values don't match, the keys certainly don't match
     * either, so we can skip the expensive key comparison.  Matching
     * hashes don't guarantee matching keys, so equal_keys() is still
     * needed for confirmation.
     */

  A short "See comment in find_in_bucket()" reference is also added in
  delete_key_from_bucket().

  2. No regressions with short keys / cheap comparisons

  I ran an additional benchmark with short keys ("1" ~ "10000", 1-5 chars)
  where strcmp cost is minimal:

    Test                     | Before    | After     | Change
    -------------------------+-----------+-----------+------------
    INSERT 10000 entries     | 13.26 ms  |  6.44 ms  | ~51% faster
    LOOKUP 10000 hits        |  7.94 ms  |  5.03 ms  | ~37% faster
    LOOKUP 10000 misses      |  8.08 ms  |  4.80 ms  | ~41% faster
    LOOKUP 50000 hits (x5)   | 33.05 ms  | 24.06 ms  | ~27% faster

  For reference, here are the original string key results ("key_1" ~
  "key_10000"):

    Test                     | Before    | After     | Change
    -------------------------+-----------+-----------+------------
    INSERT 10000 entries     | 14.99 ms  |  9.46 ms  | ~37% faster
    LOOKUP 10000 hits        | 10.40 ms  |  5.52 ms  | ~47% faster
    LOOKUP 10000 misses      |  8.41 ms  |  4.95 ms  | ~41% faster
    LOOKUP 50000 hits (x5)   | 33.48 ms  | 26.44 ms  | ~21% faster

  No regressions in either scenario.  Even with short keys, the integer
  hash pre-check is always cheaper than the DSM address translation plus
  compare function call it avoids.

  Both tests ran on macOS (arm64) using the test_dsm_registry extension
  with 10,000 entries.

  3. Keeping the pre-check outside equal_keys()

  I considered moving the hash comparison into equal_keys(), but I think
  keeping it at the call site is a better fit for the following reasons:

    - equal_keys() is a pure key comparison function.  Mixing in hash
      comparison would change its semantics and make the name misleading.

    - To pass hashes into equal_keys(), we would need to add two hash
      parameters (one for the search key, one for the item).  The caller
      still needs to extract item->hash before the call, so the call site
      doesn't actually get simpler.

    - There are only two call sites, both already modified in this patch,
      so there is no real maintenance burden from having the check at each
      call site.

    - This pattern is consistent with other hash table implementations in
      PostgreSQL (e.g., dynahash.c), which also compare hashes outside
      the key equality function.

  I'm happy to reconsider if you feel differently.

  Regards,
  charsyam

2026=EB=85=84 4=EC=9B=94 11=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 3:10, N=
athan Bossart <nathandbossart@gmail.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=
=B1:

> On Sat, Apr 11, 2026 at 01:09:33AM +0900, CharSyam wrote:
> > I believe this patch is ready for review.  I look forward to any feedba=
ck
> > and am happy to make revisions.
>
> Sorry, I forgot to ask whether we could move the "pre-check" to within th=
e
> equal_keys() function so that it needn't be added to every one of its
> callers.
>
> --
> nathan
>

--000000000000c98b91064f250242
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for the thoughtful review. I&#39;ve attached an =
updated patch (v2)<br>=C2=A0 addressing your feedback.<br><br>=C2=A0 1. Com=
ment added<br><br>=C2=A0 I&#39;ve added a comment in find_in_bucket() expla=
ining the hash pre-check<br>=C2=A0 assumption:<br><br>=C2=A0 =C2=A0 /*<br>=
=C2=A0 =C2=A0 =C2=A0* If the hash values don&#39;t match, the keys certainl=
y don&#39;t match<br>=C2=A0 =C2=A0 =C2=A0* either, so we can skip the expen=
sive key comparison.=C2=A0 Matching<br>=C2=A0 =C2=A0 =C2=A0* hashes don&#39=
;t guarantee matching keys, so equal_keys() is still<br>=C2=A0 =C2=A0 =C2=
=A0* needed for confirmation.<br>=C2=A0 =C2=A0 =C2=A0*/<br><br>=C2=A0 A sho=
rt &quot;See comment in find_in_bucket()&quot; reference is also added in<b=
r>=C2=A0 delete_key_from_bucket().<br><br>=C2=A0 2. No regressions with sho=
rt keys / cheap comparisons<br><br>=C2=A0 I ran an additional benchmark wit=
h short keys (&quot;1&quot; ~ &quot;10000&quot;, 1-5 chars)<br>=C2=A0 where=
 strcmp cost is minimal:<br><br>=C2=A0 =C2=A0 Test =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Before =C2=A0 =C2=A0| After=
 =C2=A0 =C2=A0 | Change<br>=C2=A0 =C2=A0 -------------------------+--------=
---+-----------+------------<br>=C2=A0 =C2=A0 INSERT 10000 entries =C2=A0 =
=C2=A0 | 13.26 ms =C2=A0| =C2=A06.44 ms =C2=A0| ~51% faster<br>=C2=A0 =C2=
=A0 LOOKUP 10000 hits =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A07.94 ms =C2=A0| =
=C2=A05.03 ms =C2=A0| ~37% faster<br>=C2=A0 =C2=A0 LOOKUP 10000 misses =C2=
=A0 =C2=A0 =C2=A0| =C2=A08.08 ms =C2=A0| =C2=A04.80 ms =C2=A0| ~41% faster<=
br>=C2=A0 =C2=A0 LOOKUP 50000 hits (x5) =C2=A0 | 33.05 ms =C2=A0| 24.06 ms =
=C2=A0| ~27% faster<br><br>=C2=A0 For reference, here are the original stri=
ng key results (&quot;key_1&quot; ~<br>=C2=A0 &quot;key_10000&quot;):<br><b=
r>=C2=A0 =C2=A0 Test =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 | Before =C2=A0 =C2=A0| After =C2=A0 =C2=A0 | Change<br>=
=C2=A0 =C2=A0 -------------------------+-----------+-----------+-----------=
-<br>=C2=A0 =C2=A0 INSERT 10000 entries =C2=A0 =C2=A0 | 14.99 ms =C2=A0| =
=C2=A09.46 ms =C2=A0| ~37% faster<br>=C2=A0 =C2=A0 LOOKUP 10000 hits =C2=A0=
 =C2=A0 =C2=A0 =C2=A0| 10.40 ms =C2=A0| =C2=A05.52 ms =C2=A0| ~47% faster<b=
r>=C2=A0 =C2=A0 LOOKUP 10000 misses =C2=A0 =C2=A0 =C2=A0| =C2=A08.41 ms =C2=
=A0| =C2=A04.95 ms =C2=A0| ~41% faster<br>=C2=A0 =C2=A0 LOOKUP 50000 hits (=
x5) =C2=A0 | 33.48 ms =C2=A0| 26.44 ms =C2=A0| ~21% faster<br><br>=C2=A0 No=
 regressions in either scenario.=C2=A0 Even with short keys, the integer<br=
>=C2=A0 hash pre-check is always cheaper than the DSM address translation p=
lus<br>=C2=A0 compare function call it avoids.<br><br>=C2=A0 Both tests ran=
 on macOS (arm64) using the test_dsm_registry extension<br>=C2=A0 with 10,0=
00 entries.<br><br>=C2=A0 3. Keeping the pre-check outside equal_keys()<br>=
<br>=C2=A0 I considered moving the hash comparison into equal_keys(), but I=
 think<br>=C2=A0 keeping it at the call site is a better fit for the follow=
ing reasons:<br><br>=C2=A0 =C2=A0 - equal_keys() is a pure key comparison f=
unction.=C2=A0 Mixing in hash<br>=C2=A0 =C2=A0 =C2=A0 comparison would chan=
ge its semantics and make the name misleading.<br><br>=C2=A0 =C2=A0 - To pa=
ss hashes into equal_keys(), we would need to add two hash<br>=C2=A0 =C2=A0=
 =C2=A0 parameters (one for the search key, one for the item).=C2=A0 The ca=
ller<br>=C2=A0 =C2=A0 =C2=A0 still needs to extract item-&gt;hash before th=
e call, so the call site<br>=C2=A0 =C2=A0 =C2=A0 doesn&#39;t actually get s=
impler.<br><br>=C2=A0 =C2=A0 - There are only two call sites, both already =
modified in this patch,<br>=C2=A0 =C2=A0 =C2=A0 so there is no real mainten=
ance burden from having the check at each<br>=C2=A0 =C2=A0 =C2=A0 call site=
.<br><br>=C2=A0 =C2=A0 - This pattern is consistent with other hash table i=
mplementations in<br>=C2=A0 =C2=A0 =C2=A0 PostgreSQL (e.g., dynahash.c), wh=
ich also compare hashes outside<br>=C2=A0 =C2=A0 =C2=A0 the key equality fu=
nction.<br><br>=C2=A0 I&#39;m happy to reconsider if you feel differently.<=
br><br>=C2=A0 Regards,<br>=C2=A0 charsyam</div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">2026=EB=85=
=84 4=EC=9B=94 11=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 3:10, Nathan Boss=
art &lt;<a href=3D"mailto:nathandbossart@gmail.com">nathandbossart@gmail.co=
m</a>&gt;=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Sat, Apr 11, 2026 at 01:09:33AM +0900, =
CharSyam wrote:<br>
&gt; I believe this patch is ready for review.=C2=A0 I look forward to any =
feedback<br>
&gt; and am happy to make revisions.<br>
<br>
Sorry, I forgot to ask whether we could move the &quot;pre-check&quot; to w=
ithin the<br>
equal_keys() function so that it needn&#39;t be added to every one of its<b=
r>
callers.<br>
<br>
-- <br>
nathan<br>
</blockquote></div>

--000000000000c98b91064f250242--

--000000000000c98b92064f250244
Content-Type: application/octet-stream;
	name="0001-Use-cached-hash-to-skip-unnecessary-key-comparisons-v2.patch"
Content-Disposition: attachment;
	filename="0001-Use-cached-hash-to-skip-unnecessary-key-comparisons-v2.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mntn96zv0>
X-Attachment-Id: f_mntn96zv0

RnJvbSAwZDhmMGY0NGEwZTlhYThiNmE5NTdlYWQ5ODAxODViZmFkMjIzNzA2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBEYWVNeXVuZyBLYW5nIDxjaGFyc3lhbUBuYXZlci5jb20+CkRh
dGU6IFNhdCwgMTEgQXByIDIwMjYgMDA6NTI6NTYgKzA5MDAKU3ViamVjdDogW1BBVENIIHYyXSBV
c2UgY2FjaGVkIGhhc2ggdG8gc2tpcCB1bm5lY2Vzc2FyeSBrZXkgY29tcGFyaXNvbnMgaW4KIGRz
aGFzaAoKRWFjaCBkc2hhc2hfdGFibGVfaXRlbSBhbHJlYWR5IHN0b3JlcyB0aGUgaGFzaCB2YWx1
ZSwgYnV0CmZpbmRfaW5fYnVja2V0KCkgYW5kIGRlbGV0ZV9rZXlfZnJvbV9idWNrZXQoKSB3ZXJl
IG5vdCB1c2luZyBpdCwKYWx3YXlzIGNhbGxpbmcgdGhlIGV4cGVuc2l2ZSBjb21wYXJlIGZ1bmN0
aW9uIGZvciBldmVyeSBpdGVtIGluIHRoZQpidWNrZXQgY2hhaW4uCgpBZGQgYSBoYXNoIHByZS1j
aGVjayBiZWZvcmUgY2FsbGluZyBlcXVhbF9rZXlzKCkgc28gdGhhdCBpdGVtcyB3aXRoCm5vbi1t
YXRjaGluZyBoYXNoIHZhbHVlcyBhcmUgc2tpcHBlZCB3aXRoIGEgc2ltcGxlIGludGVnZXIgY29t
cGFyaXNvbiwKYXZvaWRpbmcgdGhlIG92ZXJoZWFkIG9mIERTTSBhZGRyZXNzIHRyYW5zbGF0aW9u
IGFuZCBrZXkgY29tcGFyaXNvbi4KCkJlbmNobWFyayB3aXRoIDEwMDAwIHN0cmluZy1rZXllZCBl
bnRyaWVzIHVzaW5nIHRlc3RfZHNtX3JlZ2lzdHJ5CnNob3dzIDIxLTQ3JSBpbXByb3ZlbWVudCBh
Y3Jvc3MgaW5zZXJ0LCBsb29rdXAtaGl0LCBhbmQgbG9va3VwLW1pc3MKb3BlcmF0aW9ucy4KClNp
Z25lZC1vZmYtYnk6IERhZU15dW5nIEthbmcgPGNoYXJzeWFtQG5hdmVyLmNvbT4KLS0tCiBzcmMv
YmFja2VuZC9saWIvZHNoYXNoLmMgfCAyOSArKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLQog
MSBmaWxlIGNoYW5nZWQsIDIzIGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25zKC0pCgpkaWZmIC0t
Z2l0IGEvc3JjL2JhY2tlbmQvbGliL2RzaGFzaC5jIGIvc3JjL2JhY2tlbmQvbGliL2RzaGFzaC5j
CmluZGV4IDE5OTk5ODljMTRmLi45MWJiYjhlOWI2ZSAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQv
bGliL2RzaGFzaC5jCisrKyBiL3NyYy9iYWNrZW5kL2xpYi9kc2hhc2guYwpAQCAtMTcyLDYgKzE3
Miw3IEBAIHN0YXRpYyBib29sIHJlc2l6ZShkc2hhc2hfdGFibGUgKmhhc2hfdGFibGUsIHNpemVf
dCBuZXdfc2l6ZV9sb2cyLAogc3RhdGljIGlubGluZSB2b2lkIGVuc3VyZV92YWxpZF9idWNrZXRf
cG9pbnRlcnMoZHNoYXNoX3RhYmxlICpoYXNoX3RhYmxlKTsKIHN0YXRpYyBpbmxpbmUgZHNoYXNo
X3RhYmxlX2l0ZW0gKmZpbmRfaW5fYnVja2V0KGRzaGFzaF90YWJsZSAqaGFzaF90YWJsZSwKIAkJ
CQkJCQkJCQkJCWNvbnN0IHZvaWQgKmtleSwKKwkJCQkJCQkJCQkJCWRzaGFzaF9oYXNoIGhhc2gs
CiAJCQkJCQkJCQkJCQlkc2FfcG9pbnRlciBpdGVtX3BvaW50ZXIpOwogc3RhdGljIHZvaWQgaW5z
ZXJ0X2l0ZW1faW50b19idWNrZXQoZHNoYXNoX3RhYmxlICpoYXNoX3RhYmxlLAogCQkJCQkJCQkJ
ZHNhX3BvaW50ZXIgaXRlbV9wb2ludGVyLApAQCAtMTgzLDYgKzE4NCw3IEBAIHN0YXRpYyBkc2hh
c2hfdGFibGVfaXRlbSAqaW5zZXJ0X2ludG9fYnVja2V0KGRzaGFzaF90YWJsZSAqaGFzaF90YWJs
ZSwKIAkJCQkJCQkJCQkJIGludCBmbGFncyk7CiBzdGF0aWMgYm9vbCBkZWxldGVfa2V5X2Zyb21f
YnVja2V0KGRzaGFzaF90YWJsZSAqaGFzaF90YWJsZSwKIAkJCQkJCQkJICAgY29uc3Qgdm9pZCAq
a2V5LAorCQkJCQkJCQkgICBkc2hhc2hfaGFzaCBoYXNoLAogCQkJCQkJCQkgICBkc2FfcG9pbnRl
ciAqYnVja2V0X2hlYWQpOwogc3RhdGljIGJvb2wgZGVsZXRlX2l0ZW1fZnJvbV9idWNrZXQoZHNo
YXNoX3RhYmxlICpoYXNoX3RhYmxlLAogCQkJCQkJCQkJZHNoYXNoX3RhYmxlX2l0ZW0gKml0ZW0s
CkBAIC00MDgsNyArNDEwLDcgQEAgZHNoYXNoX2ZpbmQoZHNoYXNoX3RhYmxlICpoYXNoX3RhYmxl
LCBjb25zdCB2b2lkICprZXksIGJvb2wgZXhjbHVzaXZlKQogCWVuc3VyZV92YWxpZF9idWNrZXRf
cG9pbnRlcnMoaGFzaF90YWJsZSk7CiAKIAkvKiBTZWFyY2ggdGhlIGFjdGl2ZSBidWNrZXQuICov
Ci0JaXRlbSA9IGZpbmRfaW5fYnVja2V0KGhhc2hfdGFibGUsIGtleSwgQlVDS0VUX0ZPUl9IQVNI
KGhhc2hfdGFibGUsIGhhc2gpKTsKKwlpdGVtID0gZmluZF9pbl9idWNrZXQoaGFzaF90YWJsZSwg
a2V5LCBoYXNoLCBCVUNLRVRfRk9SX0hBU0goaGFzaF90YWJsZSwgaGFzaCkpOwogCiAJaWYgKCFp
dGVtKQogCXsKQEAgLTQ2Miw3ICs0NjQsNyBAQCByZXN0YXJ0OgogCWVuc3VyZV92YWxpZF9idWNr
ZXRfcG9pbnRlcnMoaGFzaF90YWJsZSk7CiAKIAkvKiBTZWFyY2ggdGhlIGFjdGl2ZSBidWNrZXQu
ICovCi0JaXRlbSA9IGZpbmRfaW5fYnVja2V0KGhhc2hfdGFibGUsIGtleSwgQlVDS0VUX0ZPUl9I
QVNIKGhhc2hfdGFibGUsIGhhc2gpKTsKKwlpdGVtID0gZmluZF9pbl9idWNrZXQoaGFzaF90YWJs
ZSwga2V5LCBoYXNoLCBCVUNLRVRfRk9SX0hBU0goaGFzaF90YWJsZSwgaGFzaCkpOwogCiAJaWYg
KGl0ZW0pCiAJCSpmb3VuZCA9IHRydWU7CkBAIC01MzYsNyArNTM4LDcgQEAgZHNoYXNoX2RlbGV0
ZV9rZXkoZHNoYXNoX3RhYmxlICpoYXNoX3RhYmxlLCBjb25zdCB2b2lkICprZXkpCiAJTFdMb2Nr
QWNxdWlyZShQQVJUSVRJT05fTE9DSyhoYXNoX3RhYmxlLCBwYXJ0aXRpb24pLCBMV19FWENMVVNJ
VkUpOwogCWVuc3VyZV92YWxpZF9idWNrZXRfcG9pbnRlcnMoaGFzaF90YWJsZSk7CiAKLQlpZiAo
ZGVsZXRlX2tleV9mcm9tX2J1Y2tldChoYXNoX3RhYmxlLCBrZXksCisJaWYgKGRlbGV0ZV9rZXlf
ZnJvbV9idWNrZXQoaGFzaF90YWJsZSwga2V5LCBoYXNoLAogCQkJCQkJCSAgICZCVUNLRVRfRk9S
X0hBU0goaGFzaF90YWJsZSwgaGFzaCkpKQogCXsKIAkJQXNzZXJ0KGhhc2hfdGFibGUtPmNvbnRy
b2wtPnBhcnRpdGlvbnNbcGFydGl0aW9uXS5jb3VudCA+IDApOwpAQCAtOTg1LDE3ICs5ODcsMjcg
QEAgZW5zdXJlX3ZhbGlkX2J1Y2tldF9wb2ludGVycyhkc2hhc2hfdGFibGUgKmhhc2hfdGFibGUp
CiAKIC8qCiAgKiBTY2FuIGEgbG9ja2VkIGJ1Y2tldCBmb3IgYSBtYXRjaCwgdXNpbmcgdGhlIHBy
b3ZpZGVkIGNvbXBhcmUgZnVuY3Rpb24uCisgKiBTa2lwcyBpdGVtcyB3aG9zZSBjYWNoZWQgaGFz
aCB2YWx1ZXMgZG9uJ3QgbWF0Y2gsIGF2b2lkaW5nIGV4cGVuc2l2ZQorICoga2V5IGNvbXBhcmlz
b25zLgogICovCiBzdGF0aWMgaW5saW5lIGRzaGFzaF90YWJsZV9pdGVtICoKIGZpbmRfaW5fYnVj
a2V0KGRzaGFzaF90YWJsZSAqaGFzaF90YWJsZSwgY29uc3Qgdm9pZCAqa2V5LAotCQkJICAgZHNh
X3BvaW50ZXIgaXRlbV9wb2ludGVyKQorCQkJICAgZHNoYXNoX2hhc2ggaGFzaCwgZHNhX3BvaW50
ZXIgaXRlbV9wb2ludGVyKQogewogCXdoaWxlIChEc2FQb2ludGVySXNWYWxpZChpdGVtX3BvaW50
ZXIpKQogCXsKIAkJZHNoYXNoX3RhYmxlX2l0ZW0gKml0ZW07CiAKIAkJaXRlbSA9IGRzYV9nZXRf
YWRkcmVzcyhoYXNoX3RhYmxlLT5hcmVhLCBpdGVtX3BvaW50ZXIpOwotCQlpZiAoZXF1YWxfa2V5
cyhoYXNoX3RhYmxlLCBrZXksIEVOVFJZX0ZST01fSVRFTShpdGVtKSkpCisKKwkJLyoKKwkJICog
SWYgdGhlIGhhc2ggdmFsdWVzIGRvbid0IG1hdGNoLCB0aGUga2V5cyBjZXJ0YWlubHkgZG9uJ3Qg
bWF0Y2gKKwkJICogZWl0aGVyLCBzbyB3ZSBjYW4gc2tpcCB0aGUgZXhwZW5zaXZlIGtleSBjb21w
YXJpc29uLiAgTWF0Y2hpbmcKKwkJICogaGFzaGVzIGRvbid0IGd1YXJhbnRlZSBtYXRjaGluZyBr
ZXlzLCBzbyBlcXVhbF9rZXlzKCkgaXMgc3RpbGwKKwkJICogbmVlZGVkIGZvciBjb25maXJtYXRp
b24uCisJCSAqLworCQlpZiAoaXRlbS0+aGFzaCA9PSBoYXNoICYmCisJCQllcXVhbF9rZXlzKGhh
c2hfdGFibGUsIGtleSwgRU5UUllfRlJPTV9JVEVNKGl0ZW0pKSkKIAkJCXJldHVybiBpdGVtOwog
CQlpdGVtX3BvaW50ZXIgPSBpdGVtLT5uZXh0OwogCX0KQEAgLTEwNDcsMTAgKzEwNTksMTMgQEAg
aW5zZXJ0X2ludG9fYnVja2V0KGRzaGFzaF90YWJsZSAqaGFzaF90YWJsZSwKIAogLyoKICAqIFNl
YXJjaCBhIGJ1Y2tldCBmb3IgYSBtYXRjaGluZyBrZXkgYW5kIGRlbGV0ZSBpdC4KKyAqIFNraXBz
IGl0ZW1zIHdob3NlIGNhY2hlZCBoYXNoIHZhbHVlcyBkb24ndCBtYXRjaCwgYXZvaWRpbmcgZXhw
ZW5zaXZlCisgKiBrZXkgY29tcGFyaXNvbnMuCiAgKi8KIHN0YXRpYyBib29sCiBkZWxldGVfa2V5
X2Zyb21fYnVja2V0KGRzaGFzaF90YWJsZSAqaGFzaF90YWJsZSwKIAkJCQkJICAgY29uc3Qgdm9p
ZCAqa2V5LAorCQkJCQkgICBkc2hhc2hfaGFzaCBoYXNoLAogCQkJCQkgICBkc2FfcG9pbnRlciAq
YnVja2V0X2hlYWQpCiB7CiAJd2hpbGUgKERzYVBvaW50ZXJJc1ZhbGlkKCpidWNrZXRfaGVhZCkp
CkBAIC0xMDU5LDcgKzEwNzQsOSBAQCBkZWxldGVfa2V5X2Zyb21fYnVja2V0KGRzaGFzaF90YWJs
ZSAqaGFzaF90YWJsZSwKIAogCQlpdGVtID0gZHNhX2dldF9hZGRyZXNzKGhhc2hfdGFibGUtPmFy
ZWEsICpidWNrZXRfaGVhZCk7CiAKLQkJaWYgKGVxdWFsX2tleXMoaGFzaF90YWJsZSwga2V5LCBF
TlRSWV9GUk9NX0lURU0oaXRlbSkpKQorCQkvKiBTZWUgY29tbWVudCBpbiBmaW5kX2luX2J1Y2tl
dCgpICovCisJCWlmIChpdGVtLT5oYXNoID09IGhhc2ggJiYKKwkJCWVxdWFsX2tleXMoaGFzaF90
YWJsZSwga2V5LCBFTlRSWV9GUk9NX0lURU0oaXRlbSkpKQogCQl7CiAJCQlkc2FfcG9pbnRlciBu
ZXh0OwogCi0tIAoyLjUwLjEgKEFwcGxlIEdpdC0xNTUpCgo=
--000000000000c98b92064f250244--