Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp639966pxb; Tue, 5 Apr 2022 16:57:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx6kOsNxrMjLCLUpuB/EdnLD8qbag0/esOgyzq9xtcF+HFfUy0owWqNFWL7UvXPxUM9raNq X-Received: by 2002:a17:90a:558a:b0:1ca:a819:d2d1 with SMTP id c10-20020a17090a558a00b001caa819d2d1mr6978163pji.126.1649203060928; Tue, 05 Apr 2022 16:57:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649203060; cv=none; d=google.com; s=arc-20160816; b=yOBetcBgak8/mqrIPsbKh9VhutnA60KNpNKIrzEDKJfWzh7u8+Rp5RmH5++NK1iDiX RFoLBx9EnBzreRiQ1lFWJJOwI1GX3H0eHuyvQpQmu2W4jhxYTgHNZv4aE5xhjHWT77BX jhdW9tyZUJmma4qEOcww3Ps3tQVY7R8tbdPMEK7j/VWcY7zmPPclWKGTYXaaaoSzb8hu H+nKlvh3kir9a7OMZToRrKRmkMlKLvSlvDea/f1AthQyrYXN4BOOiEZcu2mUkyusDPJk k51LLIHp4/TmfEINRXYpI2Nl1hUIjJCrZU1XUCDN7sE3A8NB9Zx/cMJB4XIx2DggfElQ 2fTw== 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:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=v4cmUEPl9nA5HtCIQ5yxj2q9REU7ZwoGYg/sDvzf9eM=; b=d0l1LkI/ccoNsuQFjJcGsj9zjbgko1HNUnl7aFp+8knJ+5CxCUOFDrUjo6JlK10f+u Coqe3hYBwQanQOqRlEJGAZDBHd+yH4Amc8f+VdhW//0+IJCCHmYOBCaIKLmh6nQcdoi8 pUfDYVacSTBfRv3bxSWjLfMcjV7kQPd5nLH82mkGUBHLWKfhnJeMZ1Wxs7e87XeSs0fA cWcaEsqUXTRRTX4DT5dY0RcJSHt8ol/Ah0nxqdf69n+g1lWBDdKZaPUt0bmDhZ+hDpk/ hkF026+u8F+N7eg680AR6O30bKSz30rGiQdwUiPz+njHkwX8BJIhb3TX7WQ/7riR7LCT hv8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=z5SDChZu; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id o20-20020a656a54000000b0039924bcaf8bsi9069667pgu.713.2022.04.05.16.57.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 16:57:40 -0700 (PDT) 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=@linuxfoundation.org header.s=korg header.b=z5SDChZu; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DFC682816BA; Tue, 5 Apr 2022 16:43:29 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358752AbiDENJh (ORCPT + 99 others); Tue, 5 Apr 2022 09:09:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344164AbiDEJS2 (ORCPT ); Tue, 5 Apr 2022 05:18:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF4366212F; Tue, 5 Apr 2022 02:04:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8C274614E4; Tue, 5 Apr 2022 09:04:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F170C385A0; Tue, 5 Apr 2022 09:04:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649149495; bh=pIuTGn7V2ZbvS6rqkuxePpmv09JwUS3+tmCDJx4nrgM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z5SDChZujxyFxqy4Wyj6Kr9eujBFj4Co9ArT0yt73EviNvJmXRdrKysRCFZH3ycnK Ibij+RF9ImlLyHiNsh383kOMGUqvcdTh2hHwXV21JicyfsZaYpzk2QTe4rgp55bDUY V1/TAUNbHcqKl0QK4iFQF+YbNllfSxbGZPI25kPU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ido Schimmel , David Ahern , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 0735/1017] selftests: test_vxlan_under_vrf: Fix broken test case Date: Tue, 5 Apr 2022 09:27:28 +0200 Message-Id: <20220405070416.082992146@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070354.155796697@linuxfoundation.org> References: <20220405070354.155796697@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 From: Ido Schimmel [ Upstream commit b50d3b46f84282d795ae3076111acb75ae1031f3 ] The purpose of the last test case is to test VXLAN encapsulation and decapsulation when the underlay lookup takes place in a non-default VRF. This is achieved by enslaving the physical device of the tunnel to a VRF. The binding of the VXLAN UDP socket to the VRF happens when the VXLAN device itself is opened, not when its physical device is opened. This was also mentioned in the cited commit ("tests that moving the underlay from a VRF to another works when down/up the VXLAN interface"), but the test did something else. Fix it by reopening the VXLAN device instead of its physical device. Before: # ./test_vxlan_under_vrf.sh Checking HV connectivity [ OK ] Check VM connectivity through VXLAN (underlay in the default VRF) [ OK ] Check VM connectivity through VXLAN (underlay in a VRF) [FAIL] After: # ./test_vxlan_under_vrf.sh Checking HV connectivity [ OK ] Check VM connectivity through VXLAN (underlay in the default VRF) [ OK ] Check VM connectivity through VXLAN (underlay in a VRF) [ OK ] Fixes: 03f1c26b1c56 ("test/net: Add script for VXLAN underlay in a VRF") Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20220324200514.1638326-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- tools/testing/selftests/net/test_vxlan_under_vrf.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/net/test_vxlan_under_vrf.sh b/tools/testing/selftests/net/test_vxlan_under_vrf.sh index ea5a7a808f12..1fd1250ebc66 100755 --- a/tools/testing/selftests/net/test_vxlan_under_vrf.sh +++ b/tools/testing/selftests/net/test_vxlan_under_vrf.sh @@ -120,11 +120,11 @@ echo "[ OK ]" # Move the underlay to a non-default VRF ip -netns hv-1 link set veth0 vrf vrf-underlay -ip -netns hv-1 link set veth0 down -ip -netns hv-1 link set veth0 up +ip -netns hv-1 link set vxlan0 down +ip -netns hv-1 link set vxlan0 up ip -netns hv-2 link set veth0 vrf vrf-underlay -ip -netns hv-2 link set veth0 down -ip -netns hv-2 link set veth0 up +ip -netns hv-2 link set vxlan0 down +ip -netns hv-2 link set vxlan0 up echo -n "Check VM connectivity through VXLAN (underlay in a VRF) " ip netns exec vm-1 ping -c 1 -W 1 10.0.0.2 &> /dev/null || (echo "[FAIL]"; false) -- 2.34.1