MIME-Version: 1.0
References: 
 <CAHg+QDfDwcM4=DSiAV6Ly89YQ5EcMhzO1-9x=mGG1WJzODcAig@mail.gmail.com>
 <CAExHW5s27tfBqn7ZAtFNR3y7r+LxWCogvkZkyXNi+FH0AtawJg@mail.gmail.com>
In-Reply-To: 
 <CAExHW5s27tfBqn7ZAtFNR3y7r+LxWCogvkZkyXNi+FH0AtawJg@mail.gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Thu, 30 Apr 2026 12:01:04 -0700
Message-ID: 
 <CAHg+QDe8JU+ERqA2xwjrg_ZptvH_v0T6PS9_P_ZgyYzD5h-Grw@mail.gmail.com>
Subject: Re: Limit GRAPH_TABLE path combinations to prevent memory exhaustion
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000bded070650b2165f"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHg%2BQDe8JU%2BERqA2xwjrg_ZptvH_v0T6PS9_P_ZgyYzD5h-Grw%40mail.gmail.com>
Precedence: bulk

--000000000000bded070650b2165f
Content-Type: multipart/alternative; boundary="000000000000bded060650b2165d"

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

Hi,

On Thu, Apr 30, 2026 at 12:16=E2=80=AFAM Ashutosh Bapat <
ashutosh.bapat.oss@gmail.com> wrote:

> On Wed, Apr 29, 2026 at 10:05=E2=80=AFPM SATYANARAYANA NARLAPURAM
> <satyanarlapuram@gmail.com> wrote:
> >
> > Hi hackers,
> >
> > generate_queries_for_path_pattern_recurse() enumerates all path
> > combinations by recursing over the Cartesian product of matching elemen=
ts
> > per pattern position.  Without IS label filters, each position matches
> > ALL tables of that kind, leading to N^K combinations (N tables, K
> > pattern positions).  Each combination allocates a Query node via palloc
> > causing unbounded memory growth.
> >
> > A 8-table graph with a -element pattern reaches 81.3 GB RES in a few
> seconds
> > before I cancel the query. Tests in the patch (those were failed) can
> reproduce the problem
> > without the fix included in the patch.
> >
> > top - 15:04:19 up 43 days, 19:18,  5 users,  load average: 0.43, 0.19,
> 0.08
> > Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> > %Cpu(s):  0.9 us,  0.8 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,
> 0.0 st
> > MiB Mem : 515766.2 total, 248412.7 free, 234847.7 used,  48014.7
> buff/cache
> > MiB Swap:      0.0 total,      0.0 free,      0.0 used. 280918.6 avail
> Mem
> >
> >     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
> COMMAND
> >  649642 azureus+  20   0  212.2g  81.3g  33948 R 100.0  16.1   0:41.20
> postgres
> >
>
> I tried to reproduce this problem on my laptop with queries included
> in the patch. For me all the queries finished. First within 4 ms,
> second within 133 ms and the third in 12ms. Did you try with more
> edges or more rows in the tables?
>
> >
> > As a POC I added a pre-computation check that calculates the total numb=
er
> > of path combinations before entering the
> generate_queries_for_path_pattern_recurse.
> > If the product exceeds MAX_GRAPH_TABLE_PATH_COMBINATIONS (set to 10,000=
),
> > the rewriter reports ERRCODE_PROGRAM_LIMIT_EXCEEDED with a hint
> suggesting
> > IS label filters to reduce the search space. The limit of 10,000 is
> somewhat arbitrary
> > but conservative. It caps memory at roughly 5 MB of Query nodes.
> > Patterns that would exceed the limit without labels can always be made
> to succeed
> > by adding IS expressions to pin specific positions to fewer tables.
> > Alternatively, we can consider adding a GUC to control the limit but
> appears
> > to be an overkill. Thoughts?
>
> I understand the problem and can understand the pain. Somebody who is
> writing a query like ()-()-()-()-() ... should know that every pattern
> that doesn't have a label will be matched against each vertex/edge.
> Our documentation makes it explicit [1] "The above patterns would
> match any vertex, or any two vertices connected by any edge ... ". But
> if they are really interested in matching every vertex or edge they
> don't have any other choice. Using restrictive label expressions would
> lead to wrong or incomplete results. If they can use label expressions
> they should do so anyway, otherwise they will end up with incorrect
> results. To me it seems like somebody who is writing such a pattern
> without providing enough resources is writing a bad query.
>
> We have other places where queries can consume large amounts of memory
> during planning or execution. Simply take the SQL query equivalent to
> the above pattern. We do not have a way to prohibit such queries as
> far as I know. I understand that SQL/PGQ makes it easy to write such
> queries by hand. But that seems to be abusing a powerful tool.
>
> Another example is joining partitioned tables with thousands of
> partitions. We have a GUC which enables or disables partitionwise join
> but there is no GUC to limit the number of tables or partitions being
> joined.
>
> I think we can document that such a pattern can result in large
> queries which may consume memory.
>
> Said that 81.3 GB looks unreasonably large for
> generate_queries_for_path_pattern_recurse() alone. I guess a large
> portion of it comes from planning and execution. How many rows did
> those tables had? Which phase of query execution consumed that much
> memory? Do you have a dump of memory contexts when it reaches that
> limit?
>

