[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

2018-01-16 Thread bugzilla-noreply
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

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

2018-01-16 Thread bugzilla-noreply
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

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

2018-01-16 Thread bugzilla-noreply
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,

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

2018-01-16 Thread bugzilla-noreply
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

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

2018-01-16 Thread bugzilla-noreply
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 *

[Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize

2018-01-16 Thread bugzilla-noreply
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