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: Wed, 16 Nov 2016 17:18:29 +0200 From: Ido Schimmel <idosch@...sch.org> To: Hannes Frederic Sowa <hannes@...essinduktion.org> Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com, eladr@...lanox.com, yotamg@...lanox.com, nogahf@...lanox.com, arkadis@...lanox.com, ogerlitz@...lanox.com, roopa@...ulusnetworks.com, dsa@...ulusnetworks.com, nikolay@...ulusnetworks.com, andy@...yhouse.net, vivien.didelot@...oirfairelinux.com, andrew@...n.ch, f.fainelli@...il.com, alexander.h.duyck@...el.com, kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net Subject: Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump Hi Hannes, On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote: > On 16.11.2016 15:09, Jiri Pirko wrote: > > From: Ido Schimmel <idosch@...lanox.com> > > > > Commit b90eb7549499 ("fib: introduce FIB notification infrastructure") > > introduced a new notification chain to notify listeners (f.e., switchdev > > drivers) about addition and deletion of routes. > > > > However, upon registration to the chain the FIB tables can already be > > populated, which means potential listeners will have an incomplete view > > of the tables. > > > > Solve that by adding an API to request a FIB dump. The dump itself it > > done using RCU in order not to starve consumers that need RTNL to make > > progress. > > > > Signed-off-by: Ido Schimmel <idosch@...lanox.com> > > Signed-off-by: Jiri Pirko <jiri@...lanox.com> > > Have you looked at potential inconsistencies resulting of RCU walking > the table and having concurrent inserts? Yes. I did try to think about situations in which this approach will fail, but I could only find problems with concurrent removals, which I addressed in 5/8. In case of concurrent insertions, even if you missed the node, you would still get the ENTRY_ADD event to your listener.
Powered by blists - more mailing lists