Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1778780pxb; Wed, 9 Feb 2022 04:25:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJxhH8cv6fyrBF754bzDUwIxCkD0ufXd/0Mq9XJ7kKBFBXvsnZJq6/50UkSswY00z4e1kP7b X-Received: by 2002:a17:902:ecc6:: with SMTP id a6mr2170239plh.6.1644409547119; Wed, 09 Feb 2022 04:25:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644409547; cv=none; d=google.com; s=arc-20160816; b=p2bSUoINf+qcq21Tn8LnlMTVPWs5r64sE9X2DYvMDNoI5gn9oX8I4IhtJnXy0LAtnH WrchQb/0wWUfxBr7aRP+G0F+NUVW/Yg2Zqtc/bnLP6OuzdxnmfWKLQsVtJPzi6XzWfRc NVSP0QvRU57JORdQC951Bt4XZV4iuTjkzuo54OGDoS0OxSeD7oDVihnPmXAKqk8XDrfm HdkUDmR9SMgJpu+LxLlxOQOUt4D0ndFafNwcnvpJ+lBFLQt6qwsrOjsobA34r0xPFCXB MrB4yVKDKT07P0RnvIeA6PBW9K0O7Wa0td0J6wfFw9nE0PEe4oXCvQ/8O4sgpCXyFvPk V92Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:date:message-id:subject:from:cc:to; bh=k80wN6PYx2o0fZv6Vf18Dae6slk5UK867Ni6EbNqKt8=; b=FTxCCNIQFPUKQt7fzrnHyzKX2PjNVk6bul8/j59E1GVkJ+PCFhDQdd7CDKjPZns1gp xDfYxUE6OuEaiqqoSQYl8RIFBsOmYghUTQWmn/DfcuvAINZQjDdnsPRInMVS+mOFjnde FWLzSdlpphA1CB1yYJDJ4yLJHKMCeSFYQAz9rDdQsDSR+ek+zihCwWSHwIjBA5bBujs/ aKGCGmOYL9jPoZrrSkgUYMqVdaChSiovbl4cgM0tI4j4SQirGsv19IgLdV42ShtXXaQ3 RNJfjkTCUlt+Hpfhx8ZsvUzeC41uudlMlUDN1hxNbNmIXV9ac7w6LuUy6P9tQdNe0fem 8+Ng== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id z17si16899480pfe.9.2022.02.09.04.25.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 04:25:47 -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; 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0FCF5E126236; Wed, 9 Feb 2022 02:17:21 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382981AbiBGOnr (ORCPT + 99 others); Mon, 7 Feb 2022 09:43:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1392293AbiBGO0J (ORCPT ); Mon, 7 Feb 2022 09:26:09 -0500 X-Greylist: delayed 972 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 07 Feb 2022 06:26:05 PST Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C034C0401C1 for ; Mon, 7 Feb 2022 06:26:05 -0800 (PST) Received: from kwepemi500005.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Jsp0N0MWqzccn5; Mon, 7 Feb 2022 22:08:52 +0800 (CST) Received: from kwepemm600001.china.huawei.com (7.193.23.3) by kwepemi500005.china.huawei.com (7.221.188.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 22:09:51 +0800 Received: from [10.174.176.245] (10.174.176.245) by kwepemm600001.china.huawei.com (7.193.23.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 22:09:50 +0800 To: David Miller , Jakub Kicinski , , , CC: , linux-kernel From: "wanghai (M)" Subject: [BUG] net: ipv4: The sent udp broadcast message may be converted to an arp request message Message-ID: <55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com> Date: Mon, 7 Feb 2022 22:09:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.245] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600001.china.huawei.com (7.193.23.3) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 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. Any feedback would be appreciated, thanks. -- Wang Hai