https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #16 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #15)
>> It does now. It was added very recently (in head). man 9 mallocarray. It
>> might be worth doing that change in a separate
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #11 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #10)
Yes, but I wouldn't check the free memory.
I've not yet looked at the code, but the original report suggests there are a
couple of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #13 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #12)
Yes, that's probably one of them.
There are a couple of allocations in pf_initialize() and they all use M_WAITOK.
I do see why,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #15 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #14)
> So, does this come down to supplying a default value and re-attempting
> malloc() again?
I was thinking in that direction as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #12 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #11)
For the first issue you mentioned,
I think it is this line blocking the startup
V_pf_srchash = malloc(pf_srchashsize *
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #14 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #13)
>> I do see why, because it's non-trivial to cope with allocation failures in
>> that part of the code. It gets called from a