]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Remove RT_LOCK mutex from rte.
authormelifaro <melifaro@FreeBSD.org>
Mon, 24 Aug 2020 20:23:34 +0000 (20:23 +0000)
committermelifaro <melifaro@FreeBSD.org>
Mon, 24 Aug 2020 20:23:34 +0000 (20:23 +0000)
commit4343e7f4d9b84ffb7f696f5942c38505811091c7
tree72bfcfee4a158f4fd2c639eb30c9f3543ce3c9f4
parent9b3448f3dbe0a15018666c463f3cb2d2146fac5e
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