<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The similar failure happens in neutron-fwaas. This blocks several patches in neutron-fwaas including policy-in-code support.<div><a href="https://bugs.launchpad.net/neutron/+bug/1811506">https://bugs.launchpad.net/neutron/+bug/1811506</a></div><div><br></div><div>Most failures are fixed by applying Ben's neutron fix <a href="https://review.openstack.org/#/c/629335/">https://review.openstack.org/#/c/629335/</a> [1],</div><div>but we still have one failure in neutron_fwaas.tests.functional.privileged.test_utils.InNamespaceTest.test_in_namespace [2].</div><div>This failure is caused by oslo.privsep 1.31.0 too. This does not happen with 1.30.1.</div><div>Any help would be appreciated.<br></div><div><br></div><div>[1] neutron-fwaas change <a href="https://review.openstack.org/#/c/630451/">https://review.openstack.org/#/c/630451/</a></div><div>[2] <a href="http://logs.openstack.org/51/630451/2/check/legacy-neutron-fwaas-dsvm-functional/05b9131/logs/testr_results.html.gz">http://logs.openstack.org/51/630451/2/check/legacy-neutron-fwaas-dsvm-functional/05b9131/logs/testr_results.html.gz</a></div><div><br></div><div>-- </div><div>Akihiro Motoki (irc: amotoki)<br><div><br></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">2019年1月9日(水) 9:32 Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think I've got it. At least in my local tests, the handle pointer <br>
being passed from C -> Python -> C was getting truncated at the Python <br>
step because we didn't properly define the type. If the address assigned <br>
was larger than would fit in a standard int then we passed what amounted <br>
to a bogus pointer back to the C code, which caused the segfault.<br>
<br>
I have no idea why privsep threading would have exposed this, other than <br>
maybe running in threads affected the address space somehow?<br>
<br>
In any case, <a href="https://review.openstack.org/629335" rel="noreferrer" target="_blank">https://review.openstack.org/629335</a> has got these <br>
functional tests working for me locally in oslo.privsep 1.31.0. It would <br>
be great if somebody could try them out and verify that I didn't just <br>
find a solution that somehow only works on my system. :-)<br>
<br>
-Ben<br>
<br>
On 1/8/19 4:30 PM, Ben Nemec wrote:<br>
> <br>
> <br>
> On 1/8/19 2:22 PM, Slawomir Kaplonski wrote:<br>
>> Hi Ben,<br>
>><br>
>> I was also looking at it today. I’m totally not an C and Oslo.privsep <br>
>> expert but I think that there is some new process spawned here.<br>
>> I put pdb before line <br>
>> <a href="https://github.com/openstack/neutron/blob/master/neutron/privileged/agent/linux/netlink_lib.py#L191" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/privileged/agent/linux/netlink_lib.py#L191</a> <br>
>> where this issue happen. Then, with "ps aux” I saw:<br>
>><br>
>> vagrant@fullstack-ubuntu ~ $ ps aux | grep privsep<br>
>> root     18368  0.1  0.5 185752 33544 pts/1    Sl+  13:24   0:00 <br>
>> /opt/stack/neutron/.tox/dsvm-functional/bin/python <br>
>> /opt/stack/neutron/.tox/dsvm-functional/bin/privsep-helper <br>
>> --config-file neutron/tests/etc/neutron.conf --privsep_context <br>
>> neutron.privileged.default --privsep_sock_path <br>
>> /tmp/tmpG5iqb9/tmp1dMGq0/privsep.sock<br>
>> vagrant  18555  0.0  0.0  14512  1092 pts/2    S+   13:25   0:00 grep <br>
>> --color=auto privsep<br>
>><br>
>> But then when I continue run test, and it segfaulted, in journal log I <br>
>> have:<br>
>><br>
>> Jan 08 13:25:29 fullstack-ubuntu kernel: privsep-helper[18369] <br>
>> segfault at 140043e8 ip 00007f8e1800ef32 sp 00007f8e18a63320 error 4 <br>
>> in libnetfilter_conntrack.so.3.5.0[7f8e18009000+1a000]<br>
>><br>
>> Please check pics of those processes. First one (when test was <br>
>> „paused” with pdb) has 18368 and later segfault has 18369.<br>
> <br>
> privsep-helper does fork, so I _think_ that's normal.<br>
> <br>
> <a href="https://github.com/openstack/oslo.privsep/blob/ecb1870c29b760f09fb933fc8ebb3eac29ffd03e/oslo_privsep/daemon.py#L539" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.privsep/blob/ecb1870c29b760f09fb933fc8ebb3eac29ffd03e/oslo_privsep/daemon.py#L539</a> <br>
> <br>
> <br>
>><br>
>> I don’t know if You saw my today’s comment in launchpad. I was trying <br>
>> to change method used to start PrivsepDaemon from Method.ROOTWRAP to <br>
>> Method.FORK (in <br>
>> <a href="https://github.com/openstack/oslo.privsep/blob/master/oslo_privsep/priv_context.py#L218" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.privsep/blob/master/oslo_privsep/priv_context.py#L218</a>) <br>
>> and run test as root, then tests were passed.<br>
> <br>
> Yeah, I saw that, but I don't understand it. :-/<br>
> <br>
> The daemon should end up running with the same capabilities in either <br>
> case. By the time it starts making the C calls the environment should be <br>
> identical, regardless of which method was used to start the process.<br>
> <br>
>><br>
>> —<br>
>> Slawek Kaplonski<br>
>> Senior software engineer<br>
>> Red Hat<br>
>><br>
>>> Wiadomość napisana przez Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> w dniu <br>
>>> 08.01.2019, o godz. 20:04:<br>
>>><br>
>>> Further update: I dusted off my gdb skills and attached it to the <br>
>>> privsep process to try to get more details about exactly what is <br>
>>> crashing. It looks like the segfault happens on this line:<br>
>>><br>
>>> <a href="https://git.netfilter.org/libnetfilter_conntrack/tree/src/conntrack/api.c#n239" rel="noreferrer" target="_blank">https://git.netfilter.org/libnetfilter_conntrack/tree/src/conntrack/api.c#n239</a> <br>
>>><br>
>>><br>
>>> which is<br>
>>><br>
>>> h->cb = cb;<br>
>>><br>
>>> h being the conntrack handle and cb being the callback function.<br>
>>><br>
>>> This makes me think the problem isn't the callback itself (even if we <br>
>>> assigned a bogus pointer, which we didn't, it shouldn't cause a <br>
>>> segfault unless you try to dereference it) but in the handle we pass <br>
>>> in. Trying to look at h->cb results in:<br>
>>><br>
>>> (gdb) print h->cb<br>
>>> Cannot access memory at address 0x800f228<br>
>>><br>
>>> Interestingly, h itself is fine:<br>
>>><br>
>>> (gdb) print h<br>
>>> $3 = (struct nfct_handle *) 0x800f1e0<br>
>>><br>
>>> It doesn't _look_ to me like the handle should be crossing any thread <br>
>>> boundaries or anything, so I'm not sure why it would be a problem. It <br>
>>> gets created in the same privileged function that ultimately <br>
>>> registers the callback: <br>
>>> <a href="https://github.com/openstack/neutron/blob/aa8a6ea848aae6882abb631b7089836dee8f4008/neutron/privileged/agent/linux/netlink_lib.py#L246" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/aa8a6ea848aae6882abb631b7089836dee8f4008/neutron/privileged/agent/linux/netlink_lib.py#L246</a> <br>
>>><br>
>>><br>
>>> So still not sure what's going on, but I thought I'd share what I've <br>
>>> found before I stop to eat something.<br>
>>><br>
>>> -Ben<br>
>>><br>
>>> On 1/7/19 12:11 PM, Ben Nemec wrote:<br>
>>>> Renamed the thread to be more descriptive.<br>
>>>> Just to update the list on this, it looks like the problem is a <br>
>>>> segfault when the netlink_lib module makes a C call. Digging into <br>
>>>> that code a bit, it appears there is a callback being used[1]. I've <br>
>>>> seen some comments that when you use a callback with a Python <br>
>>>> thread, the thread needs to be registered somehow, but this is all <br>
>>>> uncharted territory for me. Suggestions gratefully accepted. :-)<br>
>>>> 1: <br>
>>>> <a href="https://github.com/openstack/neutron/blob/master/neutron/privileged/agent/linux/netlink_lib.py#L136" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/privileged/agent/linux/netlink_lib.py#L136</a> <br>
>>>> On 1/4/19 7:28 AM, Slawomir Kaplonski wrote:<br>
>>>>> Hi,<br>
>>>>><br>
>>>>> I just found that functional tests in Neutron are failing since <br>
>>>>> today or maybe yesterday. See [1]<br>
>>>>> I was able to reproduce it locally and it looks that it happens <br>
>>>>> with oslo.privsep==1.31. With oslo.privsep==1.30.1 tests are fine.<br>
>>>>><br>
>>>>> [1] <a href="https://bugs.launchpad.net/neutron/+bug/1810518" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1810518</a><br>
>>>>><br>
>>>>> —<br>
>>>>> Slawek Kaplonski<br>
>>>>> Senior software engineer<br>
>>>>> Red Hat<br>
>>>>><br>
>><br>
> <br>
<br>
</blockquote></div>