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 from the tree)
- 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.