pf: Initialize the table entry zone limit at initialization time

[markj]

Summary

The limit may later be updated by the "set limit" directive in pf.conf.
UMA does not permit a limit to be set on a zone after any items have
been allocated from a zone.

Other UMA zones used by pf do not appear to be susceptible to this
problem: they either set a limit at zone creation time or never set one
at all.

PR: 260406

[kp]

That seems sane.

Does uma cope if limits get reduced, or does that also risk underflows?

(Also, it'd be nice to have UMA assert on this sort of mis-use.)

[markj]

In D34713#786690, @kp wrote:

That seems sane.

Does uma cope if limits get reduced, or does that also risk underflows?

I don't see a way for underflow to happen in that case. When a limit is set on a zone, UMA starts counting each item allocated to the zone from the slab layer. This counting is independent of the limit itself.

(Also, it'd be nice to have UMA assert on this sort of mis-use.)

Yep, I have a follow-up commit which does exactly that.

[markj]

I guess one question is whether anyone's relying on the fact that the limit is unset by default. Perhaps the default limit should be INT_MAX instead, at least in stable branches?

[kp]

In D34713#786719, @markj wrote:

I guess one question is whether anyone's relying on the fact that the limit is unset by default. Perhaps the default limit should be INT_MAX instead, at least in stable branches?

Given V_pf_limits[PF_LIMIT_TABLE_ENTRIES].limit = PFR_KENTRY_HIWAT; (i.e. we reported a limit to user space already) I'd think of the old behaviour as a bug and this is just a bug fix.