I am worried about a potential DOS by a low privileged user or an
accidental query
causing OOM.
Please find the attached patch that added traces to print the memory
context.
Patch also includes CFI to cancel the query which we didn't have earlier.

You can see traces like below once you run the repro:

2026-04-30 18:43:51.268 UTC [927121] LOG:  GRAPH_TABLE: before
generate_queries_for_path_pattern_recurse, current memory context
"MessageContext": 39392903168 bytes total
2026-04-30 18:43:51.268 UTC [927121] STATEMENT:  SELECT count(*) FROM
GRAPH_TABLE (g5 MATCH (a)-[e1]->(b)-[e2]->(c)-[e3]->(d)-[e4]->(e) COLUMNS (
a.id AS aid));
2026-04-30 18:43:51.268 UTC [927121] ERROR:  canceling statement due to
user request
2026-04-30 18:43:51.268 UTC [927121] STATEMENT:  SELECT count(*) FROM
GRAPH_TABLE (g5 MATCH (a)-[e1]->(b)-[e2]->(c)-[e3]->(d)-[e4]->(e) COLUMNS (
a.id AS aid));

Repro:
CREATE temp TABLE v1 (id int PRIMARY KEY, val int);
CREATE temp TABLE v2 (id int PRIMARY KEY, val int);
CREATE temp TABLE v3 (id int PRIMARY KEY, val int);
CREATE temp TABLE v4 (id int PRIMARY KEY, val int);
CREATE temp TABLE v5 (id int PRIMARY KEY, val int);
CREATE temp TABLE v6 (id int PRIMARY KEY, val int);
CREATE temp TABLE v7 (id int PRIMARY KEY, val int);
CREATE temp TABLE v8 (id int PRIMARY KEY, val int);
CREATE temp TABLE e1 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e2 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e3 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e4 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e5 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e6 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e7 (id int PRIMARY KEY, src int, dest int);
CREATE temp TABLE e8 (id int PRIMARY KEY, src int, dest int);
CREATE PROPERTY GRAPH g5
    VERTEX TABLES (
        v1 LABEL vl PROPERTIES (id, val) LABEL vl2 PROPERTIES (id, val),
        v2 LABEL vl PROPERTIES (id, val),
        v3 LABEL vl PROPERTIES (id, val),
        v4 LABEL vl PROPERTIES (id, val),
        v5 LABEL vl PROPERTIES (id, val),
        v6 LABEL vl PROPERTIES (id, val),
        v7 LABEL vl PROPERTIES (id, val),
        v8 LABEL vl PROPERTIES (id, val)
    )
    EDGE TABLES (
        e1 SOURCE KEY (src) REFERENCES v1 (id) DESTINATION KEY (dest)
REFERENCES v2 (id) LABEL el PROPERTIES (id),
        e2 SOURCE KEY (src) REFERENCES v2 (id) DESTINATION KEY (dest)
REFERENCES v3 (id) LABEL el PROPERTIES (id),
        e3 SOURCE KEY (src) REFERENCES v3 (id) DESTINATION KEY (dest)
REFERENCES v4 (id) LABEL el PROPERTIES (id),
        e4 SOURCE KEY (src) REFERENCES v4 (id) DESTINATION KEY (dest)
REFERENCES v5 (id) LABEL el PROPERTIES (id),
        e5 SOURCE KEY (src) REFERENCES v5 (id) DESTINATION KEY (dest)
REFERENCES v6 (id) LABEL el PROPERTIES (id),
        e6 SOURCE KEY (src) REFERENCES v6 (id) DESTINATION KEY (dest)
REFERENCES v7 (id) LABEL el PROPERTIES (id),
        e7 SOURCE KEY (src) REFERENCES v7 (id) DESTINATION KEY (dest)
REFERENCES v8 (id) LABEL el PROPERTIES (id),
        e8 SOURCE KEY (src) REFERENCES v8 (id) DESTINATION KEY (dest)
REFERENCES v1 (id) LABEL el PROPERTIES (id)
    );

