iflib/bridge kernel panic

[Kristof Provost]

On 30 Sep 2020, at 13:52, Alexander Leidinger wrote:
> Quoting Kristof Provost <kp at freebsd.org> (from Tue, 29 Sep 2020 
> 23:20:44 +0200):
>
>> On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
>>
>>> Quoting Kristof Provost <kp at freebsd.org> (from Mon, 28 Sep 2020 
>>> 13:53:16 +0200):
>>>
>>>> On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
>>>>> Quoting Kristof Provost <kp at freebsd.org> (from Sun, 27 Sep 2020 
>>>>> 17:51:32 +0200):
>>>>>> Here’s an early version of a task queue based approach: 
>>>>>> http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch
>>>>>>
>>>>>> That still needs to be cleaned up, but this should resolve the 
>>>>>> sleep issue and the LOR.
>>>>>
>>>>> There are some issues... seems like inside a jail I can't ping 
>>>>> systems outside of the hardware.
>>>>>
>>>>> Bridge setup:
>>>>>   - member jail A
>>>>>   - member jail B
>>>>>   - member external_if of host
>>>>>
>>>>> If I ping the router from the host, it works. If I ping from one 
>>>>> jail to another, it works. If I ping from the jail to the IP of 
>>>>> the external_if, it works. If I ping from a jail to the router, I 
>>>>> do not get a response.
>>>>>
>>>> Can you check for 'failed ifpromisc' error messages in dmesg? And 
>>>> verify that all bridge member interfaces are in promiscuous mode?
>>>
>>> I have a panic for you...:
>>> - startup still in progress = 22 jails in startup, somewhere after a 
>>> few jails started the panic happened
>>> - tcpdump was running on the external interface
>>> - a ping to a jail IP from another system was running, the first 
>>> ping went through, then it paniced
>>>
>>> First regarding your questions about promisc mode: no error, but the 
>>> promisc mode is directly disabled again on all interfaces.
>>>
>> I think I see why you had issues with the promiscuous setting. I’ve 
>> updated the patch to be even more horrific than it was before.
>
> Hmmm.... same behavior as before.
> I haven't kept the old version of the patch, so I can't compare if I 
> somehow downloaded the old version again, or if I got the updated 
> one...
>
Okay, let’s abandon that patch. It’s ugly and it doesn’t work.

Here’s a different approach that I’m much happier with.
https://people.freebsd.org/~kp/0001-bridge-Call-member-interface-ioctl-without-NET_EPOCH.patch

It passes the regression tests with WITNESS and INVARIANTS enabled, and 
a hack in the epair ioctl() handler to make it sleep (to look a bit like 
the Intel ioctl() handler that currently trips up if_bridge).

Best,
Kristof