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.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 DAF4BC433DF for ; Thu, 30 Jul 2020 21:01:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B83092084D for ; Thu, 30 Jul 2020 21:01:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730426AbgG3VBN (ORCPT ); Thu, 30 Jul 2020 17:01:13 -0400 Received: from mga12.intel.com ([192.55.52.136]:13681 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728809AbgG3VBL (ORCPT ); Thu, 30 Jul 2020 17:01:11 -0400 IronPort-SDR: 7yMrklX/VzB/EgrqbsGlLBsM6V+ap1/WBByFM35lRaR5nZBrXDBhzCKOGe5AoxPR03E0zFDAlI JKHmsSfTZ/Kw== X-IronPort-AV: E=McAfee;i="6000,8403,9698"; a="131260075" X-IronPort-AV: E=Sophos;i="5.75,415,1589266800"; d="scan'208";a="131260075" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 14:01:08 -0700 IronPort-SDR: PbBop5KoWfxIf5o0EeWb6lVbV0rWzkfRTunIt9hrwuf/zZQRSrrXZp+ryETaUUA/WKnwaLh1qp 2jvTHGZqeMIQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,415,1589266800"; d="scan'208";a="490804902" Received: from kyoungil-mobl1.amr.corp.intel.com (HELO ellie) ([10.209.108.110]) by fmsmga006.fm.intel.com with ESMTP; 30 Jul 2020 14:01:06 -0700 From: Vinicius Costa Gomes To: Eric Dumazet , Dmitry Vyukov Cc: "Zhang\, Qiang" , syzbot , "davem\@davemloft.net" , "fweisbec\@gmail.com" , "jhs\@mojatatu.com" , "jiri\@resnulli.us" , "linux-kernel\@vger.kernel.org" , "mingo\@kernel.org" , "netdev\@vger.kernel.org" , "syzkaller-bugs\@googlegroups.com" , "tglx\@linutronix.de" , "xiyou.wangcong\@gmail.com" Subject: Re: =?utf-8?B?5Zue5aSNOg==?= INFO: rcu detected stall in tc_modify_qdisc In-Reply-To: <3fc2ce1b-553a-e6de-776c-7e4d668c6ecb@gmail.com> References: <0000000000006f179d05ab8e2cf2@google.com> <87tuxqxhgq.fsf@intel.com> <87pn8cyk2b.fsf@intel.com> <3fc2ce1b-553a-e6de-776c-7e4d668c6ecb@gmail.com> Date: Thu, 30 Jul 2020 14:01:05 -0700 Message-ID: <87k0ykyay6.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, Eric Dumazet writes: >> I admit that I am on the fence on that argument: do not let even root >> crash the system (the point that my code is crashing the system gives >> weight to this side) vs. root has great powers, they need to know what >> they are doing. >> >> The argument that I used to convince myself was: root can easily create >> a bunch of processes and give them the highest priority and do >> effectively the same thing as this issue, so I went with a the "they >> need to know what they are doing side". >> >> A bit more on the specifics here: >> >> - Using a small interval size, is only a limitation of the taprio >> software mode, when using hardware offloads (which I think most users >> do), any interval size (supported by the hardware) can be used; >> >> - Choosing a good lower limit for this seems kind of hard: something >> below 1us would never work well, I think, but things 1us < x < 100us >> will depend on the hardware/kernel config/system load, and this is the >> range includes "useful" values for many systems. >> >> Perhaps a middle ground would be to impose a limit based on the link >> speed, the interval can never be smaller than the time it takes to send >> the minimum ethernet frame (for 1G links this would be ~480ns, should be >> enough to catch most programming mistakes). I am going to add this and >> see how it looks like. >> >> Sorry for the brain dump :-) > > > I do not know taprio details, but do you really need a periodic timer > ? As we can control the transmission time of packets, you are right, I don't. Just a bit more detail about the current implementation taprio, basically it has a sequence of { Traffic Classes that are open; Interval } that repeats cyclicly, it uses an hrtimer to advance the pointer for the current element, so during dequeue I can check if a traffic class is "open" or "closed". But again, if I calculate the 'skb->tstamp' of each packet during enqueue, I don't need the hrtimer. What we have in the txtime-assisted mode is half way there. I think this is what you had in mind. Cheers, -- Vinicius