SELECT count(*) FROM GRAPH_TABLE (g5 MATCH
(a)-[e1]->(b)-[e2]->(c)-[e3]->(d)-[e4]->(e) COLUMNS (a.id AS aid));

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 30, =
2026 at 12:16=E2=80=AFAM Ashutosh Bapat &lt;<a href=3D"mailto:ashutosh.bapa=
t.oss@gmail.com">ashutosh.bapat.oss@gmail.com</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 29, 2026 at 10:05=
=E2=80=AFPM SATYANARAYANA NARLAPURAM<br>
&lt;<a href=3D"mailto:satyanarlapuram@gmail.com" target=3D"_blank">satyanar=
lapuram@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi hackers,<br>
&gt;<br>
&gt; generate_queries_for_path_pattern_recurse() enumerates all path<br>
&gt; combinations by recursing over the Cartesian product of matching eleme=
nts<br>
&gt; per pattern position.=C2=A0 Without IS label filters, each position ma=
tches<br>
&gt; ALL tables of that kind, leading to N^K combinations (N tables, K<br>
&gt; pattern positions).=C2=A0 Each combination allocates a Query node via =
palloc<br>
&gt; causing unbounded memory growth.<br>
&gt;<br>
&gt; A 8-table graph with a -element pattern reaches 81.3 GB RES in a few s=
econds<br>
&gt; before I cancel the query. Tests in the patch (those were failed) can =
reproduce the problem<br>
&gt; without the fix included in the patch.<br>
&gt;<br>
&gt; top - 15:04:19 up 43 days, 19:18,=C2=A0 5 users,=C2=A0 load average: 0=
.43, 0.19, 0.08<br>
&gt; Tasks:=C2=A0 =C2=A01 total,=C2=A0 =C2=A01 running,=C2=A0 =C2=A00 sleep=
ing,=C2=A0 =C2=A00 stopped,=C2=A0 =C2=A00 zombie<br>
&gt; %Cpu(s):=C2=A0 0.9 us,=C2=A0 0.8 sy,=C2=A0 0.0 ni, 98.3 id,=C2=A0 0.0 =
wa,=C2=A0 0.0 hi,=C2=A0 0.0 si,=C2=A0 0.0 st<br>
&gt; MiB Mem : 515766.2 total, 248412.7 free, 234847.7 used,=C2=A0 48014.7 =
buff/cache<br>
&gt; MiB Swap:=C2=A0 =C2=A0 =C2=A0 0.0 total,=C2=A0 =C2=A0 =C2=A0 0.0 free,=
=C2=A0 =C2=A0 =C2=A0 0.0 used. 280918.6 avail Mem<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0PID USER=C2=A0 =C2=A0 =C2=A0 PR=C2=A0 NI=C2=A0 =C2=
=A0 VIRT=C2=A0 =C2=A0 RES=C2=A0 =C2=A0 SHR S=C2=A0 %CPU=C2=A0 %MEM=C2=A0 =
=C2=A0 =C2=A0TIME+ COMMAND<br>
&gt;=C2=A0 649642 azureus+=C2=A0 20=C2=A0 =C2=A00=C2=A0 212.2g=C2=A0 81.3g=
=C2=A0 33948 R 100.0=C2=A0 16.1=C2=A0 =C2=A00:41.20 postgres<br>
&gt;<br>
<br>
I tried to reproduce this problem on my laptop with queries included<br>
in the patch. For me all the queries finished. First within 4 ms,<br>
second within 133 ms and the third in 12ms. Did you try with more<br>
edges or more rows in the tables?<br>
<br>
&gt;<br>
&gt; As a POC I added a pre-computation check that calculates the total num=
ber<br>
&gt; of path combinations before entering the generate_queries_for_path_pat=
tern_recurse.<br>
&gt; If the product exceeds MAX_GRAPH_TABLE_PATH_COMBINATIONS (set to 10,00=
0),<br>
&gt; the rewriter reports ERRCODE_PROGRAM_LIMIT_EXCEEDED with a hint sugges=
ting<br>
&gt; IS label filters to reduce the search space. The limit of 10,000 is so=
mewhat arbitrary<br>
&gt; but conservative. It caps memory at roughly 5 MB of Query nodes.<br>
&gt; Patterns that would exceed the limit without labels can always be made=
 to succeed<br>
