lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Jan 2020 22:30:06 +0100 From: Jesper Dangaard Brouer <brouer@...hat.com> To: John Fastabend <john.fastabend@...il.com> Cc: brouer@...hat.com, bpf@...r.kernel.org, bjorn.topel@...el.com, songliubraving@...com, ast@...nel.org, daniel@...earbox.net, toke@...hat.com, maciej.fijalkowski@...el.com, netdev@...r.kernel.org Subject: Re: [PATCH bpf-next v2 3/3] bpf: xdp, remove no longer required rcu_read_{un}lock() On Sat, 25 Jan 2020 19:58:53 -0800 John Fastabend <john.fastabend@...il.com> 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@...il.com> Acked-by: Jesper Dangaard Brouer <brouer@...hat.com> -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists