Kernel Panic

[Ermal Luçi]

On Thu, Mar 1, 2018 at 9:43 AM, Joe Jones <joe at stream-technologies.com>
wrote:

> Hi Kristo,
>
> It's just the master that crashed, the backup can take over.
>
> We think the panic we got by compiling with witness and invariant may be a
> red herring.
>
> We are now looking rules like
>
> nat on $isp_if from <napts> to any -> <external_napts> sticky-address
>
> if we replace the external_napts table with a single address rather than a
> block of addresses the box does not crash.
>
> We are following this line of investigation at the moment.
>

This is a known issue and should be documented somewhere, possibly man page.
It source is when locking was re-designed for pf(4).

https://github.com/freebsd/freebsd/blob/releng/11.1/sys/netpfil/pf/pf_lb.c#L428

* XXXGL: in the round-robin case we need to store
* the round-robin machine state in the rule, thus
* forwarding thread needs to modify rule.
*
* This is done w/o locking, because performance is assumed
* more important than round-robin precision.
*
* In the simpliest case we just update the "rpool->cur"
* pointer. However, if pool contains tables or dynamic
* addresses, then "tblidx" is also used to store machine
* state. Since "tblidx" is int, concurrent access to it can't
* lead to inconsistence, only to lost of precision.
*
* Things get worse, if table contains not hosts, but
* prefixes. In this case counter also stores machine state,
* and for IPv6 address, counter can't be updated atomically.
* Probably, using round-robin on a table containing IPv6
* prefixes (or even IPv4) would cause a panic.

The fix is to add proper locking around such scenario.
At minimum there would be needed a RULES_WLOCK in there or maybe reside to
atomics.



> Regards
> Joe Jones
>
>
> On 01/03/18 09:57, Kristof Provost wrote:
>
>> On 1 Mar 2018, at 15:37, Joe Jones wrote:
>>
>>> yes we use pfsync. Yesterday we tried with pfsync switched off, the box
>>> still locked up but this time without a panic.
>>>
>>> We make the DIOCRADDADDRS ioctl on the master and the backup (we use
>>> CARPed pairs).
>>>
>>> Interesting. It might be related to pfsync. Is is the master that panics
>> or the backup? Or both?
>>
>> Regards,
>> Kristof
>>
>
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>
> --
> Ermal
>