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: Mon, 11 Sep 2017 14:58:16 -0700 From: Cong Wang <xiyou.wangcong@...il.com> To: Jiri Pirko <jiri@...nulli.us> Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>, Jakub Kicinski <jakub.kicinski@...ronome.com>, Jiri Pirko <jiri@...lanox.com> Subject: Re: [Patch net v2 2/2] net_sched: fix all the madness of tc filter chain On Mon, Sep 11, 2017 at 2:14 PM, Cong Wang <xiyou.wangcong@...il.com> wrote: > > Looks like all due to the lack of locking on block->chain_list. > I thought the rcu_barrier() could properly handle this, > but seems still not, probably I need to move it in the loop, > I am still not 100% sure if it is totally safe with > list_for_each_safe(): > > > - list_for_each_entry(chain, &block->chain_list, list) > + list_for_each_entry_safe(chain, tmp, &block->chain_list, list) { > tcf_chain_flush(chain); > - rcu_barrier(); > + rcu_barrier(); // are we safe now??? > + } > Answer myself: No, this is not safe either, because we may list_del() the next node, and apparently _safe() can't guarantee that... So either we have to use locking or use the trick you suggested.
Powered by blists - more mailing lists