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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 3CEA9C28CBC for ; Sat, 9 May 2020 05:57:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 049E424955 for ; Sat, 9 May 2020 05:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589003828; bh=ISc8bGy7yBICO1h3slM7QebMq5NKve758qzwmXPLuyA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=QApulD8MRlI43+DW2+osf/44OLTYS2N5b7ldATI6I5CLwUCqCXts2qBprjf3cRgLl Fzh7tPE7ioquy5bqVLNuPvC1RMAiAzczomanK1MXn5wpZ21XXPsa+LQOj+KCAP8LwP Gi+9+EwxRzVdNs2A4GMOqq1skA1V7wtDCT19nR0U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728797AbgEIF5H (ORCPT ); Sat, 9 May 2020 01:57:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:36016 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbgEIF5G (ORCPT ); Sat, 9 May 2020 01:57:06 -0400 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (unknown [163.114.132.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EB94521582; Sat, 9 May 2020 05:57:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589003826; bh=ISc8bGy7yBICO1h3slM7QebMq5NKve758qzwmXPLuyA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JkWBYxwAaXAoo7yqlxjXhok/SauHRHC80crfJhhcGQlX0TP01RtK/ZvqamBZppFbJ IY3nVlquGkFgQHKhzuLRnPHXQeKYDyan6azu1xY8K4UkkL+2OGlpuz/1EcKAncxk+q cqg6Qg0Dvan4nnqy45DWmTtQILEdJ+8nrNTo6RHQ= Date: Fri, 8 May 2020 22:57:04 -0700 From: Jakub Kicinski To: Paolo Abeni Cc: netdev@vger.kernel.org, "David S. Miller" , Colin Walters Subject: Re: [PATCH net] net: ipv4: really enforce backoff for redirects Message-ID: <20200508225704.40f53162@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <7f71c9a7ba0d514c9f2d006f4797b044c824ae84.1588954755.git.pabeni@redhat.com> References: <7f71c9a7ba0d514c9f2d006f4797b044c824ae84.1588954755.git.pabeni@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 8 May 2020 19:28:34 +0200 Paolo Abeni wrote: > In commit b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and > rate_tokens usage") I missed the fact that a 0 'rate_tokens' will > bypass the backoff algorithm. > > Since rate_tokens is cleared after a redirect silence, and never > incremented on redirects, if the host keeps receiving packets > requiring redirect it will reply ignoring the backoff. > > Additionally, the 'rate_last' field will be updated with the > cadence of the ingress packet requiring redirect. If that rate is > high enough, that will prevent the host from generating any > other kind of ICMP messages > > The check for a zero 'rate_tokens' value was likely a shortcut > to avoid the more complex backoff algorithm after a redirect > silence period. Address the issue checking for 'n_redirects' > instead, which is incremented on successful redirect, and > does not interfere with other ICMP replies. > > Fixes: b406472b5ad7 ("net: ipv4: avoid mixed n_redirects and rate_tokens usage") Looks like this one got backported all the way back to 3.16.. > Reported-and-tested-by: Colin Walters > Signed-off-by: Paolo Abeni Applied, thanks!