Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1592482pxb; Tue, 8 Feb 2022 23:25:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJzh3IWEM4Z+ef/v6+pT7QMNlCRBFYX/Dvwz3Vk9P1es3Q7FdFlZGMn+YEQT5uYqrSazpvf4 X-Received: by 2002:a17:902:da84:: with SMTP id j4mr854354plx.108.1644391531964; Tue, 08 Feb 2022 23:25:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644391531; cv=none; d=google.com; s=arc-20160816; b=ZlBYAXESdxp1f4ECPdlVcC2e9w1vvOsS4vm8uZACU97TMoMO2JdWw4hmI0IfVDLYmY +jqJ5zH+qdm31wgKMX40wAkdiKv3tHQOC1V/7OlS+uMEvwtLt1ZjjygqfY4M46or7qWV btcx+0JduS4JnNHSJIpLymRiuSe/8YFRXwReQowPQndghmpIdW0BqceM36xtA7NkQvHx uhvpCJn9lRJF+RtEk/N/Jwe5Uol5U8Bj0dccbTx+KhF4h1sOfdupHWSW6HU2/0lUJQis QE3Qh6YQ/hIdcVGNlsKxPijuymW6JlbO3Y+z1pGoHPYE0dKXGf0hg3KrOHTknuHUNQWb SaqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=CpObZswqDowwOx77NiQV1IhLqQ3/YYHk/8qYQOtLWSY=; b=Z5I1miO04Qt6Dp5uEe8yAx7EkvrnOJpIsNw+DseFkdRMO32gKBNRrLAvYLw6tvdpRp Ug26ysYE8J2Uh9tf8FJOnCkUWj+3L0ZpHnngYyknh9w4e39+r5QrCY5rKlHoOmXu0Vsx MnfqAyfMXmK2e69yqRYM/vY7lAYqiTxt02cMGJaORyJLsCufzKC3FdvcEQG+3lcA6bu8 n4CpFGkwM5h1xf2VnLRm3qypNMTJnNkA1GqV/nph4JzSAHPx6UZVvmCVfQSHIqgvsegH 6P8fwqqMCzOJqYCvsgCNUd7haFXL+76HzEW7SSUOyYNgAXqiBVYl2Xn/MbDJijylrebT sHWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=FOhwphY1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id w3si14464372ply.342.2022.02.08.23.25.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Feb 2022 23:25:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=FOhwphY1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E9F28E06FB29; Tue, 8 Feb 2022 22:37:08 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348624AbiBHHwF (ORCPT + 99 others); Tue, 8 Feb 2022 02:52:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235478AbiBHHwE (ORCPT ); Tue, 8 Feb 2022 02:52:04 -0500 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8960AC0401EF; Mon, 7 Feb 2022 23:52:03 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B729F320209C; Tue, 8 Feb 2022 02:52:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 08 Feb 2022 02:52:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date: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=fm2; bh=CpObZswqDowwOx77NiQV1IhLqQ3/YYHk/8qYQOtLW SY=; b=FOhwphY1RCs7OL4P897HcCxindLpk/o2q7oZP/nUuZIdlqj4taWeHOXpW OSOwxqOKraovMGq5hEk+qm69V32Dkz5sRKKaXJeymsVg4Ju0qCA+UHSzGOktWPpR Ikj2/Dp/FLOZhx7u9cMPV39WrEogqhJNAuNUV36T42qpCoQDE6ijIj/eNRcGbebd aBW+6urYzFX8Uz7gIPZZ9Qxj5ZwHoM2AuvIXAbhdEhm9j4abUWFJ0r5emhXRYEiY s+esRTMZJiWtYCebsppH1DJnKnX6iyM529J5PcL1cKMb/Qe3ypTBLPFnIE5PVeTY 0fyuuZyXd4Nfwl3ufIPngiGLwO52g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeigdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjgesthekredttddtudenucfhrhhomhepkfguohcu ufgthhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrth htvghrnhepvdffveekfeeiieeuieetudefkeevkeeuhfeuieduudetkeegleefvdegheej hefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepih guohhstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Feb 2022 02:51:58 -0500 (EST) Date: Tue, 8 Feb 2022 09:51:54 +0200 From: Ido Schimmel To: "wanghai (M)" Cc: David Miller , Jakub Kicinski , edumazet@google.com, yoshfuji@linux-ipv6.org, dsahern@kernel.org, netdev@vger.kernel.org, linux-kernel Subject: Re: [BUG] net: ipv4: The sent udp broadcast message may be converted to an arp request message Message-ID: References: <55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com> X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 07, 2022 at 10:09:49PM +0800, wanghai (M) wrote: > Hello, > > I found a bug, but I don't know how to fix it. Anyone have some good ideas? > > This bug will cause udp broadcast messages not to be sent, but instead send > non-expected arp request messages. > > Deleting the ip while sending udp broadcast messages and then configuring > the ip again will probably trigger the bug. > > The following is the timing diagram of the bug, cpu0 sends a broadcast > message and cpu1 deletes the routing table at the appropriate time. > > cpu0??????????????????? ??? ??? ??? ??? ??? cpu1 > send() > ? udp_sendmsg() > ??? ip_route_output_flow() > ??? |? fib_lookup() > ??? udp_send_skb() > ????? ip_send_skb() > ??????? ip_finish_output2() > > ??????????????????????????????????????????? ifconfig eth0:2 down > ????????????????????????????????????????????? fib_del_ifaddr > ??????????????????????????????????????????????? fib_table_delete // delete > fib table > > ????????? ip_neigh_for_gw() > ????????? |? ip_neigh_gw4() > ????????? |??? __ipv4_neigh_lookup_noref() > ????????? |??? __neigh_create() > ????????? |????? tbl->constructor(n) --> arp_constructor() > ????????? |??????? neigh->type = inet_addr_type_dev_table(); // no route, > neigh->type = RTN_UNICAST > ????????? neigh_output() // unicast, send an arp request and create an > exception arp entry > > After the above operation, an abnormal arp entry will be generated. If > the ip is configured again(ifconfig eth0:2 12.0.208.0), the abnormal arp > entry will still exist, and the udp broadcast message will be converted > to an arp request message when it is sent. Can you try the below? Not really happy with it, but don't have a better idea at the moment. It seemed better to handle it from the control path than augmenting the data path with more checks diff --git a/include/net/arp.h b/include/net/arp.h index 031374ac2f22..9e6a1961b64c 100644 --- a/include/net/arp.h +++ b/include/net/arp.h @@ -64,6 +64,7 @@ void arp_send(int type, int ptype, __be32 dest_ip, const unsigned char *dest_hw, const unsigned char *src_hw, const unsigned char *th); int arp_mc_map(__be32 addr, u8 *haddr, struct net_device *dev, int dir); +int arp_invalidate(struct net_device *dev, __be32 ip); void arp_ifdown(struct net_device *dev); struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip, diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c index 4db0325f6e1a..b81665ce2b57 100644 --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -1116,7 +1116,7 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev) return err; } -static int arp_invalidate(struct net_device *dev, __be32 ip) +int arp_invalidate(struct net_device *dev, __be32 ip) { struct neighbour *neigh = neigh_lookup(&arp_tbl, &ip, dev); int err = -ENXIO; diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c index 4d61ddd8a0ec..2d7085232cb5 100644 --- a/net/ipv4/fib_frontend.c +++ b/net/ipv4/fib_frontend.c @@ -1112,9 +1112,11 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) return; /* Add broadcast address, if it is explicitly assigned. */ - if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) + if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) { fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim, 0); + arp_invalidate(dev, ifa->ifa_broadcast); + } if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) && (prefix != addr || ifa->ifa_prefixlen < 32)) { @@ -1128,6 +1130,7 @@ void fib_add_ifaddr(struct in_ifaddr *ifa) if (ifa->ifa_prefixlen < 31) { fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask, 32, prim, 0); + arp_invalidate(dev, prefix | ~mask); } } }