&gt; by adding IS expressions to pin specific positions to fewer tables.<br=
>
&gt; Alternatively, we can consider adding a GUC to control the limit but a=
ppears<br>
&gt; to be an overkill. Thoughts?<br>
<br>
I understand the problem and can understand the pain. Somebody who is<br>
writing a query like ()-()-()-()-() ... should know that every pattern<br>
that doesn&#39;t have a label will be matched against each vertex/edge.<br>
Our documentation makes it explicit [1] &quot;The above patterns would<br>
match any vertex, or any two vertices connected by any edge ... &quot;. But=
<br>
if they are really interested in matching every vertex or edge they<br>
don&#39;t have any other choice. Using restrictive label expressions would<=
br>
lead to wrong or incomplete results. If they can use label expressions<br>
they should do so anyway, otherwise they will end up with incorrect<br>
results. To me it seems like somebody who is writing such a pattern<br>
without providing enough resources is writing a bad query.<br>
<br>
We have other places where queries can consume large amounts of memory<br>
during planning or execution. Simply take the SQL query equivalent to<br>
the above pattern. We do not have a way to prohibit such queries as<br>
far as I know. I understand that SQL/PGQ makes it easy to write such<br>
queries by hand. But that seems to be abusing a powerful tool.<br>
<br>
Another example is joining partitioned tables with thousands of<br>
partitions. We have a GUC which enables or disables partitionwise join<br>
but there is no GUC to limit the number of tables or partitions being<br>
joined.<br>
<br>
I think we can document that such a pattern can result in large<br>
queries which may consume memory.<br>
<br>
Said that 81.3 GB looks unreasonably large for<br>
generate_queries_for_path_pattern_recurse() alone. I guess a large<br>
portion of it comes from planning and execution. How many rows did<br>
those tables had? Which phase of query execution consumed that much<br>
memory? Do you have a dump of memory contexts when it reaches that<br>
limit?<br></blockquote><div><br></div><div>I am worried about a potential D=
OS by a low privileged user or an accidental query</div><div>causing OOM.=
=C2=A0</div><div>Please find the attached patch that added traces to print =
the memory context.</div><div>Patch also includes CFI to cancel the query w=
hich we didn&#39;t have earlier.</div><div><br></div><div>You can see trace=
s like below once you run the repro:</div><div><br></div><div>2026-04-30 18=
:43:51.268 UTC [927121] LOG: =C2=A0GRAPH_TABLE: before generate_queries_for=
_path_pattern_recurse, current memory context &quot;MessageContext&quot;: 3=
9392903168 bytes total<br>2026-04-30 18:43:51.268 UTC [927121] STATEMENT: =
=C2=A0SELECT count(*) FROM GRAPH_TABLE (g5 MATCH (a)-[e1]-&gt;(b)-[e2]-&gt;=
(c)-[e3]-&gt;(d)-[e4]-&gt;(e) COLUMNS (<a href=3D"http://a.id">a.id</a> AS =
aid));<br>2026-04-30 18:43:51.268 UTC [927121] ERROR: =C2=A0canceling state=
ment due to user request<br>2026-04-30 18:43:51.268 UTC [927121] STATEMENT:=
 =C2=A0SELECT count(*) FROM GRAPH_TABLE (g5 MATCH (a)-[e1]-&gt;(b)-[e2]-&gt=
;(c)-[e3]-&gt;(d)-[e4]-&gt;(e) COLUMNS (<a href=3D"http://a.id">a.id</a> AS=
 aid));</div><div>=C2=A0</div><div>Repro:</div><div>CREATE temp TABLE v1 (i=
d int PRIMARY KEY, val int);<br>CREATE temp TABLE v2 (id int PRIMARY KEY, v=
al int);<br>CREATE temp TABLE v3 (id int PRIMARY KEY, val int);<br>CREATE t=
emp TABLE v4 (id int PRIMARY KEY, val int);<br>CREATE temp TABLE v5 (id int=
 PRIMARY KEY, val int);<br>CREATE temp TABLE v6 (id int PRIMARY KEY, val in=
t);<br>CREATE temp TABLE v7 (id int PRIMARY KEY, val int);<br>CREATE temp T=
ABLE v8 (id int PRIMARY KEY, val int);<br>CREATE temp TABLE e1 (id int PRIM=
ARY KEY, src int, dest int);<br>CREATE temp TABLE e2 (id int PRIMARY KEY, s=
rc int, dest int);<br>CREATE temp TABLE e3 (id int PRIMARY KEY, src int, de=
st int);<br>CREATE temp TABLE e4 (id int PRIMARY KEY, src int, dest int);<b=
r>CREATE temp TABLE e5 (id int PRIMARY KEY, src int, dest int);<br>CREATE t=
emp TABLE e6 (id int PRIMARY KEY, src int, dest int);<br>CREATE temp TABLE =
e7 (id int PRIMARY KEY, src int, dest int);<br>CREATE temp TABLE e8 (id int=
 PRIMARY KEY, src int, dest int);<br>CREATE PROPERTY GRAPH g5<br>=C2=A0 =C2=
