MIME-Version: 1.0
References: 
 <CA+T=_GU-vTxFqRwWJMR4Hz8YUXkpUv_q6Nm3CrTqHNbhCrS5BA@mail.gmail.com>
 <CALj2ACVc3iYLOkC36VJwoXyVZmGcb0WEMKoc478q+xdRG+2BtA@mail.gmail.com>
In-Reply-To: 
 <CALj2ACVc3iYLOkC36VJwoXyVZmGcb0WEMKoc478q+xdRG+2BtA@mail.gmail.com>
From: shawn wang <shawn.wang.pg@gmail.com>
Date: Sat, 4 Apr 2026 00:14:34 +0800
Message-ID: 
 <CA+T=_GVx9+tZ0UnnkYoOnzg7_0F8SNYutEYULZNskpU_JmUHvA@mail.gmail.com>
Subject: Re: Add logical_decoding_spill_limit to cap spill file disk usage per
 slot
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="000000000000ba7f92064e909d2f"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BT%3D_GVx9%2BtZ0UnnkYoOnzg7_0F8SNYutEYULZNskpU_JmUHvA%40mail.gmail.com>
Precedence: bulk

--000000000000ba7f92064e909d2f
Content-Type: multipart/alternative; boundary="000000000000ba7f92064e909d2b"

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

Hi Bharath,

Thank you for the thorough and thoughtful review!


> Having a lot of spill files also increases crash/recovery times.
> However, files spilling to disk causing no-space-left-on-disk issues
> leading to downtime applies to WAL files, historical catalog snapshot
> files, subtransaction overflow files, CLOG (and all the subsystems
> backed by SLRU data structure), etc. - basically any Postgres
> subsystem writing files to disk. I'm a bit worried that we may end up
> solving disk space issues, which IMHO are outside of the database
> scope, in the database. Others may have different opinions though.

That's a fair philosophical point.  However, I'd argue that spill files
are uniquely unprotected compared to the other subsystems you mentioned:

  - WAL files =E2=86=92 max_slot_wal_keep_size
  - Temp files =E2=86=92 temp_file_limit
  - SLRU/CLOG =E2=86=92 bounded by design (sized proportionally to active X=
IDs)

Spill files are the gap: they can grow proportionally to the *data
volume* of in-progress transactions, not to the number of transactions,
and there is no existing upper bound.  A single bulk-load transaction
replicated via logical decoding can generate tens of GBs of spill files
with no way for the DBA to cap it.

So this is not about solving a general OS-level disk problem in the
database; it is about providing the same kind of safety net that already
exists for WAL (max_slot_wal_keep_size) and temp files (temp_file_limit)
=E2=80=94 a per-subsystem guardrail that the DBA can configure.


> How common is this issue? Could you please add a test case to the
> proposed patch that without this feature would otherwise hit the issue
> described?

Typically triggered by bulk data migrations or long-running DDL on large
tables,
combined with a subscriber that fell behind.  Each incident caused the
instance
to go read-only, affecting all workloads =E2=80=94 not just replication.

We have also seen reports of this in pgsql-general and on community
forums, though the root cause is not always identified as spill files.

Absolutely.  I will add a TAP test that:
  1. Creates 10 logical replication slots with test_decoding.
  2. Starts a large transaction that generates spill files exceeding
     the configured logical_decoding_spill_limit.
  3. Verifies that the walsender ERRORs out with the expected
     ERRCODE_CONFIGURATION_LIMIT_EXCEEDED.
  4. Verifies that spill files are cleaned up after the error.

I will include the 4 in v2.

Test case:
1. build a table:

psql -p 5432 -d postgres -c "
CREATE TABLE spill_load (
    id      bigint,
    payload text
);
"

2. build some slots:
#base

for i in $(seq 1 10); do
    psql -p 5432 -d postgres -c \
        "SELECT pg_create_logical_replication_slot('spill_slot_${i}',
'test_decoding');"
done

psql -p 5432 -d postgres -c \
    "SELECT slot_name, plugin, active FROM pg_replication_slots ORDER BY
slot_name;"

3. start pg_recvlogical:
#bash
mkdir -p /tmp/spill_test/pids

for i in $(seq 1 10); do
    pg_recvlogical \
        --dbname=3D"port=3D5432 dbname=3Dpostgres" \
        --slot=3D"spill_slot_${i}" \
        --start \
        --no-loop \
        --status-interval=3D0 \
        --file=3D/dev/null &
    echo $! > /tmp/spill_test/pids/recv_${i}.pid
    echo "Started pg_recvlogical for spill_slot_${i}, PID=3D$!"
done

sleep 2

psql -p 5432 -d postgres -c \
    "SELECT slot_name, active, active_pid
     FROM pg_replication_slots
     WHERE slot_name LIKE 'spill_slot_%'
     ORDER BY slot_name;"

4. make a big transaction:

psql -p 5432 -d postgres -c "
BEGIN;
INSERT INTO spill_load
    SELECT i, repeat('X', 100000)
    FROM generate_series(1, 10000000) i;
COMMIT;

"

> Having said that, were alternatives like disabling subscriptions when
> seen occupying the disk space considered?

Yes, we considered monitoring-based approaches, but they have inherent
limitations:

  1. Reaction latency: Even with 1-second polling, a high-throughput
     bulk load can spill gigabytes between two polls.  The spill rate
     can easily exceed 100 MB/s, so a 5-second monitoring gap means
     500 MB of uncontrolled growth.

  2. External dependency: Relying on an external tool means the
     protection is not available by default.  Every deployment must
     set up and maintain the monitoring =E2=80=94 and if it fails or is
     misconfigured, the disk-full scenario still occurs.

  3. No subscriber-side control: pg_recvlogical users and third-party
     CDC tools (Debezium, etc.) that consume directly from the
     publisher have no "subscription" to disable.

  4. Disabling a subscription does not immediately stop spilling:
     the walsender continues processing WAL records already in flight.

The proposed GUC acts as a synchronous, in-process safety valve =E2=80=94 i=
t
checks the limit at the exact point where the next spill write would
occur, with zero latency.  Monitoring and the GUC are complementary:
monitoring for alerting, the GUC as a hard backstop.


> When the logical_decoding_spill_limit is exceeded, ERRORing out in the
> walsender is even more problematic, right? The replication slot would
> be inactive, causing bloat and preventing tuple freezing, WAL files
> growth and eventually the system may hit disk-space issues - it is
> like "we avoided disk space issues for one subsystem, but introduced
> it for another". This looks a bit problematic IMHO. Others may have
> different opinions though.

This is a great point and deserves a careful answer.

First, the "inactive slot causes WAL growth" problem already has a
well-established solution: max_slot_wal_keep_size.  When this is
configured (which is recommended practice), an inactive slot will be
invalidated once WAL retention exceeds the limit, releasing both WAL
files and catalog bloat.  So the combination of:

logical_decoding_spill_limit + max_slot_wal_keep_size

provides defense in depth: the spill limit prevents the data disk from
filling up with spill files, while max_slot_wal_keep_size prevents WAL
disk from growing unboundedly due to an inactive slot.

Second, compare the two failure modes:

  (a) WITHOUT spill limit: disk fills up =E2=86=92 the ENTIRE instance goes
      read-only or shutdown.  All workloads stop.  Recovery requires manual
      intervention (rm spill files, restart).  Data loss is possible
      if WAL writes also fail.

  (b) WITH spill limit: walsender ERRORs =E2=86=92 only replication is
      interrupted.  The primary continues serving all read/write
      workloads normally.  The DBA receives a clear error message
      and can act: increase the limit, increase work_mem, enable
      streaming, or investigate the large transaction.

cenario (b) is strictly better than (a): it converts an
instance-wide outage into a replication-only interruption with a
clear, actionable error message.

Additionally, in the updated patch (v2), I have ensured that spill

files are properly cleaned up in the error path (via
WalSndErrorCleanup), so exceeding the limit does not leave orphaned
files on disk.

