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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 10 Aug 2018 14:45:24 -0700 From: Cong Wang <xiyou.wangcong@...il.com> To: Vlad Buslov <vladbu@...lanox.com> Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>, Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Yevgeny Kliteynik <kliteyn@...lanox.com>, Jiri Pirko <jiri@...lanox.com> Subject: Re: [PATCH net-next v6 10/11] net: sched: atomically check-allocate action On Fri, Aug 10, 2018 at 3:29 AM Vlad Buslov <vladbu@...lanox.com> wrote: > > Approach you suggest is valid, but has its own trade-offs: > > - As you noted, lock granularity becomes coarse-grained due to per-netns > scope. Sure, you acquire idrinfo->lock too, the only difference is how long you take it. The bottleneck of your approach is the same, also you take idrinfo->lock twice, so the contention is heavier. > > - I am not sure it is possible to call idr_replace() without obtaining > idrinfo->lock in this particular case. Concurrent delete of action with > same id is possible and, according to idr_replace() description, > unlocked execution is not supported for such use-case: But we can hold its refcnt before releasing idrinfo->lock, so idr_replace() can't race with concurrent delete. > > - High rate or replace request will generate a lot of unnecessary memory > allocations and deallocations. > Yes, this is literally how RCU works, always allocate and copy, release upon error. Also, if this is really a problem, we have SLAB_TYPESAFE_BY_RCU too. ;)
Powered by blists - more mailing lists