Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp981198pxb; Wed, 6 Apr 2022 05:59:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2y8XBLQzGM+8BcbX4W473yR4jdSOSF6u3IP92+AdtcwzHjXOkZ7/v9LQ6XuEXsaacqWgA X-Received: by 2002:a05:6a00:b92:b0:4fa:82e9:786c with SMTP id g18-20020a056a000b9200b004fa82e9786cmr8781249pfj.31.1649249944346; Wed, 06 Apr 2022 05:59:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649249944; cv=none; d=google.com; s=arc-20160816; b=BrQgRy/T8TVmGO+Joxvm69Q6RfieBAX36cUMNEgOWZiVigw7gmeQMIACXS2C/6gyJP Kg2YCt3CA0nN172BHsKMUyReQHSPYGbAqyj6DdalLkLLyvDMrdSh6SbUFJuyfpK7iQ1k W5pDka3JpSV3wUw33WTFJx0OOuljC7+oJvX4WTtMZpdq41MvKeWxx03fTO2PKM00m0bh c7PjjGqSVBqxLetftUPhfvcOhMsReA2WDPPlBZUn8lXRq/cPW5iiao2C+hU26aP8TzoC VI0IjYq/Y3/h0KKYdCQCZSzBGBsVpey5vE0UiPmgR7LCFTmIlMwkLI1mQJ5UShdagWnI cUHQ== 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=rVeEdU70Fymy4HC9tNGM9lrpC8SbJy6Rcgf1pZDLcOo=; b=SLCbBOy5CVfxUYGixI+LiI6YpcR6kSEZEnbbTl3cTsy34hZzq7JkXwbgkgTMGSTCqR wyjuyREkFVAPIM2YnW7GkkzQTiOm3sAFvJPmT/NT+jRYjvKnjp40VYQGmaSvw9x8UUpN SPyIUW9bJboxaADFS3GIYSgT7F/XhwuF3Xf0d1751QNByitqfftA1Dns8E1VsicMzgsS oG7sOJP2syhS1rDP+0viauqZUpIvucFJTgoqKA9Lmdu92BRfBsDqVpFXXmVGm6tCZt0N fc2m85DAEhdN3fmBU4gO7WQRkPEvgGxC3mxArXC7y8J3MyQKEN+ewiksWoPoyJNDvVtb Q4XA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Yy+OJjA6; 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 pi11-20020a17090b1e4b00b001c653f1f13esi5070617pjb.95.2022.04.06.05.59.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 05:59:04 -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=Yy+OJjA6; 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 out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5866E46B82D; Wed, 6 Apr 2022 03:11:37 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1844053AbiDFBnC (ORCPT + 99 others); Tue, 5 Apr 2022 21:43:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350068AbiDEJwk (ORCPT ); Tue, 5 Apr 2022 05:52:40 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 710EC47AC2; Tue, 5 Apr 2022 02:50:41 -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 ams.source.kernel.org (Postfix) with ESMTPS id 28B9CB818F3; Tue, 5 Apr 2022 09:50:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78242C385A1; Tue, 5 Apr 2022 09:50:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649152238; bh=BYLceQ27HCG3skTU1Q/nNGBO22BIEfWtYYg8LclAFG0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yy+OJjA6OfMiVrL2s+UA0R5TFHOwYvGnkV3NmafU0IWz95CTyl5SoboQLBoJ3/LxR FnT+Ze+rznoieNpy+kECqUiO6zniQzQUceBLJ7M3PfyS/aRIgMJHfglfVjV0LI/LDl WGkneZVC//0BEKUkU6g0aZwZGGlXKlrsu3aSO0pU= 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.15 667/913] selftests: test_vxlan_under_vrf: Fix broken test case Date: Tue, 5 Apr 2022 09:28:49 +0200 Message-Id: <20220405070359.829072423@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@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 534c8b7699ab..6fadc8e2f116 100755 --- a/tools/testing/selftests/net/test_vxlan_under_vrf.sh +++ b/tools/testing/selftests/net/test_vxlan_under_vrf.sh @@ -118,11 +118,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