On Mon, Dec 11, 2023 at 10:58:22AM +0100, Alexandr Nedvedicky wrote: > dlg@ and I are basically trying to remove all NET_LOCK() operations from > pf(4), because we don't want pf(4) to be playing with global NET_LOCK(). > all callers to pf(4) should either obtain NET_LOCK() in case they need it. > pf(4) should not care about NET_LOCK() at all. That's the ideal situation > where we are heading to.
pf(4) neither playing with NET_LOCK() nor relying on net lock is a good goal. But when pf calls something in the network stack, it needs at least shared net lock. This is the reponsibility of the caller. As the caller does not know when pf calls what, it think all entry points into pf should hold net lock. In general this is also true for the pf timers. We should keep simple locking rules how subsystems interact. Removing net lock from pf on one end and relying on net lock in IP stack when called from pf will not work. > I took a closer look at export_pflow() in current. It seems to me the > function assumes caller holds a shared NET_LOCK() at least, just to > protect > consistency of `pflowif_list`. For that we take mvs@ diff. It solves the current problem.
