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=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 F3F11C04AB5 for ; Thu, 6 Jun 2019 14:04:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D38A020652 for ; Thu, 6 Jun 2019 14:04:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727590AbfFFOEM (ORCPT ); Thu, 6 Jun 2019 10:04:12 -0400 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:51304 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726092AbfFFOEM (ORCPT ); Thu, 6 Jun 2019 10:04:12 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1hYszy-0001Sg-9o; Thu, 06 Jun 2019 16:04:10 +0200 Date: Thu, 6 Jun 2019 16:04:10 +0200 From: Florian Westphal To: John Hurley Cc: Florian Westphal , Linux Netdev List , Simon Horman , Jakub Kicinski , Jamal Hadi Salim , oss-drivers@netronome.com Subject: Re: [RFC net-next v2 1/1] net: sched: protect against loops in TC filter hooks Message-ID: <20190606140410.4rp3eudxamdtfme7@breakpoint.cc> References: <1559825374-32117-1-git-send-email-john.hurley@netronome.com> <20190606125818.bvo5im2wqj365tai@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org John Hurley wrote: > On Thu, Jun 6, 2019 at 1:58 PM Florian Westphal wrote: > > I dislike this, why can't we just use a pcpu counter? > > > > The only problem is with recursion/nesting; whenever we > > hit something that queues the skb for later we're safe. > > > > Hi Florian, > The per cpu counter (initial proposal) should protect against > recursion through loops and the potential stack overflows. > It will not protect against a packet infinitely looping through a poor > configuration if (as you say) the packet is queued at some point and > the cpu counter reset. Yes, it won't help, but thats not harmful, such cycle will be broken/resolved as soon as the configuration is fixed. > The per skb tracking seems to accommodate both issues. Yes, but I do not see the 'looping with queueing' as a problem, it can also occur for different reasons. > Do you see the how the cpu counter could stop infinite loops in the > case of queuing? No, but I don't think it has to. > Or perhaps these are 2 different issues and should be treated differently? The recursion is a problem, so, yes, I think these are different issues. > > We can't catch loops in real (physical) setups either, > > e.g. bridge looping back on itself. > > yes, this is only targeted at 'internal' loops. Right, however, I'm not sure we should bother with those, we can't prevent this (looping packets) from happening for other reasons. I'm sure you can make packets go in circles without tc, e.g. via veth+bridge+netns.