On Thu, Mar 1, 2018 at 9:43 AM, Joe Jones <j...@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org" > > -- > Ermal > _______________________________________________ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
