]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Remove RT_LOCK mutex from rte.
authorAlexander V. Chernikov <melifaro@FreeBSD.org>
Mon, 24 Aug 2020 20:23:34 +0000 (20:23 +0000)
committerAlexander V. Chernikov <melifaro@FreeBSD.org>
Mon, 24 Aug 2020 20:23:34 +0000 (20:23 +0000)
commit592d300e346f7c376d7be30b1627d0a2db500570
tree72bfcfee4a158f4fd2c639eb30c9f3543ce3c9f4
parent17c511a42294bff409ad573e12140085f4877c85
Remove RT_LOCK mutex from rte.

rtentry lock traditionally served 2 purposed: first was protecting refcounts,
 the second was assuring consistent field access/changes.
Since route nexthop introduction, the need for the former disappeared and
 the need for the latter reduced.
To be more precise, the following rte field are mutable:

rt_nhop (nexthop pointer, updated with RIB_WLOCK, passed in rib_cmd_info)
rte_flags (only RTF_HOST and RTF_UP, where RTF_UP gets changed at rte removal)
rt_weight (relative weight, updated with RIB_WLOCK, passed in rib_cmd_info)
rt_expire (time when rte deletion is scheduled, updated with RIB_WLOCK)
rt_chain (deletion chain pointer, updated with RIB_WLOCK)
All of them are updated under RIB_WLOCK, so the only remaining concern is the reading.

rt_nhop and rt_weight (addressed in this review) are read under rib lock and
 stored in the rib_cmd_info, so the caller has no problem with consitency.
rte_flags is currently read unlocked in rtsock reporting (however the scope
 is only RTF_UP flag, which is pretty static).
rt_expire is currently read unlocked in rtsock reporting.
rt_chain accesses are safe, as this is only used at route deletion.

rt_expire and rte_flags reads will be dealt in a separate reviews soon.

Differential Revision: https://reviews.freebsd.org/D26162
sys/kern/subr_witness.c
sys/net/route.c
sys/net/route/route_ctl.c
sys/net/route/route_var.h
sys/net/rtsock.c