=A0 VERTEX TABLES (<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v1 LABEL vl PROPERTIES (=
id, val) LABEL vl2 PROPERTIES (id, val),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v2 =
LABEL vl PROPERTIES (id, val),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v3 LABEL vl P=
ROPERTIES (id, val),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v4 LABEL vl PROPERTIES =
(id, val),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v5 LABEL vl PROPERTIES (id, val),=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6 LABEL vl PROPERTIES (id, val),<br>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 v7 LABEL vl PROPERTIES (id, val),<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 v8 LABEL vl PROPERTIES (id, val)<br>=C2=A0 =C2=A0 )<br>=C2=A0=
 =C2=A0 EDGE TABLES (<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 e1 SOURCE KEY (src) RE=
FERENCES v1 (id) DESTINATION KEY (dest) REFERENCES v2 (id) LABEL el PROPERT=
IES (id),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 e2 SOURCE KEY (src) REFERENCES v2 =
(id) DESTINATION KEY (dest) REFERENCES v3 (id) LABEL el PROPERTIES (id),<br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 e3 SOURCE KEY (src) REFERENCES v3 (id) DESTINA=
TION KEY (dest) REFERENCES v4 (id) LABEL el PROPERTIES (id),<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 e4 SOURCE KEY (src) REFERENCES v4 (id) DESTINATION KEY (d=
est) REFERENCES v5 (id) LABEL el PROPERTIES (id),<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 e5 SOURCE KEY (src) REFERENCES v5 (id) DESTINATION KEY (dest) REFERE=
NCES v6 (id) LABEL el PROPERTIES (id),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 e6 SO=
URCE KEY (src) REFERENCES v6 (id) DESTINATION KEY (dest) REFERENCES v7 (id)=
 LABEL el PROPERTIES (id),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 e7 SOURCE KEY (sr=
c) REFERENCES v7 (id) DESTINATION KEY (dest) REFERENCES v8 (id) LABEL el PR=
OPERTIES (id),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 e8 SOURCE KEY (src) REFERENCE=
S v8 (id) DESTINATION KEY (dest) REFERENCES v1 (id) LABEL el PROPERTIES (id=
)<br>=C2=A0 =C2=A0 );<br></div><div><br></div><div>SELECT count(*) FROM GRA=
PH_TABLE (g5 MATCH (a)-[e1]-&gt;(b)-[e2]-&gt;(c)-[e3]-&gt;(d)-[e4]-&gt;(e) =
COLUMNS (<a href=3D"http://a.id">a.id</a> AS aid));</div></div></div>

