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)
Wed, Oct 30, 2:57 AM
Unknown Object (File)
Oct 16 2024, 6:03 AM
Unknown Object (File)
Oct 5 2024, 1:14 PM
Unknown Object (File)
Oct 4 2024, 2:42 PM
Unknown Object (File)
Oct 4 2024, 10:02 AM
Unknown Object (File)
Oct 1 2024, 8:52 PM
Unknown Object (File)
Oct 1 2024, 8:28 PM
Unknown Object (File)
Oct 1 2024, 1:05 PM

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.