From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22C08C4360F for ; Thu, 28 Feb 2019 05:15:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E04E7218AE for ; Thu, 28 Feb 2019 05:15:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y0FL961G" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730804AbfB1FP5 (ORCPT ); Thu, 28 Feb 2019 00:15:57 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:37180 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725899AbfB1FP4 (ORCPT ); Thu, 28 Feb 2019 00:15:56 -0500 Received: by mail-pg1-f194.google.com with SMTP id q206so9105244pgq.4 for ; Wed, 27 Feb 2019 21:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9UMX3pcmSLHAr39L2mTVyZv9Lg+bgg6voY3R7v9i1Po=; b=Y0FL961GH5Xbjw0sUd13M6q+KrM+CtT/XDcmZbywxrQaGNXdAMsDFva8vDmDWxdhUw clcv1yvSNJMnUIYkkeD16MTpFxNBMdh0Q9zbJzn3QP2Hw8NhqfoHCDLlMsjsDNmYLRqv rJZphlh7c0mYu48pQVUbCVNplCFuIuVWWOGGgDWuK+mCHY4EhmRRVEip63OiyX3GdfoV 5F5dYOBMErEx+o1Z6lrb0emt0xo1vw1zbOJjBlsaHrEBkiosj0sJFlDFPv+5Cy051jTL TJzyq9y11OfatG5L9EHnHZJOHlzqOWoyXDoH2Sp4DKFa3gxpdb2hMxXzFFG+pGAquQnk GbIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9UMX3pcmSLHAr39L2mTVyZv9Lg+bgg6voY3R7v9i1Po=; b=TSUgZoQJG3yqOzY/d1NSeVcW9Ypr44MLXnf7SCCsdkisu44//3JbsIQeklsCDbs6iH DTGLJT4U2cmoPnOZG351dTfAd9OqeuFSMYdXGm/RvKYeDl5hzNwaLr5qSxt8NyHea+2H EqW/G3dDPdPd+zhWelFirtOopdersHxW+bUjA+jU76TNr8O3xj/y0s2g+mLronuNDG0q ca63QosjSE7oea/SiEaXx+/BvP2Qt5ZRCe+MSG+6jwGX7nenQ8sojF3Ix91o7VB40glF o2qB6rskwreSkENNoCyCjsXewpFJvLyCi8Qa0kGLvX6bQMgxxapnFw1PpD+AoMIeHxkh 35Zg== X-Gm-Message-State: AHQUAubt4Q5JwhHw9JR4J7gu2Jr0AfKCnXB4ZOBHGnkzlmNwFWk/notV IwATTrFCM7cyaIpFCcAdfQMkHRqw X-Google-Smtp-Source: AHgI3IYORewY6dGcimOmikl+fTh3A8aAZ/UMf12LRm/4Vdq/mSbZB0++uwFalE3ma3EXdxQQd+10qw== X-Received: by 2002:a63:3541:: with SMTP id c62mr6540756pga.157.1551330955776; Wed, 27 Feb 2019 21:15:55 -0800 (PST) Received: from [192.168.86.235] (c-73-241-150-70.hsd1.ca.comcast.net. [73.241.150.70]) by smtp.gmail.com with ESMTPSA id g71sm40431794pfg.157.2019.02.27.21.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 21:15:54 -0800 (PST) Subject: Re: [BUG] net/sched : qlen can not really be per cpu ? To: Cong Wang Cc: John Fastabend , Networking , Jamal Hadi Salim , Jiri Pirko References: <5fb87db3-d5bd-714b-213d-6821f4bf37da@gmail.com> From: Eric Dumazet Message-ID: Date: Wed, 27 Feb 2019 21:15:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 02/27/2019 06:46 PM, Cong Wang wrote: > Hmm, looking into this, do we really need to check cl->leaf.q->q.qlen > in htb_activate() for pfifo_fast? htb_activate() is only called when > qdisc_enqueue() returns NET_XMIT_SUCCESS, so for pfifo_fast > that is always qlen!=0, right? > > So something like below? It is ugly but should be sufficient to shut > up the warning. > > diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c > index 30f9da7e1076..6d0182750f8b 100644 > --- a/net/sched/sch_htb.c > +++ b/net/sched/sch_htb.c > @@ -555,7 +555,8 @@ htb_change_class_mode(struct htb_sched *q, struct > htb_class *cl, s64 *diff) > */ > static inline void htb_activate(struct htb_sched *q, struct htb_class *cl) > { > - WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen); > + WARN_ON(cl->level || !cl->leaf.q || > + (!(cl->leaf.q->flags & TCQ_F_NOLOCK) && !cl->leaf.q->q.qlen)); > > if (!cl->prio_activity) { > cl->prio_activity = 1 << cl->prio; > Well, this is the tip of the iceberg. Look at lines 845 & 883 How are we going to fix them ? (Then there are all the other qdisc I mentioned)