Re: [PATCH net-next v2 3/3] vrf: Remove unnecessary RCU protection around dst entries

[David Ahern <dsahern@kernel.org>]

On 3/26/26 2:32 PM, Ido Schimmel wrote:
> During initialization of a VRF device, the VRF driver creates two dst
> entries (for IPv4 and IPv6). They are attached to locally generated
> packets that are transmitted out of the VRF ports (via the
> l3mdev_l3_out() hook). Their purpose is to redirect packets towards the
> VRF device instead of having the packets egress directly out of the VRF
> ports. This is useful, for example, when a queuing discipline is
> configured on the VRF device.
> 
> In order to avoid a NULL pointer dereference, commit b0e95ccdd775 ("net:
> vrf: protect changes to private data with rcu") made the pointers to the
> dst entries RCU protected. As far as I can tell, this was needed because
> back then the dst entries were released (and the pointers reset to NULL)
> before removing the VRF ports.
> 
> Later on, commit f630c38ef0d7 ("vrf: fix bug_on triggered by rx when
> destroying a vrf") moved the removal of the VRF ports to the VRF
> device's dellink() callback. As such, the tear down sequence of a VRF
> device looks as follows:
> 
> 1. VRF ports are removed.
> 2. VRF device is unregistered.
>     a. Device is closed.
>     b. An RCU grace period passes.
>     c. ndo_uninit() is called.
>         i. dst entries are released.
> 
> Given the above, the Tx path will always see the same fully initialized
> dst entries and will never race with the ndo_uninit() callback.
> 
> Therefore, there is no need to make the pointers to the dst entries RCU
> protected. Remove it as well as the unnecessary NULL checks in the Tx
> path.
> 
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  drivers/net/vrf.c | 56 ++++++++++-------------------------------------
>  1 file changed, 12 insertions(+), 44 deletions(-)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>