netdev - Re: [PATCH 00/14] Modify action API for implementing lockless actions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vbfmuwwor72.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
Date:   Fri, 18 May 2018 19:37:37 +0300
From:   Vlad Buslov <vladbu@...lanox.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, Roman Mashak <mrv@...atatu.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Cong Wang <xiyou.wangcong@...il.com>, pablo@...filter.org,
        kadlec@...ckhole.kfki.hu, fw@...len.de, ast@...nel.org,
        Daniel Borkmann <daniel@...earbox.net>,
        Eric Dumazet <edumazet@...gle.com>, kliteyn@...lanox.com,
        Lucas Bates <lucasb@...atatu.com>
Subject: Re: [PATCH 00/14] Modify action API for implementing lockless actions


On Fri 18 May 2018 at 12:33, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 17/05/18 09:35 AM, Vlad Buslov wrote:
>> 
>> On Wed 16 May 2018 at 21:51, Jiri Pirko <jiri@...nulli.us> wrote:
>>> Wed, May 16, 2018 at 11:23:41PM CEST, vladbu@...lanox.com wrote:
>>>>
>
>>>>> Please make sure you have these in your kernel config:
>>>>>
>>>>> CONFIG_NET_ACT_IFE=y
>>>>> CONFIG_NET_IFE_SKBMARK=m
>>>>> CONFIG_NET_IFE_SKBPRIO=m
>>>>> CONFIG_NET_IFE_SKBTCINDEX=m
>>>
>>> Roman, could you please add this to some file? Something similar to:
>>> tools/testing/selftests/net/forwarding/config
>>>
>
> How would putting the file there help?
>
>>> Thanks!
>>>
>>>>>
>>>>> For tdc to run all the tests, it is assumed that all the supported tc
>>>>> actions/filters are enabled and compiled.
>>>>
>>>> Enabling these options allowed all ife tests to pass. Thanks!
>>>>
>>>> Error in u32 test still appears however:
>>>>
>>>> Test e9a3: Add u32 with source match
>>>>
>>>> -----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 ingress"
>>>>
>>>> -----> prepare stage *** Error message: "Cannot find device "v0p1"
>> 
>> I investigated and was able to fix u32 problems.
>> 
>> First of all, u32 test requires having veth interfaces that are not
>> created by test infrastructure by default. Following command fixes the
>> issue:
>> 
>> sudo ip link add v0p0 type veth peer name v0p1
>> 
>
> That is documented on the README i believe - however, we should
> be able to detect that a test needs the device and create it via
> a plugin. Lucas?

Description from README:

*  The kernel must have veth support available, as a veth pair is created
   prior to running the tests.

For me it looked like test suite will create veth pair by itself and I
only need to enable veth support in kernel config.

>
>> After executing this command test passes, however looking at test
>> definition itself it seems meaningless. It creates filter with match
>> source IP 127.0.0.1, then tests if filter with source IP 127.0.0.2
>> exists, but passes successfully because it actually expects to match
>> zero filters with such IP :)
>> 
>> I fixed it and it passed properly matching single filter with source IP
>> 127.0.0.2.
>>
>
> Please send a patch.

Done.

>
>> After this flower test failed. The flower test expects that user
>> explicitly provide "-d" option with interface to use. With -d it failed
>> again. This time because it expects action to have 1m references, but
>> actual value was 1000001. I investigated it and found out that test
>> passed, if executed without running other tests first. So it seemed that
>> some other test was leaking reference to gact action. It turned out that
>> culprit was mirred test 6fb4, which created pipe action but didn't flush
>> it afterward.
>>
>
> Hopefully the last patch from Roman fixes that? Otherwise send something
> on top.

Done.

>
>> With all tests passing on that particular version of net-next, I will
>> now rebase my changes on top of it and run them again.
>> 
>
> Thank you Vlad!
>
> cheers,
> jamal