From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [PATCH] net: Revert "net_sched: no need to free qdisc in RCU callback" Date: Fri, 22 Dec 2017 10:35:24 +0100 Message-ID: <20171222093524.GA11519@nanopsycho> References: <20171220200919.6233.48192.stgit@john-Precision-Tower-5810> <3c7d356b-8293-9e60-ede0-a92188296867@gmail.com> <20171221083908.GA1930@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: John Fastabend , David Miller , Jakub Kicinski , Linux Kernel Network Developers , Eric Dumazet To: Cong Wang Return-path: Received: from mail-wm0-f68.google.com ([74.125.82.68]:34767 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200AbdLVJf0 (ORCPT ); Fri, 22 Dec 2017 04:35:26 -0500 Received: by mail-wm0-f68.google.com with SMTP id y82so23606235wmg.1 for ; Fri, 22 Dec 2017 01:35:25 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Thu, Dec 21, 2017 at 09:59:56PM CET, xiyou.wangcong@gmail.com wrote: >On Thu, Dec 21, 2017 at 12:39 AM, Jiri Pirko wrote: >> >> Why just moving qdisc_free to rcu is not enough? It would resolve this >> issue and also avoid using synchronize net. Something like: > >If you mean Jakub's issue, apparently not: >https://www.kernel.org/pub/linux/kernel/people/paulmck/Answers/RCU/RCUCBordering.html > >Jiri, you have to use a rcu barrier to wait for a rcu callback, not >queuing another rcu callback, the ordering is simply NOT guaranteed. Sure. But the ordering does not matter in this case. You just need to make sure the reader does not see freed qdisc struct. > >What's more importantly, you already have one rcu barrier in the >same function. Why keep believing you don't need it? The rcu barrier is there for a different reason. It is there to avoid reuse of old miniq that readers still might see in scenario miniq1 miniq2 miniq1 again