Bug 243561 - pfctl -f fails on tables if system is swapping: cannot define table ${table_name}: Cannot allocate memory
Summary: pfctl -f fails on tables if system is swapping: cannot define table ${table_n...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2020-01-24 11:48 UTC by Lorenzo Salvadore
Modified: 2020-06-02 14:36 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Lorenzo Salvadore freebsd_committer 2020-01-24 11:48:07 UTC
My system is very busy and thus is using swap: swapinfo reports I am using 5% of swapping.

If I run "pfctl -f /etc/pf.conf" I get an error message "cannot define table ${table_name}: Cannot allocate memory" for every table I defined in /etc/pf.conf. After all this errors I get "Syntax error in config file: pf rules not loaded".

This happens on 13.0-CURRENT r356358.
Comment 1 Kristof Provost freebsd_committer 2020-01-24 12:41:52 UTC
Yeah ... you're out of memory, there's not much we can do in that situation.

The allocation code for tables deliberately does not try forever to get memory (i.e. it allocates with M_NOWAIT), because if it did you could lock up pf accidentally by trying to allocate a far too large table.
A consequence of this is that if you're under heavy memory pressure you're going to fail to allocate, and fail the reconfiguration.
Comment 2 Mark Johnston freebsd_committer 2020-06-02 14:36:44 UTC
I'm not sure there is much we can do here.  I recently made some changes to reduce memory usage for large pf tables, but as Kristof pointed out, we can't realistically use M_WAITOK since the tables can use an arbitrary amount of memory (subject to a sysctl which can be changed).

I would suggest seeing if you can still reproduce the problem on the latest HEAD or stable/12, though.  r345177 increased the memory footprint of large tables, especially on systems with many CPUs.  r360903 and r361095 restore the previous behaviour if you are not using per-entry counters (the default).

I will thus close the bug for now.  Please re-open if you are still able to trigger the failure with the above-mentioned revisions.