aboutsummaryrefslogtreecommitdiff
path: root/.github
diff options
context:
space:
mode:
authorGleb Smirnoff <glebius@FreeBSD.org>2021-12-02 18:48:48 +0000
committerGleb Smirnoff <glebius@FreeBSD.org>2021-12-02 18:48:48 +0000
commitde2d47842e880281da07f2589b9ec558b42c09c1 (patch)
tree12e10b46a936eb5a1afd2c6b0767e9e545b33a31 /.github
parent565655f4e33e6e04c53c1c566b50fc07fd685f2f (diff)
SMR protection for inpcbs
With introduction of epoch(9) synchronization to network stack the inpcb database became protected by the network epoch together with static network data (interfaces, addresses, etc). However, inpcb aren't static in nature, they are created and destroyed all the time, which creates some traffic on the epoch(9) garbage collector. Fairly new feature of uma(9) - Safe Memory Reclamation allows to safely free memory in page-sized batches, with virtually zero overhead compared to uma_zfree(). However, unlike epoch(9), it puts stricter requirement on the access to the protected memory, needing the critical(9) section to access it. Details: - The database is already build on CK lists, thanks to epoch(9). - For write access nothing is changed. - For a lookup in the database SMR section is now required. Once the desired inpcb is found we need to transition from SMR section to r/w lock on the inpcb itself, with a check that inpcb isn't yet freed. This requires some compexity, since SMR section itself is a critical(9) section. The complexity is hidden from KPI users in inp_smr_lock(). - For a inpcb list traversal (a pcblist sysctl, or broadcast notification) also a new KPI is provided, that hides internals of the database - inp_next(struct inp_iterator *). Reviewed by: rrs Differential revision: https://reviews.freebsd.org/D33022
Diffstat (limited to '.github')
0 files changed, 0 insertions, 0 deletions