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

Date:   Mon, 5 Mar 2018 13:29:56 +0100
From:   Stefano Brivio <sbrivio@...hat.com>
To:     David Ahern <dsahern@...il.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 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.

> 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".

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.

-- 
Stefano