Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp755370pxb; Tue, 5 Apr 2022 21:56:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFyubuydssReNPRXP+qDSoW2U8aziRDFB/v+5Ee/m43z4DrwDZHfBbI0hvTOW+c59BOZyW X-Received: by 2002:a17:902:f687:b0:154:64be:3518 with SMTP id l7-20020a170902f68700b0015464be3518mr6872121plg.4.1649220973359; Tue, 05 Apr 2022 21:56:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649220973; cv=none; d=google.com; s=arc-20160816; b=wclmqOkhe5IPEb2GUHyqb5dJ3ENgvbm4LzNJstOeoJ70obBQsIgr41BFAaBvmHkOIr aLBp2Z2d7e9WJB9ktw2UP4jg461WR7kJUrc9QdQfcgAYn4Rj1kxsi1yDEL7PegteSeW8 9pLXek49AxPfsQCqYUD0HEVnwueEitGulxeFTxlPcfWnoaCYoDv3IPMP9ZcGMo34svdq cMeFMk8JGbgN58+bbZHZ1jzkDG2IGyUHa3KChXHs/RuEtjASKqmAcMjix/8AOqaYZDlX 1aeVoGq9H/558nZ+MD2vUooWl2vJo2G4Wwde898SCPVXWXT+x1SvnJ0Zee2MBKDjhjET rQ6A== 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=L97Ky2tMIwWxZd5iadlqSCMyTWlXVNFTCqYQa3WWJV4WDF0/YFygyiUxCtRhCcF3Rm 3z5hs2FpG6kZsxAXRt6SYjEITVwa3Q5wh4fRf8vT/fBGWRI+IU1+3N4gjUG4Uk3ZMheI YITUeBqz60OpIwGjgOn965zumXMItR/lWFeVVEkB6wUs6DtM6w21NwLP3XUy0VDsamhK qBvEufB/77mZrmwT1q3r+udAPIc4FHlwjBJZDwnvekdEDBQTvVDBf4mK0Kyh/6lTCfJa T3/hg1PJDznhXfFTMFgBKDwTSfdg1llFEivRE2sdGZzoc3nx9cBTOnfAN2cZc2KM8dU/ sO7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=12oK0qL7; 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 n12-20020a170902d2cc00b00153b2d16490si14974983plc.152.2022.04.05.21.56.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 21:56:13 -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=12oK0qL7; 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 4B344D1CFA; Tue, 5 Apr 2022 20:15:59 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347926AbiDEJ2q (ORCPT + 99 others); Tue, 5 Apr 2022 05:28:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239556AbiDEIUO (ORCPT ); Tue, 5 Apr 2022 04:20:14 -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 9C29F25D2; Tue, 5 Apr 2022 01:16:10 -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 39FF9609D0; Tue, 5 Apr 2022 08:16:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D52EC385A2; Tue, 5 Apr 2022 08:16:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649146569; bh=pIuTGn7V2ZbvS6rqkuxePpmv09JwUS3+tmCDJx4nrgM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=12oK0qL7eZdp4hkK1ako/d5k8JbDYgaYazxMlabvb14BGW/zCz6P213NviJC76rz+ e0QfJ/yzrqh3Zy8d8r6Q9gBnsQ+1BXD8fCzq9oksAJmViYQzgfLZXJo8TvoQxhfOb6 Ys/p5ty2or6swHmZ98+w7j4XJX3On4gIKP+kRDWQ= 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.17 0812/1126] selftests: test_vxlan_under_vrf: Fix broken test case Date: Tue, 5 Apr 2022 09:25:59 +0200 Message-Id: <20220405070431.398906798@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070407.513532867@linuxfoundation.org> References: <20220405070407.513532867@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