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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 925D7C43217 for ; Thu, 24 Nov 2022 12:42:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229507AbiKXMmV (ORCPT ); Thu, 24 Nov 2022 07:42:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229647AbiKXMmI (ORCPT ); Thu, 24 Nov 2022 07:42:08 -0500 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDFAFF72F5 for ; Thu, 24 Nov 2022 04:41:40 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A90635C0129; Thu, 24 Nov 2022 07:41:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Nov 2022 07:41:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1669293696; x=1669380096; bh=VitFjZtJvWpj3F2lJqlagGHTV0Ec x94SxdP9qRlazko=; b=EgDBEDaM9gUdgJZu6aNO+mTgVkxJ9c++evMUKD7oiHP6 +LoO6XkSnHlczG+3lrMEAwTkdOEiPIY7nKBYxpqjAs9leoucTgMI+kExtCrrOIQe 9TEJiI4ef5ccpPpOF+82If4orX3xnLDYZW/89/GY9AIDQ1u6+cI0taR0mIqT07bI BDv35oaofuNlxJbBRpISNm6JBjce4en54I8FwCRtLJLwK2q/F8E5NN5AL+U1GNUn 15WwfpqbO5TIOMDBsj/59GgWxpL30+Bcd22EVL1b08615m5bz8t3T7PwhYvLQ+ko PJyGTz5zM+TNiY53nIAm/Q73P91jrMqG6bDOJnTBmA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrieefgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedvudefveekheeugeeftddvveefgfduieefudeifefgleekheegleegjeejgeeg hfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiug hoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Feedback-ID: i494840e7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Nov 2022 07:41:35 -0500 (EST) Date: Thu, 24 Nov 2022 14:41:31 +0200 From: Ido Schimmel To: Jonas Gorski Cc: Network Development , David Ahern Subject: Re: RTM_DELROUTE not sent anymore when deleting (last) nexthop of routes in 6.1 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Nov 24, 2022 at 10:20:00AM +0100, Jonas Gorski wrote: > Hello, > > when an IPv4 route gets removed because its nexthop was deleted, the > kernel does not send a RTM_DELROUTE netlink notifications anymore in > 6.1. A bisect lead me to 61b91eb33a69 ("ipv4: Handle attempt to delete > multipath route when fib_info contains an nh reference"), and > reverting it makes it work again. > > It can be reproduced by doing the following and listening to netlink > (e.g. via ip monitor) > > ip a a 172.16.1.1/24 dev veth1 > ip nexthop add id 100 via 172.16.1.2 dev veth1 > ip route add 172.16.101.0/24 nhid 100 > ip nexthop del id 100 > > where the nexthop del will trigger a RTM_DELNEXTHOP message, but no > RTM_DELROUTE, but the route is gone afterwards anyways. I tried the reproducer and I get the same notifications in ip monitor regardless of whether 61b91eb33a69 is reverted or not. Looking at the code and thinking about it, I don't think we ever generated RTM_DELROUTE notifications when IPv4 routes were flushed (to avoid a notification storm). Are you running an upstream kernel? Thanks > > Doing the same thing with IPv6 still works as expected > > ip a a 2001:db8:91::1/64 dev veth1 > ip nexthop add id 100 via 2001:db8:91::2 dev veth1 > ip route add 2001:db8:101::/64 nhid 100 > ip nexthop del id 100 > > Here the kernel will send out both the RTM_DELNEXTHOP and the > RTM_DELROUTE netlink messages. > > Unfortunately my net-foo is not good enough to propose a fix. > > Best regards > Jonas