From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [PATCH] net: Revert "net_sched: no need to free qdisc in RCU callback" Date: Wed, 20 Dec 2017 15:34:05 -0800 Message-ID: <3c7d356b-8293-9e60-ede0-a92188296867@gmail.com> References: <20171220200919.6233.48192.stgit@john-Precision-Tower-5810> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jiri Pirko , David Miller , Jakub Kicinski , Linux Kernel Network Developers , Eric Dumazet To: Cong Wang Return-path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:33102 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754303AbdLTXeV (ORCPT ); Wed, 20 Dec 2017 18:34:21 -0500 Received: by mail-pf0-f195.google.com with SMTP id y89so13220389pfk.0 for ; Wed, 20 Dec 2017 15:34:21 -0800 (PST) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 12/20/2017 03:23 PM, Cong Wang wrote: > On Wed, Dec 20, 2017 at 3:05 PM, John Fastabend > wrote: >> On 12/20/2017 02:41 PM, Cong Wang wrote: >>> On Wed, Dec 20, 2017 at 12:09 PM, John Fastabend >>> wrote: >>>> RCU grace period is needed for lockless qdiscs added in the commit >>>> c5ad119fb6c09 ("net: sched: pfifo_fast use skb_array"). >>>> >>>> It is needed now that qdiscs may be lockless otherwise we risk >>>> free'ing a qdisc that is still in use from datapath. Additionally, >>>> push list cleanup into RCU callback. Otherwise we risk the datapath >>>> adding skbs during removal. >>> >>> What about qdisc_graft() -> dev_deactivate() -> synchronize_net() ? >>> It doesn't work with your "lockless" patches? >>> >> >> Well this is only in the 'parent == NULL' case otherwise we call >> cops->graft(). Most sch_* seem to use qdisc_replace and this uses >> sch_tree_lock(). >> >> The only converted qdisc mq and mqprio at this point don't care >> though and do their own dev_deactivate/activate. So its not fixing >> anything in the above mentioned commit. > > Sure, removing a class does not impact the whole device, > but removing the root qdisc does. > > After your "lockless", skb_array_consume_bh() is called in > pfifo_fast_reset() and ptr_ring_cleanup() is called in > pfifo_fast_destroy(), assuming skb_array is not buggy, what race > do we have here with datapath? > None at the moment. > >> >> I still think it will need to be done eventually. If it resolves >> the miniq case it seems like a good idea. Although per Jakub's comment >> perhaps I pulled too much into the RCU handler. > > The case Jakub reported is a RCU callback missing a rcu > barrier. I don't understand why you keep believing it is RCU > readers on datapath.> > Not even to mention ingress is not affected by your "lockless" > thing. > I was thinking about the case where we want a lockless qdisc with classes. Doing the qdisc destroy after a grace period would solve this. Also we could start to cleanup a lot of the locking and extra bits around 'running' qdisc and such by doing a clean xchg on the qdisc layer. It seems that a dev_activate/deactivate just to install a new qdisc is not needed. Anyways future work. However if it resolves the miniq issue, as Jiri indicated, seems like a clean fix. Although Jakub's issue with the patch would need to be addressed. Seems he gets a WARN_ON if the offload is not disabled but the device is unitialized. .John