Hello,
On Wed, Dec 16, 2015 at 02:48:49PM +1300, Richard Procter wrote: > > On Tue, 15 Dec 2015, Mike Belopuhov wrote: > > > > Yet another possibility is to drop 'once' rules as too complex to > > > implement for multiprocessor but I have no idea if this is viable. > > > > It is. And I have said that before with an authority of the implementor > > of "once" rules: since we don't have any userland applications that > > would use this yet, we can ditch them for now and possibly devise a > > better approach later. > > > Don't make your lives harder than they have to be! > > I tend to agree! And I can't see a way to reimplement it for a > multithreaded pf without introducing downsides. > > Quoting pf.conf(5) "once - Creates a one shot rule that will remove itself > from an active ruleset after the first match." > > A 'first' match presupposes a total ordering. This comes for free when pf > is single-threaded but concurrent rule matching must take the trouble to > re-impose it somewhere. (I assume that pf aims to do concurrent matching > of packets against the ruleset.) pf@solaris allows the race here. The price for correct behavior, which is to allow one and only one packet to hit the rule is too high (given the once rules are kind of special case). What has to be granted is there is one 'winner' only, which puts the rule to garbage collector list. The pragmatic approach wins here. regards sasha
