On Sat, 25 Jan 2020 19:58:53 -0800 John Fastabend <john.fastabend@xxxxxxxxx> wrote: > Now that we depend on rcu_call() and synchronize_rcu() to also wait > for preempt_disabled region to complete the rcu read critical section > in __dev_map_flush() is no longer required. Except in a few special > cases in drivers that need it for other reasons. > > These originally ensured the map reference was safe while a map was > also being free'd. And additionally that bpf program updates via > ndo_bpf did not happen while flush updates were in flight. But flush > by new rules can only be called from preempt-disabled NAPI context. > The synchronize_rcu from the map free path and the rcu_call from the > delete path will ensure the reference there is safe. So lets remove > the rcu_read_lock and rcu_read_unlock pair to avoid any confusion > around how this is being protected. > > If the rcu_read_lock was required it would mean errors in the above > logic and the original patch would also be wrong. > > Now that we have done above we put the rcu_read_lock in the driver > code where it is needed in a driver dependent way. I think this > helps readability of the code so we know where and why we are > taking read locks. Most drivers will not need rcu_read_locks here > and further XDP drivers already have rcu_read_locks in their code > paths for reading xdp programs on RX side so this makes it symmetric > where we don't have half of rcu critical sections define in driver > and the other half in devmap. > > Signed-off-by: John Fastabend <john.fastabend@xxxxxxxxx> Acked-by: Jesper Dangaard Brouer <brouer@xxxxxxxxxx> -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