Best regards,
Shawn

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

<div><div><div>Hi Bharath,<br>
<br>
Thank you for the thorough and thoughtful review!</div></div></div><div><di=
v><div><br>
<br>
&gt; Having a lot of spill files also increases crash/recovery times.<br>
&gt; However, files spilling to disk causing no-space-left-on-disk issues<b=
r>
&gt; leading to downtime applies to WAL files, historical catalog snapshot<=
br>
&gt; files, subtransaction overflow files, CLOG (and all the subsystems<br>
&gt; backed by SLRU data structure), etc. - basically any Postgres<br>
&gt; subsystem writing files to disk. I&#39;m a bit worried that we may end=
 up<br>
&gt; solving disk space issues, which IMHO are outside of the database<br>
&gt; scope, in the database. Others may have different opinions though.<br>
<br></div></div></div><div><div><div>
That&#39;s a fair philosophical point.=C2=A0 However, I&#39;d argue that sp=
ill files<br>
are uniquely unprotected compared to the other subsystems you mentioned:<br=
>
<br>
=C2=A0 - WAL files =E2=86=92 max_slot_wal_keep_size<br>
=C2=A0 - Temp files =E2=86=92 temp_file_limit<br>
=C2=A0 - SLRU/CLOG =E2=86=92 bounded by design (sized proportionally to act=
ive XIDs)<br>
<br>
Spill files are the gap: they can grow proportionally to the *data<br>
volume* of in-progress transactions, not to the number of transactions,<br>
and there is no existing upper bound.=C2=A0 A single bulk-load transaction<=
br>
replicated via logical decoding can generate tens of GBs of spill files<br>
with no way for the DBA to cap it.<br>
<br>
So this is not about solving a general OS-level disk problem in the<br>
database; it is about providing the same kind of safety net that already<br=
>
exists for WAL (max_slot_wal_keep_size) and temp files (temp_file_limit)<br=
>
=E2=80=94 a per-subsystem guardrail that the DBA can configure.</div></div>=
</div><div><div><div><br>
<br>
<br>
&gt; How common is this issue? Could you please add a test case to the<br>
&gt; proposed patch that without this feature would otherwise hit the issue=
<br>
&gt; described?<br>
<br></div></div></div><div><div><div>
Typically triggered by bulk data migrations or long-running DDL on large ta=
bles,<br>
combined with a subscriber that fell behind.=C2=A0 Each incident caused the=
 instance<br>
