svn commit: r359436 - in head/sys: kern net sys

[Kristof Provost]

On 31 Mar 2020, at 17:17, Mark Johnston wrote:
> On Tue, Mar 31, 2020 at 03:51:27PM +0800, Li-Wen Hsu wrote:
>> On Tue, Mar 31, 2020 at 3:00 PM Kristof Provost <kp at freebsd.org> 
>> wrote:
>>>
>>> On 31 Mar 2020, at 7:56, Li-Wen Hsu wrote:
>>>> On Tue, Mar 31, 2020 at 10:55 AM Mark Johnston <markj at freebsd.org> 
>>>> wrote:
>>>>>>> It seems could be triggered by sys.netinet6.frag6.*
>>>>>>> sys.netpfil.common.* sbin.pfctl.pfctl_test.* tests, and there 
>>>>>>> are lots
>>>>>>> of test cases timed out.
>>>>>>>
>>>>>>> Can you help check these?
>>>>>>
>>>>>> I see, it is actually caused by r359438.  I'm looking at it now.
>>>>>
>>>>> I verified that the netpfil and netinet6 tests pass with r359477.
>>>>
>>>> Thanks for the fixing, the latest test panics at epair_qflush:
>>>>
>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14747/consoleFull
>>>>
>>>> while executing sys.netpfil.pf.* tests. I'm not sure if this is
>>>> related or because of previous commits (I suspect the later). I'll
>>>> look into this.
>>>>
>>> That’s a know issue with epair (since EPOCH, I believe).
>>> A number of the pf tests are disabled due to this. See 238870.
>>
>> I also think so, btw, currently every test run panics so I am afraid
>> that the recent commits might make status worse (or say, make the
>> issue easier to reproduce?)
>
> I haven't been able to reproduce any panics or test failures so far.

Once you disable the ‘atf_skip’ lines in the pf tests a simple `sudo 
kldload pfsync && cd /usr/tests/sys/netpfil/pf && sudo kyua test` is 
likely sufficient.

There’s a complex race around tearing down epair interfaces and moving 
them back to their home vnet that’s proven very tricky to resolve.

Best regards,
Kristof