netdev - Re: [PATCH net] ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes

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] [day] [month] [year] [list]

Message-ID: <eea3d0b0-64ed-7aea-ffb7-ab48078ab494@gmail.com>
Date:   Mon, 5 Mar 2018 08:27:26 -0700
From:   David Ahern <dsahern@...il.com>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Wei Wang <weiwan@...gle.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Maciej Żenczykowski <maze@...gle.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] ipv6: Reflect MTU changes on PMTU of exceptions for
 MTU-less routes

On 3/5/18 5:29 AM, Stefano Brivio wrote:
> On Sun, 4 Mar 2018 18:11:41 -0700
> David Ahern <dsahern@...il.com> wrote:
> 
>> On 3/4/18 4:12 PM, Stefano Brivio wrote:
>>> On Sat, 3 Mar 2018 12:22:36 +0100
>>> Stefano Brivio <sbrivio@...hat.com> wrote:
>>>   
>>>>> And please codify the above expectation as a test under
>>>>> tools/testing/selftests/net    
>>>>
>>>> And this, along with v2.  
>>>
>>> On a second thought: I start thinking it doesn't make much sense,
>>> especially given the current context of self-tests, to explicitly test
>>> this, because it's a rather particular corner case.
>>>
>>> I think it would make more sense to introduce generic tests first.
>>> About, say, PMTU, or route exceptions, but not "tunnel causes route
>>> exception and administrative change doesn't affect PMTU".
>>>   
>>
>> I would argue corner cases in particular should be documented.
> 
> Sure, but self-tests are not meant for documentation. I think commit
> messages are.
> 
> And about corner cases, from Documentation/dev-tools/kselftest.rst:
> 
> 	These are intended to be small tests to exercise individual code
> 	paths in the kernel. Tests are intended to be run after building, installing
> 	and booting a kernel.
> 
> and:
> 
> 	In general, the rules for selftests are
> 	[...]
> 	 * Don't take too long;
> 
> if you plan to request a self-test for every fix in the networking area,
> you need to substantially change the scope of these self-tests. This stuff
> would instead fit in a comprehensive networking test suite.

The Linux Networking stack is long over due for a comprehensive
functional test. There is very little about Layer 3 that can not be
tested with network namespaces, vrf, veth and a recent iproute2 package.

No one company is going to pay someone to write this test suite. It
takes commitment from contributors to submit tests as we go, and test
cases for bug fixes is one of the easiest and best ways to get this moving.

> 
>> From the commit message it seems like you took the time to create a test
>> setup using network namespaces. Throw those commands into a shell script
>> -- tools/testing/selftests/net/mtu.sh. It can evolve from there.
> 
> My script sets up namespaces, veth and vti6 interfaces, xfrm states and
> policies (could be replaced by vxlan, but that's what I have now). Then
> it pings, waits, prints exception routes, changes MTU, etc. In the
> commit message, I reported only the relevant parts that are enough to
> clearly show the issue.
> 
> This script is some ugly monster I don't want to have on my conscience,
> or wish for anybody to run as "small test to exercise individual code
> paths".

Understood. I have a lot of those for MPLS, for example. Each time I
write one it evolves into something cleaner and now I have a few worth
submitting to selftests (and that will happen in it - e.g, when I come
back to MPLS).

> 
> I don't think sensible self-tests can evolve from it. They could
> instead evolve from some generic, basic PMTU (or route exceptions) test,
> rather than from my very particular fix that needs to involve so many
> steps to be checked.
> 

sure it can. I have a basic pmtu script that I wrote to test IPv6 for my
FIB change patch set. I will be submitting it in time as well.

We have to start somewhere, and it takes a commitment from multiple
people to make this happen.