Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp948399pxb; Wed, 6 Apr 2022 05:05:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0IGxOe044IPrCPx7aQGCDyhcLqTiDJhvtzTzKEvRVn1MTIPunBSlwozyjxbXfjfZkBZx8 X-Received: by 2002:a63:cf0c:0:b0:380:fb66:fa2a with SMTP id j12-20020a63cf0c000000b00380fb66fa2amr6874116pgg.273.1649246755951; Wed, 06 Apr 2022 05:05:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649246755; cv=none; d=google.com; s=arc-20160816; b=0H1URB5sulcTHNPOkILsHWxDzcoVR0YXtt3rPIlIjKUUV+pFQjnGcB2CTV/bqSzX33 vtUMohI+fmBKdWPtLMbubDXKCeacaiPklcPFL7JmsQAjcIZrWOAKci63KUP6/kiCFqdt 6462dAK2vXLQY9DjR6VWJ2RABlnQ+MjMMlkymd7yKnK1Q9urKlnmmHGGWPQJUSPvOVQy 4dEeBc591rUS0AnN8ZrHT5gnVNA3r1KcOj09MQQVdjxDeA+QO/AJ/uYbjbkUbdqB5pc7 KsxHCz+6DjpUwOT+vngjGQpvakYFkZR5+CAIQ42LDYIQGD6Q0YwV3kCBUVYeC2hWX/3V Epfw== 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=RV+wjh1Q4nobNENPKON5lfsI7nrOiHChwmGU855hSWY=; b=NlJjusYVCou7Jvwbt8RfJrtOI2l+aeQOjnx4FaOApxbVMVtxhZ4UAH12DfndVOG7Sr PzA9Nt2HTDJidiik+q0SCOAYh+VHXCG1C7HLW0TtmP95mFTDaIdvG7fhfEhSWLYindiT Rm6x/z/HSTsDkk6SEmau9oR2Viwj2oSxp+N7Wkw2t2B5x1JGmauEJmtupQRr6pLQ52Oj GbUGNMWJSZyAH2NjrzaP+wE1/uYMihoCf3wzwJZPlOQtLQT0hD7ap4GlN2OwFIl4PM1b ca28DblHPYlQFC0Lc7TlubalMn/T9m5yyBWgPuch3DCyYoEsRI+q8GZVzBHPR9WmvC95 8ytg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DJf1RUzK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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. [23.128.96.19]) by mx.google.com with ESMTPS id nu13-20020a17090b1b0d00b001c673ed257csi5214751pjb.180.2022.04.06.05.05.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 05:05:55 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DJf1RUzK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 44A0F682DCE; Wed, 6 Apr 2022 03:33:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1457714AbiDEWrj (ORCPT + 99 others); Tue, 5 Apr 2022 18:47:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242775AbiDEKfS (ORCPT ); Tue, 5 Apr 2022 06:35:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6EFA4A920; Tue, 5 Apr 2022 03:20:59 -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 568BBB81BC5; Tue, 5 Apr 2022 10:20:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD4A0C385A1; Tue, 5 Apr 2022 10:20:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649154057; bh=WTTgE0jq1ET24nxFgkUnERXPbOwuOz6l4qpBGMY5MV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DJf1RUzKmTIBoSPMbVGl97qAEdIxzwa1SO318SypLmwvz5j3741W8LWExNBF3A+zC I5WDTdpPAQtC7uouk2CWZjI6iWzcAeBidoMZYgiIRKm2XFKQ/J6Cy0S/eF8wk9+epy F11irdxnb+Kd65jWoooxSTctAnISCB7ZsnfjVaig= 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.10 441/599] selftests: test_vxlan_under_vrf: Fix broken test case Date: Tue, 5 Apr 2022 09:32:15 +0200 Message-Id: <20220405070311.955504838@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070258.802373272@linuxfoundation.org> References: <20220405070258.802373272@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 09f9ed92cbe4..a44b9aca7427 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