--000000000000bded060650b2165d--

--000000000000bded070650b2165f
Content-Type: application/octet-stream;
	name="0001-Add-memory-context-debugging-for-GRAPH_TABLE-path-ge.patch"
Content-Disposition: attachment;
	filename="0001-Add-memory-context-debugging-for-GRAPH_TABLE-path-ge.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_moluhkju0>
X-Attachment-Id: f_moluhkju0

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3Jld3JpdGUvcmV3cml0ZUdyYXBoVGFibGUuYyBiL3Ny
Yy9iYWNrZW5kL3Jld3JpdGUvcmV3cml0ZUdyYXBoVGFibGUuYwppbmRleCA2ODY3ZGU2ZC4uOWIy
NWZlNmYgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3Jld3JpdGUvcmV3cml0ZUdyYXBoVGFibGUu
YworKysgYi9zcmMvYmFja2VuZC9yZXdyaXRlL3Jld3JpdGVHcmFwaFRhYmxlLmMKQEAgLTQyLDYg
KzQyLDcgQEAKICNpbmNsdWRlICJ1dGlscy9idWlsdGlucy5oIgogI2luY2x1ZGUgInV0aWxzL2Zt
Z3JvaWRzLmgiCiAjaW5jbHVkZSAidXRpbHMvbHN5c2NhY2hlLmgiCisjaW5jbHVkZSAidXRpbHMv
bWVtdXRpbHMuaCIKICNpbmNsdWRlICJ1dGlscy9ydWxldXRpbHMuaCIKICNpbmNsdWRlICJ1dGls
cy9zeXNjYWNoZS5oIgogCkBAIC0zNDIsNyArMzQzLDYgQEAgZ2VuZXJhdGVfcXVlcmllc19mb3Jf
cGF0aF9wYXR0ZXJuKFJhbmdlVGJsRW50cnkgKnJ0ZSwgTGlzdCAqcGF0aF9wYXR0ZXJuKQogCWZv
cmVhY2hfcHRyKHN0cnVjdCBwYXRoX2ZhY3RvciwgcGYsIHBhdGhfZmFjdG9ycykKIAkJcGF0aF9l
bGVtX2xpc3RzID0gbGFwcGVuZChwYXRoX2VsZW1fbGlzdHMsCiAJCQkJCQkJCSAgZ2V0X3BhdGhf
ZWxlbWVudHNfZm9yX3BhdGhfZmFjdG9yKHJ0ZS0+cmVsaWQsIHBmKSk7Ci0KIAlwYXRocXVlcmll
cyA9IGdlbmVyYXRlX3F1ZXJpZXNfZm9yX3BhdGhfcGF0dGVybl9yZWN1cnNlKHJ0ZSwgcGF0aHF1
ZXJpZXMsCiAJCQkJCQkJCQkJCQkJCQlOSUwsIHBhdGhfZWxlbV9saXN0cywgMCk7CiAJaWYgKCFw
YXRocXVlcmllcykKQEAgLTM2Nyw2ICszNjcsOCBAQCBnZW5lcmF0ZV9xdWVyaWVzX2Zvcl9wYXRo
X3BhdHRlcm5fcmVjdXJzZShSYW5nZVRibEVudHJ5ICpydGUsIExpc3QgKnBhdGhxdWVyaWVzLAog
CiAJZm9yZWFjaF9wdHIoc3RydWN0IHBhdGhfZWxlbWVudCwgcGUsIHBhdGhfZWxlbXMpCiAJewor
CQlDSEVDS19GT1JfSU5URVJSVVBUUygpOworCiAJCS8qIFVwZGF0ZSBjdXJyZW50IHBhdGggYmVp
bmcgYnVpbHQgd2l0aCBjdXJyZW50IGVsZW1lbnQuICovCiAJCWN1cl9wYXRoID0gbGFwcGVuZChj
dXJfcGF0aCwgcGUpOwogCkBAIC0zODMsMTAgKzM4NSwxOSBAQCBnZW5lcmF0ZV9xdWVyaWVzX2Zv
cl9wYXRoX3BhdHRlcm5fcmVjdXJzZShSYW5nZVRibEVudHJ5ICpydGUsIExpc3QgKnBhdGhxdWVy
aWVzLAogCQkJCXBhdGhxdWVyaWVzID0gbGFwcGVuZChwYXRocXVlcmllcywgcGF0aHF1ZXJ5KTsK
IAkJfQogCQllbHNlCisJCXsKKwkJCS8qIER1bXAgbWVtb3J5IGNvbnRleHQgYmVmb3JlIHJlY3Vy
c2l2ZSBwYXRoIHF1ZXJ5IGdlbmVyYXRpb24gKi8KKwkJCWVyZXBvcnQoTE9HLAorCQkJCQkoZXJy
bXNnKCJHUkFQSF9UQUJMRTogYmVmb3JlIGdlbmVyYXRlX3F1ZXJpZXNfZm9yX3BhdGhfcGF0dGVy
bl9yZWN1cnNlLCAiCisJCQkJCQkJImN1cnJlbnQgbWVtb3J5IGNvbnRleHQgXCIlc1wiOiAlenUg
Ynl0ZXMgdG90YWwiLAorCQkJCQkJCUN1cnJlbnRNZW1vcnlDb250ZXh0LT5uYW1lLAorCQkJCQkJ
CU1lbW9yeUNvbnRleHRNZW1BbGxvY2F0ZWQoQ3VycmVudE1lbW9yeUNvbnRleHQsIHRydWUpKSkp
OwogCQkJcGF0aHF1ZXJpZXMgPSBnZW5lcmF0ZV9xdWVyaWVzX2Zvcl9wYXRoX3BhdHRlcm5fcmVj
dXJzZShydGUsIHBhdGhxdWVyaWVzLAogCQkJCQkJCQkJCQkJCQkJCQljdXJfcGF0aCwKIAkJCQkJ
CQkJCQkJCQkJCQkJcGF0aF9lbGVtX2xpc3RzLAogCQkJCQkJCQkJCQkJCQkJCQllbGVtcG9zICsg
MSk7CisJCX0KKwogCQkvKiBNYWtlIHdheSBmb3IgdGhlIG5leHQgZWxlbWVudCBhdCB0aGUgc2Ft
ZSBwb3NpdGlvbi4gKi8KIAkJY3VyX3BhdGggPSBsaXN0X2RlbGV0ZV9sYXN0KGN1cl9wYXRoKTsK
IAl9Cg==
--000000000000bded070650b2165f--