to go read-only, affecting all workloads =E2=80=94 not just replication.<br=
>
<br>
We have also seen reports of this in pgsql-general and on community<br>
forums, though the root cause is not always identified as spill files.<br>
<br>
Absolutely.=C2=A0 I will add a TAP test that:<br>
=C2=A0 1. Creates 10 logical replication slots with test_decoding.<br>
=C2=A0 2. Starts a large transaction that generates spill files exceeding<b=
r>
=C2=A0 =C2=A0 =C2=A0the configured logical_decoding_spill_limit.<br>
=C2=A0 3. Verifies that the walsender ERRORs out with the expected<br>
=C2=A0 =C2=A0 =C2=A0ERRCODE_CONFIGURATION_LIMIT_EXCEEDED.<br>
=C2=A0 4. Verifies that spill files are cleaned up after the error.<br>
<br>
I will include the 4 in v2.<br>
<br>
Test case:<br>
1. build a table:<br>
<br>
psql -p 5432 -d postgres -c &quot;<br>
CREATE TABLE spill_load (<br>
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 bigint,<br>
=C2=A0 =C2=A0 payload text<br>
);<br>
&quot;<br>
<br>
2. build some slots:<br>
#base<br>
<br>
for i in $(seq 1 10); do<br>
=C2=A0 =C2=A0 psql -p 5432 -d postgres -c \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;SELECT pg_create_logical_replication_slot=
(&#39;spill_slot_${i}&#39;, &#39;test_decoding&#39;);&quot;<br>
done<br>
<br>
psql -p 5432 -d postgres -c \<br>
=C2=A0 =C2=A0 &quot;SELECT slot_name, plugin, active FROM pg_replication_sl=
ots ORDER BY slot_name;&quot;<br>
<br>
3. start pg_recvlogical:<br>
#bash<br>
mkdir -p /tmp/spill_test/pids<br>
<br>
for i in $(seq 1 10); do<br>
=C2=A0 =C2=A0 pg_recvlogical \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dbname=3D&quot;port=3D5432 dbname=3Dpostgres&=
quot; \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --slot=3D&quot;spill_slot_${i}&quot; \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --start \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --no-loop \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --status-interval=3D0 \<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --file=3D/dev/null &amp;<br>
=C2=A0 =C2=A0 echo $! &gt; /tmp/spill_test/pids/recv_${i}.pid<br>
=C2=A0 =C2=A0 echo &quot;Started pg_recvlogical for spill_slot_${i}, PID=3D=
$!&quot;<br>
done<br>
<br>
sleep 2<br>
<br>
psql -p 5432 -d postgres -c \<br>
=C2=A0 =C2=A0 &quot;SELECT slot_name, active, active_pid<br>
=C2=A0 =C2=A0 =C2=A0FROM pg_replication_slots<br>
=C2=A0 =C2=A0 =C2=A0WHERE slot_name LIKE &#39;spill_slot_%&#39;<br>
=C2=A0 =C2=A0 =C2=A0ORDER BY slot_name;&quot;<br>
<br>
4. make a big transaction:<br>
<br>
psql -p 5432 -d postgres -c &quot;<br>
BEGIN;<br>
INSERT INTO spill_load<br>
=C2=A0 =C2=A0 SELECT i, repeat(&#39;X&#39;, 100000)<br>
=C2=A0 =C2=A0 FROM generate_series(1, 10000000) i;<br>
COMMIT;</div></div></div><div><div><div><br>
&quot;<br>
<br>
&gt; Having said that, were alternatives like disabling subscriptions when<=
br>
&gt; seen occupying the disk space considered?<br>
<br></div></div></div><div><div><div>
Yes, we considered monitoring-based approaches, but they have inherent<br>
limitations:<br>
<br>
=C2=A0 1. Reaction latency: Even with 1-second polling, a high-throughput<b=
r>
=C2=A0 =C2=A0 =C2=A0bulk load can spill gigabytes between two polls.=C2=A0 =
The spill rate<br>
=C2=A0 =C2=A0 =C2=A0can easily exceed 100 MB/s, so a 5-second monitoring ga=
p means<br>
=C2=A0 =C2=A0 =C2=A0500 MB of uncontrolled growth.<br>
<br>
=C2=A0 2. External dependency: Relying on an external tool means the<br>
=C2=A0 =C2=A0 =C2=A0protection is not available by default.=C2=A0 Every dep=
loyment must<br>
=C2=A0 =C2=A0 =C2=A0set up and maintain the monitoring =E2=80=94 and if it =
fails or is<br>
=C2=A0 =C2=A0 =C2=A0misconfigured, the disk-full scenario still occurs.<br>
<br>
=C2=A0 3. No subscriber-side control: pg_recvlogical users and third-party<=
br>
=C2=A0 =C2=A0 =C2=A0CDC tools (Debezium, etc.) that consume directly from t=
he<br>
=C2=A0 =C2=A0 =C2=A0publisher have no &quot;subscription&quot; to disable.<=
br>
<br>
=C2=A0 4. Disabling a subscription does not immediately stop spilling:<br>
=C2=A0 =C2=A0 =C2=A0the walsender continues processing WAL records already =
in flight.<br>
<br>
The proposed GUC acts as a synchronous, in-process safety valve =E2=80=94 i=
t<br>
checks the limit at the exact point where the next spill write would<br>
occur, with zero latency.=C2=A0 Monitoring and the GUC are complementary:<b=
r>
monitoring for alerting, the GUC as a hard backstop.</div></div></div><div>=
<div><div><br>
<br>
&gt; When the logical_decoding_spill_limit is exceeded, ERRORing out in the=
<br>
&gt; walsender is even more problematic, right? The replication slot would<=
br>
&gt; be inactive, causing bloat and preventing tuple freezing, WAL files<br=
>
&gt; growth and eventually the system may hit disk-space issues - it is<br>
&gt; like &quot;we avoided disk space issues for one subsystem, but introdu=
ced<br>
&gt; it for another&quot;. This looks a bit problematic IMHO. Others may ha=
ve<br>
&gt; different opinions though.<br>
<br></div></div></div><div><div><div>
This is a great point and deserves a careful answer.<br>
<br>
First, the &quot;inactive slot causes WAL growth&quot; problem already has =
a<br>
well-established solution: max_slot_wal_keep_size.=C2=A0 When this is<br>
configured (which is recommended practice), an inactive slot will be<br>
invalidated once WAL retention exceeds the limit, releasing both WAL<br>
files and catalog bloat.=C2=A0 So the combination of:<br>
<br>
logical_decoding_spill_limit + max_slot_wal_keep_size<br>
<br>
provides defense in depth: the spill limit prevents the data disk from<br>
filling up with spill files, while max_slot_wal_keep_size prevents WAL<br>
disk from growing unboundedly due to an inactive slot.<br>
<br>
Second, compare the two failure modes:<br>
<br>
=C2=A0 (a) WITHOUT spill limit: disk fills up =E2=86=92 the ENTIRE instance=
 goes<br>
=C2=A0 =C2=A0 =C2=A0 read-only or shutdown.=C2=A0 All workloads stop.=C2=A0=
 Recovery requires manual<br>
=C2=A0 =C2=A0 =C2=A0 intervention (rm spill files, restart).=C2=A0 Data los=
s is possible<br>
=C2=A0 =C2=A0 =C2=A0 if WAL writes also fail.<br>
<br>
=C2=A0 (b) WITH spill limit: walsender ERRORs =E2=86=92 only replication is=
<br>
=C2=A0 =C2=A0 =C2=A0 interrupted.=C2=A0 The primary continues serving all r=
ead/write<br>
=C2=A0 =C2=A0 =C2=A0 workloads normally.=C2=A0 The DBA receives a clear err=
or message<br>
=C2=A0 =C2=A0 =C2=A0 and can act: increase the limit, increase work_mem, en=
able<br>
=C2=A0 =C2=A0 =C2=A0 streaming, or investigate the large transaction.<br>
<br>
cenario (b) is strictly better than (a): it converts an<br>
instance-wide outage into a replication-only interruption with a<br>
clear, actionable error message.<br>
<br>
Additionally, in the updated patch (v2), I have ensured that spill</div></d=
iv><div><br>
files are properly cleaned up in the error path (via<br></div><div>
WalSndErrorCleanup), so exceeding the limit does not leave orphaned<br>
files on disk.<br>
<br>
Best regards,<br>
Shawn<br>

</div>
</div>

--000000000000ba7f92064e909d2b--

--000000000000ba7f92064e909d2f
Content-Type: application/x-patch;
	name="v2-0001-Add-logical_decoding_spill_limit-GUC-to-cap-spill-file-limit.patch"
Content-Disposition: attachment;
	filename="v2-0001-Add-logical_decoding_spill_limit-GUC-to-cap-spill-file-limit.patch"
Content-Transfer-Encoding: base64
Content-ID: <19d52c369fdc77ccce01>
X-Attachment-Id: 19d52c369fdc77ccce01

RnJvbSAzNjkzMDYyYjYzYWNiMTg5ZjY1N2M4MTljMWRmMGY1NWZkZmZhMTE4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBTaGF3biBXYW5nIDxzaGF3bi53YW5nLnBnQGdtYWlsLmNvbT4K
RGF0ZTogTW9uLCAyMyBNYXIgMjAyNiAyMDo0NjowOCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggdjJd
IEFkZCBsb2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0IEdVQyB0byBjYXAgc3BpbGwgZmlsZQog
ZGlzayB1c2FnZS4KCldoZW4gbG9naWNhbCBkZWNvZGluZyBleGNlZWRzIGxvZ2ljYWxfZGVjb2Rp
bmdfd29ya19tZW0sIGNoYW5nZXMgYXJlCnNwaWxsZWQgdG8gZGlzayB1bmRlciBwZ19yZXBsc2xv
dC88c2xvdD4vLiAgQ3VycmVudGx5IHRoZXJlIGlzIG5vCmxpbWl0IG9uIHRoZSB0b3RhbCBzaXpl
IG9mIHRoZXNlIHNwaWxsIGZpbGVzLCB3aGljaCBjYW4gbGVhZCB0bwp1bmNvbnRyb2xsZWQgZGlz
ayBzcGFjZSBjb25zdW1wdGlvbiBmb3IgbGFyZ2Ugb3IgbnVtZXJvdXMgY29uY3VycmVudAp0cmFu
c2FjdGlvbnMuCgpBZGQgYSBuZXcgR1VDIGxvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQgKGlu
dGVnZXIsIHVuaXQga0IsCmRlZmF1bHQgMCBtZWFuaW5nIHVubGltaXRlZCkgdGhhdCBsaW1pdHMg
dGhlIHRvdGFsIG9uLWRpc2sgc3BpbGwgZmlsZQpzaXplIHBlciByZXBsaWNhdGlvbiBzbG90LiAg
VGhlIGltcGxlbWVudGF0aW9uIHRyYWNrcyB0aGUgY3VycmVudApvbi1kaXNrIGZvb3RwcmludCBp
biBSZW9yZGVyQnVmZmVyLnNwaWxsQnl0ZXNPbkRpc2sgKGluY3JlbWVudGVkCmFmdGVyIGVhY2gg
c3VjY2Vzc2Z1bCB3cml0ZSBpbiBSZW9yZGVyQnVmZmVyU2VyaWFsaXplQ2hhbmdlLApkZWNyZW1l
bnRlZCB3aGVuIHNwaWxsIGZpbGVzIGFyZSByZW1vdmVkIGluClJlb3JkZXJCdWZmZXJSZXN0b3Jl
Q2xlYW51cCkgYW5kIHBlci10cmFuc2FjdGlvbiBpbgpSZW9yZGVyQnVmZmVyVFhOLnNlcmlhbGl6
ZWRfc2l6ZS4KCkJlZm9yZSBzZXJpYWxpemluZyBhIHRyYW5zYWN0aW9uIHRvIGRpc2ssIFJlb3Jk
ZXJCdWZmZXJDaGVja01lbW9yeUxpbWl0CmNoZWNrcyB3aGV0aGVyIHRoZSBwcm9qZWN0ZWQgd3Jp
dGUgd291bGQgZXhjZWVkIHRoZSBjb25maWd1cmVkIGxpbWl0LgpJZiBzbywgaXQgcmFpc2VzIGFu
IEVSUk9SLiAgVGhlIHJlcGxpY2F0aW9uIHNsb3Qgc3RhdGUgKHJlc3RhcnRfbHNuLApjb25maXJt
ZWRfZmx1c2gpIGlzIHByZXNlcnZlZCwgc28gdGhlIHN1YnNjcmliZXIgY2FuIHJlY29ubmVjdCBh
ZnRlcgp0aGUgYWRtaW5pc3RyYXRvciBpbmNyZWFzZXMgdGhlIGxpbWl0LCByYWlzZXMgbG9naWNh
bF9kZWNvZGluZ193b3JrX21lbSwKb3Igc3dpdGNoZXMgdG8gYSBzdHJlYW1pbmctY2FwYWJsZSBv
dXRwdXQgcGx1Z2luLgoKVGhlIGNoZWNrIGlzIG9ubHkgb24gdGhlIHNwaWxsLXRvLWRpc2sgcGF0
aCAobm90IHRoZSBzdHJlYW1pbmcgcGF0aCwKd2hpY2ggaW52b2x2ZXMgbm8gZGlzayBJL08pIGFu
ZCBvbmx5IHdoZW4gdGhlIGxpbWl0IGlzIHNldCAoPiAwKSwgc28KdGhlcmUgaXMgemVybyBvdmVy
aGVhZCBvbiB0aGUgbm9ybWFsIGhvdCBwYXRoIGFuZCBmdWxsIGJhY2t3YXJkCmNvbXBhdGliaWxp
dHkgd2l0aCBleGlzdGluZyBjb25maWd1cmF0aW9ucy4KCkFkZGl0aW9uYWxseSwgZW5zdXJlIHNw
aWxsIGZpbGVzIGFyZSBjbGVhbmVkIHVwIGR1cmluZyBlcnJvciByZWNvdmVyeS4KRXhwb3J0IFJl
b3JkZXJCdWZmZXJDbGVhbnVwU2VyaWFsaXplZFRYTnMoKSBhbmQgY2FsbCBpdCBpbgpXYWxTbmRF
cnJvckNsZWFudXAoKSBiZWZvcmUgcmVsZWFzaW5nIHRoZSByZXBsaWNhdGlvbiBzbG90LCBzbyB0
aGF0CnNwaWxsIGZpbGVzIGxlZnQgYmVoaW5kIGJ5IHRoZSBFUlJPUiBhcmUgcHJvcGVybHkgcmVt
b3ZlZC4gIFdpdGhvdXQKdGhpcywgdGhlIGVycm9yIHBhdGggd291bGQgcmVsZWFzZSB0aGUgc2xv
dCAoc2V0dGluZyBNeVJlcGxpY2F0aW9uU2xvdAp0byBOVUxMKSBiZWZvcmUgYW55IGNoYW5jZSB0
byBjbGVhbiB1cCwgbGVhdmluZyBvcnBoYW5lZCBzcGlsbCBmaWxlcwpvbiBkaXNrIHVudGlsIHRo
ZSBuZXh0IHdhbHNlbmRlciBjb25uZWN0cyB0byB0aGUgc2FtZSBzbG90IG9yIHRoZQpzZXJ2ZXIg
cmVzdGFydHMuCi0tLQogZG9jL3NyYy9zZ21sL2NvbmZpZy5zZ21sICAgICAgICAgICAgICAgICAg
ICAgIHwgMjQgKysrKysrKysKIC4uLi9yZXBsaWNhdGlvbi9sb2dpY2FsL3Jlb3JkZXJidWZmZXIu
YyAgICAgICB8IDYwICsrKysrKysrKysrKysrKysrKy0KIHNyYy9iYWNrZW5kL3JlcGxpY2F0aW9u
L3dhbHNlbmRlci5jICAgICAgICAgICB8IDEyICsrKysKIHNyYy9iYWNrZW5kL3V0aWxzL21pc2Mv
Z3VjX3BhcmFtZXRlcnMuZGF0ICAgICB8IDEwICsrKysKIHNyYy9iYWNrZW5kL3V0aWxzL21pc2Mv
cG9zdGdyZXNxbC5jb25mLnNhbXBsZSB8ICAyICsKIHNyYy9pbmNsdWRlL3JlcGxpY2F0aW9uL3Jl
b3JkZXJidWZmZXIuaCAgICAgICB8IDE4ICsrKysrKwogNiBmaWxlcyBjaGFuZ2VkLCAxMjQgaW5z
ZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kb2Mvc3JjL3NnbWwvY29u
ZmlnLnNnbWwgYi9kb2Mvc3JjL3NnbWwvY29uZmlnLnNnbWwKaW5kZXggOGNkZDgyNmZiZDMuLmU2
ZmM5NjUzZmVmIDEwMDY0NAotLS0gYS9kb2Mvc3JjL3NnbWwvY29uZmlnLnNnbWwKKysrIGIvZG9j
L3NyYy9zZ21sL2NvbmZpZy5zZ21sCkBAIC0yMTIwLDYgKzIxMjAsMzAgQEAgaW5jbHVkZV9kaXIg
J2NvbmYuZCcKICAgICAgIDwvbGlzdGl0ZW0+CiAgICAgIDwvdmFybGlzdGVudHJ5PgogCisgICAg
IDx2YXJsaXN0ZW50cnkgaWQ9Imd1Yy1sb2dpY2FsLWRlY29kaW5nLXNwaWxsLWxpbWl0IiB4cmVm
bGFiZWw9ImxvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQiPgorICAgICAgPHRlcm0+PHZhcm5h
bWU+bG9naWNhbF9kZWNvZGluZ19zcGlsbF9saW1pdDwvdmFybmFtZT4gKDx0eXBlPmludGVnZXI8
L3R5cGU+KQorICAgICAgPGluZGV4dGVybT4KKyAgICAgICA8cHJpbWFyeT48dmFybmFtZT5sb2dp
Y2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0PC92YXJuYW1lPiBjb25maWd1cmF0aW9uIHBhcmFtZXRl
cjwvcHJpbWFyeT4KKyAgICAgIDwvaW5kZXh0ZXJtPgorICAgICAgPC90ZXJtPgorICAgICAgPGxp
c3RpdGVtPgorICAgICAgIDxwYXJhPgorICAgICAgICBTcGVjaWZpZXMgdGhlIG1heGltdW0gdG90
YWwgc2l6ZSBvZiBvbi1kaXNrIHNwaWxsIGZpbGVzIHRoYXQgbG9naWNhbAorICAgICAgICBkZWNv
ZGluZyBtYXkgdXNlIHBlciByZXBsaWNhdGlvbiBzbG90LiBXaGVuIGNoYW5nZXMgZXhjZWVkIHRo
ZSBtZW1vcnkKKyAgICAgICAgbGltaXQgc2V0IGJ5IDx2YXJuYW1lPmxvZ2ljYWxfZGVjb2Rpbmdf
d29ya19tZW08L3Zhcm5hbWU+LCB0aGV5IGFyZQorICAgICAgICBzcGlsbGVkIHRvIGRpc2suIFRo
aXMgcGFyYW1ldGVyIGxpbWl0cyB0aGUgdG90YWwgYW1vdW50IG9mIGRpc2sgc3BhY2UKKyAgICAg
ICAgdXNlZCBieSB0aG9zZSBzcGlsbCBmaWxlcy4gSWYgdGhlIGxpbWl0IHdvdWxkIGJlIGV4Y2Vl
ZGVkLCB0aGUKKyAgICAgICAgd2Fsc2VuZGVyIHByb2Nlc3MgcmFpc2VzIGFuIGVycm9yIGFuZCBk
aXNjb25uZWN0cy4gVGhlIHJlcGxpY2F0aW9uCisgICAgICAgIHNsb3QncyBzdGF0ZSBpcyBwcmVz
ZXJ2ZWQsIHNvIHRoZSBzdWJzY3JpYmVyIGNhbiByZWNvbm5lY3QgYWZ0ZXIgdGhlCisgICAgICAg
IGFkbWluaXN0cmF0b3IgaW5jcmVhc2VzIHRoaXMgbGltaXQgb3Igc3dpdGNoZXMgdG8gYSBzdHJl
YW1pbmctY2FwYWJsZQorICAgICAgICBvdXRwdXQgcGx1Z2luLgorICAgICAgICBJZiB0aGlzIHZh
bHVlIGlzIHNwZWNpZmllZCB3aXRob3V0IHVuaXRzLCBpdCBpcyB0YWtlbiBhcyBraWxvYnl0ZXMu
CisgICAgICAgIFRoZSBkZWZhdWx0IHZhbHVlIGlzIDxsaXRlcmFsPjA8L2xpdGVyYWw+LCB3aGlj
aCBtZWFucyB0aGVyZSBpcyBubworICAgICAgICBsaW1pdCBvbiBzcGlsbCBmaWxlIGRpc2sgdXNh
Z2UuCisgICAgICAgPC9wYXJhPgorICAgICAgPC9saXN0aXRlbT4KKyAgICAgPC92YXJsaXN0ZW50
cnk+CisKICAgICAgPHZhcmxpc3RlbnRyeSBpZD0iZ3VjLWNvbW1pdC10aW1lc3RhbXAtYnVmZmVy
cyIgeHJlZmxhYmVsPSJjb21taXRfdGltZXN0YW1wX2J1ZmZlcnMiPgogICAgICAgPHRlcm0+PHZh
cm5hbWU+Y29tbWl0X3RpbWVzdGFtcF9idWZmZXJzPC92YXJuYW1lPiAoPHR5cGU+aW50ZWdlcjwv
dHlwZT4pCiAgICAgICA8aW5kZXh0ZXJtPgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvcmVwbGlj
YXRpb24vbG9naWNhbC9yZW9yZGVyYnVmZmVyLmMgYi9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9s
b2dpY2FsL3Jlb3JkZXJidWZmZXIuYwppbmRleCA2ODJkMTNjOWYyMi4uOTVlNWIwZjA1MDcgMTAw
NjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL2xvZ2ljYWwvcmVvcmRlcmJ1ZmZlci5j
CisrKyBiL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL2xvZ2ljYWwvcmVvcmRlcmJ1ZmZlci5jCkBA
IC03Miw2ICs3MiwxNSBAQAogICoJICBjb3VudGVyIGlzIHVwZGF0ZWQ7IGhvd2V2ZXIgdHJhbnNh
Y3Rpb25zIHdpdGggc2l6ZSAwIGFyZSBub3Qgc3RvcmVkIGluCiAgKgkgIHRoZSBoZWFwLCBiZWNh
dXNlIHRoZXkgaGF2ZSBubyBjaGFuZ2VzIHRvIGV2aWN0LgogICoKKyAqCSAgVG8gcHJldmVudCBz
cGlsbCBmaWxlcyBmcm9tIGNvbnN1bWluZyB1bmJvdW5kZWQgZGlzayBzcGFjZSwgdGhlCisgKgkg
IGxvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQgR1VDIGNhbiBiZSBzZXQgdG8gbGltaXQgdGhl
IHRvdGFsIHNpemUKKyAqCSAgb2Ygc3BpbGwgZmlsZXMgcGVyIHJlcGxpY2F0aW9uIHNsb3QuICBX
ZSB0cmFjayB0aGUgY3VycmVudCBvbi1kaXNrCisgKgkgIGZvb3RwcmludCBpbiBSZW9yZGVyQnVm
ZmVyLnNwaWxsQnl0ZXNPbkRpc2sgKGluY3JlbWVudGVkIG9uIGVhY2gKKyAqCSAgc3VjY2Vzc2Z1
bCB3cml0ZSwgZGVjcmVtZW50ZWQgd2hlbiBzcGlsbCBmaWxlcyBhcmUgY2xlYW5lZCB1cCkgYW5k
CisgKgkgIHBlci10cmFuc2FjdGlvbiBpbiBSZW9yZGVyQnVmZmVyVFhOLnNlcmlhbGl6ZWRfc2l6
ZS4gIEJlZm9yZQorICoJICBzZXJpYWxpemluZyBhIHRyYW5zYWN0aW9uLCB3ZSBjaGVjayB3aGV0
aGVyIHRoZSBwcm9qZWN0ZWQgd3JpdGUgd291bGQKKyAqCSAgZXhjZWVkIHRoZSBjb25maWd1cmVk
IGxpbWl0IGFuZCByYWlzZSBhbiBFUlJPUiBpZiBzby4KKyAqCiAgKgkgIFdlIHN0aWxsIHJlbHkg
b24gbWF4X2NoYW5nZXNfaW5fbWVtb3J5IHdoZW4gbG9hZGluZyBzZXJpYWxpemVkIGNoYW5nZXMK
ICAqCSAgYmFjayBpbnRvIG1lbW9yeS4gQXQgdGhhdCBwb2ludCB3ZSBjYW4ndCB1c2UgdGhlIG1l
bW9yeSBsaW1pdCBkaXJlY3RseQogICoJICBhcyB3ZSBsb2FkIHRoZSBzdWJ4YWN0cyBpbmRlcGVu
ZGVudGx5LiBPbmUgb3B0aW9uIHRvIGRlYWwgd2l0aCB0aGlzCkBAIC0yMjQsNiArMjMzLDcgQEAg
dHlwZWRlZiBzdHJ1Y3QgUmVvcmRlckJ1ZmZlckRpc2tDaGFuZ2UKICAqIGxpa2UuCiAgKi8KIGlu
dAkJCWxvZ2ljYWxfZGVjb2Rpbmdfd29ya19tZW07CitpbnQJCQlsb2dpY2FsX2RlY29kaW5nX3Nw
aWxsX2xpbWl0Owogc3RhdGljIGNvbnN0IFNpemUgbWF4X2NoYW5nZXNfaW5fbWVtb3J5ID0gNDA5
NjsgLyogWFhYIGZvciByZXN0b3JlIG9ubHkgKi8KIAogLyogR1VDIHZhcmlhYmxlICovCkBAIC0y
NzYsNyArMjg2LDcgQEAgc3RhdGljIHZvaWQgUmVvcmRlckJ1ZmZlclRydW5jYXRlVFhOKFJlb3Jk
ZXJCdWZmZXIgKnJiLCBSZW9yZGVyQnVmZmVyVFhOICp0eG4sCiAJCQkJCQkJCQkgYm9vbCB0eG5f
cHJlcGFyZWQpOwogc3RhdGljIHZvaWQgUmVvcmRlckJ1ZmZlck1heWJlTWFya1RYTlN0cmVhbWVk
KFJlb3JkZXJCdWZmZXIgKnJiLCBSZW9yZGVyQnVmZmVyVFhOICp0eG4pOwogc3RhdGljIGJvb2wg
UmVvcmRlckJ1ZmZlckNoZWNrQW5kVHJ1bmNhdGVBYm9ydGVkVFhOKFJlb3JkZXJCdWZmZXIgKnJi
LCBSZW9yZGVyQnVmZmVyVFhOICp0eG4pOwotc3RhdGljIHZvaWQgUmVvcmRlckJ1ZmZlckNsZWFu
dXBTZXJpYWxpemVkVFhOcyhjb25zdCBjaGFyICpzbG90bmFtZSk7CisvKiBSZW9yZGVyQnVmZmVy
Q2xlYW51cFNlcmlhbGl6ZWRUWE5zIGlzIGRlY2xhcmVkIGluIHJlb3JkZXJidWZmZXIuaCAqLwog
c3RhdGljIHZvaWQgUmVvcmRlckJ1ZmZlclNlcmlhbGl6ZWRQYXRoKGNoYXIgKnBhdGgsIFJlcGxp
Y2F0aW9uU2xvdCAqc2xvdCwKIAkJCQkJCQkJCQlUcmFuc2FjdGlvbklkIHhpZCwgWExvZ1NlZ05v
IHNlZ25vKTsKIHN0YXRpYyBpbnQJUmVvcmRlckJ1ZmZlclRYTlNpemVDb21wYXJlKGNvbnN0IHBh
aXJpbmdoZWFwX25vZGUgKmEsIGNvbnN0IHBhaXJpbmdoZWFwX25vZGUgKmIsIHZvaWQgKmFyZyk7
CkBAIC0zODg1LDYgKzM4OTUsMTAgQEAgUmVvcmRlckJ1ZmZlckxhcmdlc3RTdHJlYW1hYmxlVG9w
VFhOKFJlb3JkZXJCdWZmZXIgKnJiKQogICogSWYgZGVidWdfbG9naWNhbF9yZXBsaWNhdGlvbl9z
dHJlYW1pbmcgaXMgc2V0IHRvICJpbW1lZGlhdGUiLCBzdHJlYW0gb3IKICAqIHNlcmlhbGl6ZSB0
aGUgY2hhbmdlcyBpbW1lZGlhdGVseS4KICAqCisgKiBXaGVuIHNwaWxsaW5nIHRvIGRpc2ssIGlm
IGxvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQgaXMgc2V0ICg+IDApLAorICogd2UgY2hlY2sg
d2hldGhlciB0aGUgcHJvamVjdGVkIHdyaXRlIHdvdWxkIGV4Y2VlZCB0aGUgY29uZmlndXJlZCBs
aW1pdAorICogYW5kIHJhaXNlIGFuIEVSUk9SIGlmIHNvLCB0byBwcmV2ZW50IHVuYm91bmRlZCBk
aXNrIHVzYWdlLgorICoKICAqIFhYWCBBdCB0aGlzIHBvaW50IHdlIHNlbGVjdCB0aGUgdHJhbnNh
Y3Rpb25zIHVudGlsIHdlIHJlYWNoIHVuZGVyIHRoZSBtZW1vcnkKICAqIGxpbWl0LCBidXQgd2Ug
bWlnaHQgYWxzbyBhZGFwdCBhIG1vcmUgZWxhYm9yYXRlIGV2aWN0aW9uIHN0cmF0ZWd5IC0gZm9y
IGV4YW1wbGUKICAqIGV2aWN0aW5nIGVub3VnaCB0cmFuc2FjdGlvbnMgdG8gZnJlZSBjZXJ0YWlu
IGZyYWN0aW9uIChlLmcuIDUwJSkgb2YgdGhlIG1lbW9yeQpAQCAtMzk2NCw2ICszOTc4LDM2IEBA
IFJlb3JkZXJCdWZmZXJDaGVja01lbW9yeUxpbWl0KFJlb3JkZXJCdWZmZXIgKnJiKQogCQkJaWYg
KFJlb3JkZXJCdWZmZXJDaGVja0FuZFRydW5jYXRlQWJvcnRlZFRYTihyYiwgdHhuKSkKIAkJCQlj
b250aW51ZTsKIAorCQkJLyoKKwkJCSAqIENoZWNrIHRoZSBzcGlsbC10by1kaXNrIHNpemUgbGlt
aXQgYmVmb3JlIGFjdHVhbGx5IHNlcmlhbGl6aW5nLgorCQkJICogV2UgdXNlIHRoZSB0cmFuc2Fj
dGlvbidzIGluLW1lbW9yeSBzaXplIGFzIGFuIGVzdGltYXRlIG9mIGhvdworCQkJICogbXVjaCB3
aWxsIGJlIHdyaXR0ZW4sIHdoaWNoIGlzIGEgcmVhc29uYWJsZSBhcHByb3hpbWF0aW9uLgorCQkJ
ICoKKwkJCSAqIFdlIG9ubHkgY2hlY2sgd2hlbiBsb2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0
IGlzIHNldCAoPiAwKS4KKwkJCSAqIFdoZW4gdGhlIGxpbWl0IHdvdWxkIGJlIGV4Y2VlZGVkLCBy
YWlzZSBhbiBFUlJPUi4gIFRoZQorCQkJICogd2Fsc2VuZGVyIHdpbGwgZXhpdCwgYnV0IHRoZSBy
ZXBsaWNhdGlvbiBzbG90J3MgcmVzdGFydF9sc24gaXMKKwkJCSAqIHByZXNlcnZlZCBzbyB0aGUg
c3Vic2NyaWJlciBjYW4gcmVjb25uZWN0IGFmdGVyIHRoZSBEQkEKKwkJCSAqIGluY3JlYXNlcyB0
aGUgbGltaXQgb3Igc3dpdGNoZXMgdG8gYSBzdHJlYW1pbmctY2FwYWJsZSBvdXRwdXQKKwkJCSAq
IHBsdWdpbi4KKwkJCSAqLworCQkJaWYgKGxvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQgPiAw
ICYmCisJCQkJcmItPnNwaWxsQnl0ZXNPbkRpc2sgKyB0eG4tPnNpemUgPgorCQkJCShTaXplKSBs
b2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0ICogMTAyNCkKKwkJCXsKKwkJCQllcmVwb3J0KEVS
Uk9SLAorCQkJCQkJKGVycmNvZGUoRVJSQ09ERV9DT05GSUdVUkFUSU9OX0xJTUlUX0VYQ0VFREVE
KSwKKwkJCQkJCSBlcnJtc2coImxvZ2ljYWwgZGVjb2Rpbmcgc3BpbGwgZmlsZSBzaXplIGxpbWl0
IGV4Y2VlZGVkIiksCisJCQkJCQkgZXJyZGV0YWlsKCJDdXJyZW50IG9uLWRpc2sgc3BpbGwgc2l6
ZSBpcyAlenUgYnl0ZXMsICIKKwkJCQkJCQkJICAgInRyYW5zYWN0aW9uIHRvIHNwaWxsIGlzICV6
dSBieXRlcywgIgorCQkJCQkJCQkgICAibGltaXQgaXMgJWQga0IuIiwKKwkJCQkJCQkJICAgcmIt
PnNwaWxsQnl0ZXNPbkRpc2ssIHR4bi0+c2l6ZSwKKwkJCQkJCQkJICAgbG9naWNhbF9kZWNvZGlu
Z19zcGlsbF9saW1pdCksCisJCQkJCQkgZXJyaGludCgiQ29uc2lkZXIgaW5jcmVhc2luZyAlcywg
JXMsICIKKwkJCQkJCQkJICJvciB1c2luZyBhIHN0cmVhbWluZy1jYXBhYmxlIG91dHB1dCBwbHVn
aW4uIiwKKwkJCQkJCQkJICJsb2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0IiwKKwkJCQkJCQkJ
ICJsb2dpY2FsX2RlY29kaW5nX3dvcmtfbWVtIikpKTsKKwkJCX0KKwogCQkJUmVvcmRlckJ1ZmZl
clNlcmlhbGl6ZVRYTihyYiwgdHhuKTsKIAkJfQogCkBAIC00Mjg2LDYgKzQzMzAsMTMgQEAgUmVv
cmRlckJ1ZmZlclNlcmlhbGl6ZUNoYW5nZShSZW9yZGVyQnVmZmVyICpyYiwgUmVvcmRlckJ1ZmZl
clRYTiAqdHhuLAogCX0KIAlwZ3N0YXRfcmVwb3J0X3dhaXRfZW5kKCk7CiAKKwkvKgorCSAqIFVw
ZGF0ZSB0aGUgb24tZGlzayBzcGlsbCBzaXplIGFjY291bnRpbmcgZm9yIGJvdGggdGhlIHRyYW5z
YWN0aW9uIGFuZAorCSAqIHRoZSByZW9yZGVyIGJ1ZmZlci4gIFRoaXMgaXMgdXNlZCB0byBlbmZv
cmNlIGxvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQuCisJICovCisJdHhuLT5zZXJpYWxpemVk
X3NpemUgKz0gb25kaXNrLT5zaXplOworCXJiLT5zcGlsbEJ5dGVzT25EaXNrICs9IG9uZGlzay0+
c2l6ZTsKKwogCS8qCiAJICogS2VlcCB0aGUgdHJhbnNhY3Rpb24ncyBmaW5hbF9sc24gdXAgdG8g
ZGF0ZSB3aXRoIGVhY2ggY2hhbmdlIHdlIHNlbmQgdG8KIAkgKiBkaXNrLCBzbyB0aGF0IFJlb3Jk
ZXJCdWZmZXJSZXN0b3JlQ2xlYW51cCB3b3JrcyBjb3JyZWN0bHkuICAoV2UgdXNlZCB0bwpAQCAt
NDg3MiwxMyArNDkyMywxOCBAQCBSZW9yZGVyQnVmZmVyUmVzdG9yZUNsZWFudXAoUmVvcmRlckJ1
ZmZlciAqcmIsIFJlb3JkZXJCdWZmZXJUWE4gKnR4bikKIAkJCQkJKGVycmNvZGVfZm9yX2ZpbGVf
YWNjZXNzKCksCiAJCQkJCSBlcnJtc2coImNvdWxkIG5vdCByZW1vdmUgZmlsZSBcIiVzXCI6ICVt
IiwgcGF0aCkpKTsKIAl9CisKKwkvKiBVcGRhdGUgdGhlIG9uLWRpc2sgc3BpbGwgc2l6ZSBhY2Nv
dW50aW5nLiAqLworCUFzc2VydChyYi0+c3BpbGxCeXRlc09uRGlzayA+PSB0eG4tPnNlcmlhbGl6
ZWRfc2l6ZSk7CisJcmItPnNwaWxsQnl0ZXNPbkRpc2sgLT0gdHhuLT5zZXJpYWxpemVkX3NpemU7
CisJdHhuLT5zZXJpYWxpemVkX3NpemUgPSAwOwogfQogCiAvKgogICogUmVtb3ZlIGFueSBsZWZ0
b3ZlciBzZXJpYWxpemVkIHJlb3JkZXIgYnVmZmVycyBmcm9tIGEgc2xvdCBkaXJlY3RvcnkgYWZ0
ZXIgYQogICogcHJpb3IgY3Jhc2ggb3IgZGVjb2Rpbmcgc2Vzc2lvbiBleGl0LgogICovCi1zdGF0
aWMgdm9pZAordm9pZAogUmVvcmRlckJ1ZmZlckNsZWFudXBTZXJpYWxpemVkVFhOcyhjb25zdCBj
aGFyICpzbG90bmFtZSkKIHsKIAlESVIJCSAgICpzcGlsbF9kaXI7CmRpZmYgLS1naXQgYS9zcmMv
YmFja2VuZC9yZXBsaWNhdGlvbi93YWxzZW5kZXIuYyBiL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9u
L3dhbHNlbmRlci5jCmluZGV4IDA4MjUzMTAzY2IzLi4yY2E5OWIzMWM1YiAxMDA2NDQKLS0tIGEv
c3JjL2JhY2tlbmQvcmVwbGljYXRpb24vd2Fsc2VuZGVyLmMKKysrIGIvc3JjL2JhY2tlbmQvcmVw
bGljYXRpb24vd2Fsc2VuZGVyLmMKQEAgLTM1Niw2ICszNTYsMTggQEAgV2FsU25kRXJyb3JDbGVh
bnVwKHZvaWQpCiAJaWYgKHhsb2dyZWFkZXIgIT0gTlVMTCAmJiB4bG9ncmVhZGVyLT5zZWcud3Nf
ZmlsZSA+PSAwKQogCQl3YWxfc2VnbWVudF9jbG9zZSh4bG9ncmVhZGVyKTsKIAorCS8qCisJICog
Q2xlYW4gdXAgc3BpbGwgZmlsZXMgYmVmb3JlIHJlbGVhc2luZyB0aGUgc2xvdCwgYmVjYXVzZQor
CSAqIFJlb3JkZXJCdWZmZXJDbGVhbnVwU2VyaWFsaXplZFRYTnMoKSBuZWVkcyB0aGUgc2xvdCBu
YW1lIHRvIGxvY2F0ZSB0aGUKKwkgKiBkaXJlY3RvcnkuICBXZSB1c2UgdGhlIHN0YXRpYyBsb2dp
Y2FsX2RlY29kaW5nX2N0eCB0byBkZXRlcm1pbmUgd2hldGhlcgorCSAqIHdlIGFyZSBpbiBhIGxv
Z2ljYWwgZGVjb2Rpbmcgc2Vzc2lvbi4KKwkgKi8KKwlpZiAobG9naWNhbF9kZWNvZGluZ19jdHgg
IT0gTlVMTCAmJiBNeVJlcGxpY2F0aW9uU2xvdCAhPSBOVUxMKQorCXsKKwkJUmVvcmRlckJ1ZmZl
ckNsZWFudXBTZXJpYWxpemVkVFhOcyhOYW1lU3RyKE15UmVwbGljYXRpb25TbG90LT5kYXRhLm5h
bWUpKTsKKwkJbG9naWNhbF9kZWNvZGluZ19jdHggPSBOVUxMOworCX0KKwogCWlmIChNeVJlcGxp
Y2F0aW9uU2xvdCAhPSBOVUxMKQogCQlSZXBsaWNhdGlvblNsb3RSZWxlYXNlKCk7CiAKZGlmZiAt
LWdpdCBhL3NyYy9iYWNrZW5kL3V0aWxzL21pc2MvZ3VjX3BhcmFtZXRlcnMuZGF0IGIvc3JjL2Jh
Y2tlbmQvdXRpbHMvbWlzYy9ndWNfcGFyYW1ldGVycy5kYXQKaW5kZXggMGM5ODU0YWQ4ZmMuLjMx
NjhkMjNmMzg3IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC91dGlscy9taXNjL2d1Y19wYXJhbWV0
ZXJzLmRhdAorKysgYi9zcmMvYmFja2VuZC91dGlscy9taXNjL2d1Y19wYXJhbWV0ZXJzLmRhdApA
QCAtMTg0OSw2ICsxODQ5LDE2IEBACiAgIGJvb3RfdmFsID0+ICdmYWxzZScsCiB9LAogCit7IG5h
bWUgPT4gJ2xvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQnLCB0eXBlID0+ICdpbnQnLCBjb250
ZXh0ID0+ICdQR0NfVVNFUlNFVCcsIGdyb3VwID0+ICdSRVNPVVJDRVNfTUVNJywKKyAgc2hvcnRf
ZGVzYyA9PiAnU2V0cyB0aGUgbWF4aW11bSB0b3RhbCBzaXplIG9mIHNwaWxsIGZpbGVzIGZvciBs
b2dpY2FsIGRlY29kaW5nLicsCisgIGxvbmdfZGVzYyA9PiAnTGltaXRzIHRoZSB0b3RhbCBkaXNr
IHNwYWNlIHVzZWQgYnkgc3BpbGwgZmlsZXMgcGVyIHJlcGxpY2F0aW9uIHNsb3QgZHVyaW5nIGxv
Z2ljYWwgZGVjb2RpbmcuIDAgbWVhbnMgbm8gbGltaXQuJywKKyAgZmxhZ3MgPT4gJ0dVQ19VTklU
X0tCJywKKyAgdmFyaWFibGUgPT4gJ2xvZ2ljYWxfZGVjb2Rpbmdfc3BpbGxfbGltaXQnLAorICBi
b290X3ZhbCA9PiAnMCcsCisgIG1pbiA9PiAnMCcsCisgIG1heCA9PiAnTUFYX0tJTE9CWVRFUycs
Cit9LAorCiB7IG5hbWUgPT4gJ2xvZ2ljYWxfZGVjb2Rpbmdfd29ya19tZW0nLCB0eXBlID0+ICdp
bnQnLCBjb250ZXh0ID0+ICdQR0NfVVNFUlNFVCcsIGdyb3VwID0+ICdSRVNPVVJDRVNfTUVNJywK
ICAgc2hvcnRfZGVzYyA9PiAnU2V0cyB0aGUgbWF4aW11bSBtZW1vcnkgdG8gYmUgdXNlZCBmb3Ig
bG9naWNhbCBkZWNvZGluZy4nLAogICBsb25nX2Rlc2MgPT4gJ1RoaXMgbXVjaCBtZW1vcnkgY2Fu
IGJlIHVzZWQgYnkgZWFjaCBpbnRlcm5hbCByZW9yZGVyIGJ1ZmZlciBiZWZvcmUgc3BpbGxpbmcg
dG8gZGlzay4nLApkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvdXRpbHMvbWlzYy9wb3N0Z3Jlc3Fs
LmNvbmYuc2FtcGxlIGIvc3JjL2JhY2tlbmQvdXRpbHMvbWlzYy9wb3N0Z3Jlc3FsLmNvbmYuc2Ft
cGxlCmluZGV4IGU0YWJlNmMwMDc3Li4wNGI0ZmI3MzczNyAxMDA2NDQKLS0tIGEvc3JjL2JhY2tl
bmQvdXRpbHMvbWlzYy9wb3N0Z3Jlc3FsLmNvbmYuc2FtcGxlCisrKyBiL3NyYy9iYWNrZW5kL3V0
aWxzL21pc2MvcG9zdGdyZXNxbC5jb25mLnNhbXBsZQpAQCAtMTQ5LDYgKzE0OSw4IEBACiAjbWFp
bnRlbmFuY2Vfd29ya19tZW0gPSA2NE1CICAgICAgICAgICAgIyBtaW4gNjRrQgogI2F1dG92YWN1
dW1fd29ya19tZW0gPSAtMSAgICAgICAgICAgICAgICMgbWluIDY0a0IsIG9yIC0xIHRvIHVzZSBt
YWludGVuYW5jZV93b3JrX21lbQogI2xvZ2ljYWxfZGVjb2Rpbmdfd29ya19tZW0gPSA2NE1CICAg
ICAgICMgbWluIDY0a0IKKyNsb2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0ID0gMCAgICAgICAj
IGxpbWl0cyBzcGlsbCBmaWxlIGRpc2sgdXNhZ2UgcGVyIHNsb3Q7CisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIyAwIG1lYW5zIG5vIGxpbWl0CiAjbWF4X3N0YWNrX2Rl
cHRoID0gMk1CICAgICAgICAgICAgICAgICAgIyBtaW4gMTAwa0IKICNzaGFyZWRfbWVtb3J5X3R5
cGUgPSBtbWFwICAgICAgICAgICAgICAjIHRoZSBkZWZhdWx0IGlzIHRoZSBmaXJzdCBvcHRpb24K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHN1cHBvcnRlZCBieSB0
aGUgb3BlcmF0aW5nIHN5c3RlbToKZGlmZiAtLWdpdCBhL3NyYy9pbmNsdWRlL3JlcGxpY2F0aW9u
L3Jlb3JkZXJidWZmZXIuaCBiL3NyYy9pbmNsdWRlL3JlcGxpY2F0aW9uL3Jlb3JkZXJidWZmZXIu
aAppbmRleCAyZDcxN2E5ZTE1Mi4uNjE1ODY0MzU3MWYgMTAwNjQ0Ci0tLSBhL3NyYy9pbmNsdWRl
L3JlcGxpY2F0aW9uL3Jlb3JkZXJidWZmZXIuaAorKysgYi9zcmMvaW5jbHVkZS9yZXBsaWNhdGlv
bi9yZW9yZGVyYnVmZmVyLmgKQEAgLTI1LDYgKzI1LDcgQEAKIAogLyogR1VDIHZhcmlhYmxlcyAq
LwogZXh0ZXJuIFBHRExMSU1QT1JUIGludCBsb2dpY2FsX2RlY29kaW5nX3dvcmtfbWVtOworZXh0
ZXJuIFBHRExMSU1QT1JUIGludCBsb2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0OwogZXh0ZXJu
IFBHRExMSU1QT1JUIGludCBkZWJ1Z19sb2dpY2FsX3JlcGxpY2F0aW9uX3N0cmVhbWluZzsKIAog
LyogcG9zc2libGUgdmFsdWVzIGZvciBkZWJ1Z19sb2dpY2FsX3JlcGxpY2F0aW9uX3N0cmVhbWlu
ZyAqLwpAQCAtNDYxLDYgKzQ2MiwxNCBAQCB0eXBlZGVmIHN0cnVjdCBSZW9yZGVyQnVmZmVyVFhO
CiAJLyogU2l6ZSBvZiB0b3AtdHJhbnNhY3Rpb24gaW5jbHVkaW5nIHN1Yi10cmFuc2FjdGlvbnMu
ICovCiAJU2l6ZQkJdG90YWxfc2l6ZTsKIAorCS8qCisJICogU2l6ZSBvZiB0aGlzIHRyYW5zYWN0
aW9uJ3MgY2hhbmdlcyBjdXJyZW50bHkgc2VyaWFsaXplZCB0byBkaXNrIChpbgorCSAqIGJ5dGVz
KS4gIFRyYWNrZWQgcGVyLXRyYW5zYWN0aW9uIHNvIHRoYXQgd2UgY2FuIGFjY3VyYXRlbHkgdXBk
YXRlIHRoZQorCSAqIFJlb3JkZXJCdWZmZXItbGV2ZWwgc3BpbGxCeXRlc09uRGlzayBjb3VudGVy
IHdoZW4gc3BpbGwgZmlsZXMgYXJlCisJICogY2xlYW5lZCB1cC4KKwkgKi8KKwlTaXplCQlzZXJp
YWxpemVkX3NpemU7CisKIAkvKgogCSAqIFByaXZhdGUgZGF0YSBwb2ludGVyIG9mIHRoZSBvdXRw
dXQgcGx1Z2luLgogCSAqLwpAQCAtNjg1LDYgKzY5NCwxNCBAQCBzdHJ1Y3QgUmVvcmRlckJ1ZmZl
cgogCWludDY0CQlzcGlsbENvdW50OwkJLyogc3BpbGwtdG8tZGlzayBpbnZvY2F0aW9uIGNvdW50
ZXIgKi8KIAlpbnQ2NAkJc3BpbGxCeXRlczsJCS8qIGFtb3VudCBvZiBkYXRhIHNwaWxsZWQgdG8g
ZGlzayAqLwogCisJLyoKKwkgKiBDdXJyZW50IHRvdGFsIHNpemUgb2Ygc3BpbGwgZmlsZXMgb24g
ZGlzayBmb3IgdGhpcyByZW9yZGVyIGJ1ZmZlciAoaW4KKwkgKiBieXRlcykuICBVbmxpa2Ugc3Bp
bGxCeXRlcyB3aGljaCBpcyBhIGN1bXVsYXRpdmUgc3RhdGlzdGljIGNvdW50ZXIsIHRoaXMKKwkg
KiB0cmFja3MgdGhlIGFjdHVhbCBvbi1kaXNrIGZvb3RwcmludCByaWdodCBub3cgYW5kIGlzIGRl
Y3JlbWVudGVkIHdoZW4KKwkgKiBzcGlsbCBmaWxlcyBhcmUgY2xlYW5lZCB1cC4gIFVzZWQgdG8g
ZW5mb3JjZSBsb2dpY2FsX2RlY29kaW5nX3NwaWxsX2xpbWl0LgorCSAqLworCVNpemUJCXNwaWxs
Qnl0ZXNPbkRpc2s7CisKIAkvKiBTdGF0aXN0aWNzIGFib3V0IHRyYW5zYWN0aW9ucyBzdHJlYW1l
ZCB0byB0aGUgZGVjb2Rpbmcgb3V0cHV0IHBsdWdpbiAqLwogCWludDY0CQlzdHJlYW1UeG5zOwkJ
LyogbnVtYmVyIG9mIHRyYW5zYWN0aW9ucyBzdHJlYW1lZCAqLwogCWludDY0CQlzdHJlYW1Db3Vu
dDsJLyogc3RyZWFtaW5nIGludm9jYXRpb24gY291bnRlciAqLwpAQCAtNzgyLDUgKzc5OSw2IEBA
IGV4dGVybiB1aW50MzIgUmVvcmRlckJ1ZmZlckdldEludmFsaWRhdGlvbnMoUmVvcmRlckJ1ZmZl
ciAqcmIsCiAJCQkJCQkJCQkJCVNoYXJlZEludmFsaWRhdGlvbk1lc3NhZ2UgKiptc2dzKTsKIAog
ZXh0ZXJuIHZvaWQgU3RhcnR1cFJlb3JkZXJCdWZmZXIodm9pZCk7CitleHRlcm4gdm9pZCBSZW9y
ZGVyQnVmZmVyQ2xlYW51cFNlcmlhbGl6ZWRUWE5zKGNvbnN0IGNoYXIgKnNsb3RuYW1lKTsKIAog
I2VuZGlmCi0tIAoyLjQzLjcKCg==
--000000000000ba7f92064e909d2f--