* Re: ipv6 UNH-IOL Intact test cases failure on kernel 4.4.178
[not found] <CAB5AJuUgQaoWPqjw5dSkZR-dQOx+KKatNR0vz28Kqzq1QYJDzA@mail.gmail.com>
@ 2019-10-11 9:11 ` Greg KH
0 siblings, 0 replies; only message in thread
From: Greg KH @ 2019-10-11 9:11 UTC (permalink / raw)
To: Lei Chen; +Cc: davem, netdev
On Fri, Oct 11, 2019 at 05:00:32PM +0800, Lei Chen wrote:
> Hi David,
> Thanks in advance for reading my message.
>
> We are running UNH-IOL test on our product which is based on kernel
> 4.4.178. The INTACT test cases failed on ipv6 verification. The same test
> cases just got pass on 4.4.153. (Sorry, the INTACT suite does not look to
> be open sourced. Hence I don't really know what the cases were indeed
> doing.)
>
> Our verification engineer also mentioned: "The pattern of failures look
> eerily similar to a regression we recently discovered in SLES 12. I.e.,
> Failures related to “Parameter Problems”, as well as “Fragmentation“." We
> have tried to back out the defragment related patch:
>
> commit 5f2d68b6b5a439c3223d8fa6ba20736f91fc58d8
> Author: Florian Westphal
> Date: Wed Oct 10 12:30:10 2018 -0700
>
> ipv6: defrag: drop non-last frags smaller than min mtu
>
> commit 0ed4229b08c13c84a3c301a08defdc9e7f4467e6 upstream.
>
> don't bother with pathological cases, they only waste cycles.
> IPv6 requires a minimum MTU of 1280 so we should never see fragments
> smaller than this (except last frag).
>
>
> But it doesn't help. Could you please shed a light on which patch between
> 4.4.153 and 4.4.178 could have caused such a regression? Thanks again.
As you can run the test, why can't you run 'git bisect' to find the
offending patch?
thanks,
greg k-h
^ permalink raw reply [flat|nested] only message in thread