Page MenuHomeFreeBSD

pf: getstates: avoid taking the hashrow lock if the row is empty
ClosedPublic

Authored by kp on Jun 29 2021, 7:38 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 6, 8:33 PM
Unknown Object (File)
Fri, Mar 14, 7:32 AM
Unknown Object (File)
Fri, Mar 14, 4:44 AM
Unknown Object (File)
Thu, Mar 13, 10:42 PM
Unknown Object (File)
Feb 23 2025, 12:03 PM
Unknown Object (File)
Feb 19 2025, 11:13 PM
Unknown Object (File)
Feb 18 2025, 8:32 PM
Unknown Object (File)
Jan 31 2025, 6:59 AM

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kp requested review of this revision.Jun 29 2021, 7:38 PM
This revision is now accepted and ready to land.Jun 30 2021, 2:04 PM
donner added inline comments.
sys/netpfil/pf/pf_ioctl.c
5058

Accessing this value without a lock ... may it cause a race condition?

sys/netpfil/pf/pf_ioctl.c
5058

It is a data race, but it is tolerable in this case. Absolute worst which can happen is that the row will be skipped when it should not be. But let's say garbage was read. The acquire fence provided by PF_HASHROW_LOCK below makes the previously read possibly bogus state irrelevant as it is forcibly refreshed.

sys/netpfil/pf/pf_ioctl.c
5058

That said ideally it would use a data structure which is safe to iterate in presence of modification. I have a rough sketch to implement this, so the state as proposed here should be temporary.