Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3340418iob; Mon, 16 May 2022 20:00:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzY19sQxK9r//y9CrAUwErlp8zHSCyrv8PWH9QVXpTWwpxjyf0HjtpQPCGdZO72CE9LloUN X-Received: by 2002:a63:8843:0:b0:3da:fe5c:9374 with SMTP id l64-20020a638843000000b003dafe5c9374mr17945249pgd.342.1652756423227; Mon, 16 May 2022 20:00:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652756423; cv=none; d=google.com; s=arc-20160816; b=06AynuNVTbJEyJNRXOWJrCGVM6EuIVMkw2W/XVdmLZRBPeAv1O18RHu5+qHyRGbBMQ tjWkRMk1uV/l9/BI3Rhlo26qGrQPgIcZ0N6L4jNmRKoHbtfwSCgGBhKeG/z0k36Ub/9A KTyPCOvmMlrlTS9fy+4cnOBT7q3a/6MaiEFzf/y5ge3liwPqIALps3dWLp/oLDHA65m5 cBjJUV4wAVoP51Hii59h7Hvn71595ViRQWJYo4ll57F8aHEdL0YWKLquK3tb1AX1PNqE RgQnJ3gQo4LJAaQSJOBOtkiPqWQsAeeFLBK112HKLAHaPX1/zH80uJRcOHh/OPxunz7d IRwA== 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=5433wkekbhMmVnoTGWgvcpHPK1VHVImeCeZ/nXSD99o=; b=ucrj+KNyvvQIMj7ECsnvsWwcY+6XGW/4NI83k0Tvl5TiON3gQTL4OdDo+SuQLRnktU tLSqyB8EcN70gCb5berNFrh2wAmh8WhCNxWw0kpewaJjvSPS/yLseJ7LMff2ycQsemDG 4Rwgi6AvyCwY99XWo3sPIR2/KyhebX9PhhJKcKqbKrCu5SrYZbkLL8ZSEv9sdbsvDHCU e9pYIGgBpTYG2VTH969v0G16/Y1AE95KZ55uy+TNASR6LrXK4zsrvyQwR7H9tJltTyGl uLAJDlkRmjy8XNEX+e/bU5Pccyi+j1ZqWKtxi+Z8pWzDQijR2rlIyN38/pEzuwFdzqEb TM4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MM3tVaE1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j2-20020a17090276c200b0015874d582f1si13492360plt.326.2022.05.16.20.00.11; Mon, 16 May 2022 20:00:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MM3tVaE1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347992AbiEPT6S (ORCPT + 99 others); Mon, 16 May 2022 15:58:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348385AbiEPTwt (ORCPT ); Mon, 16 May 2022 15:52:49 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 329D846143; Mon, 16 May 2022 12:48:30 -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 sin.source.kernel.org (Postfix) with ESMTPS id 3FE47CE1798; Mon, 16 May 2022 19:48:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 496F0C385AA; Mon, 16 May 2022 19:48:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1652730486; bh=opEjq9W4e4mdUfYcrv+hb/wQ8SN9cNZERUQK7jR9LHQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MM3tVaE1G7Jh1o8S9Tgxm7yRjCW+X10HWU3JE8YRq7ZqYlvmi3G/dOMS7cV6qhdfh zDd93ojM+jIJthr0FDtqueiPqZcpyeAPC6S1KJ3oGScogwFeZwQ31j+KCks6HYDMWv BTeN5lrXYxX6zWYtMO+a5gK4JLTwFniPbd3Cb3Sc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vladimir Oltean , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.15 007/102] net: mscc: ocelot: fix VCAP IS2 filters matching on both lookups Date: Mon, 16 May 2022 21:35:41 +0200 Message-Id: <20220516193624.205099439@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220516193623.989270214@linuxfoundation.org> References: <20220516193623.989270214@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=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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: Vladimir Oltean [ Upstream commit 6741e11880003e35802d78cc58035057934f4dab ] The VCAP IS2 TCAM is looked up twice per packet, and each filter can be configured to only match during the first, second lookup, or both, or none. The blamed commit wrote the code for making VCAP IS2 filters match only on the given lookup. But right below that code, there was another line that explicitly made the lookup a "don't care", and this is overwriting the lookup we've selected. So the code had no effect. Some of the more noticeable effects of having filters match on both lookups: - in "tc -s filter show dev swp0 ingress", we see each packet matching a VCAP IS2 filter counted twice. This throws off scripts such as tools/testing/selftests/net/forwarding/tc_actions.sh and makes them fail. - a "tc-drop" action offloaded to VCAP IS2 needs a policer as well, because once the CPU port becomes a member of the destination port mask of a packet, nothing removes it, not even a PERMIT/DENY mask mode with a port mask of 0. But VCAP IS2 rules with the POLICE_ENA bit in the action vector can only appear in the first lookup. What happens when a filter matches both lookups is that the action vector is combined, and this makes the POLICE_ENA bit ineffective, since the last lookup in which it has appeared is the second one. In other words, "tc-drop" actions do not drop packets for the CPU port, dropped packets are still seen by software unless there was an FDB entry that directed those packets to some other place different from the CPU. The last bit used to work, because in the initial commit b596229448dd ("net: mscc: ocelot: Add support for tcam"), we were writing the FIRST field of the VCAP IS2 half key with a 1, not with a "don't care". The change to "don't care" was made inadvertently by me in commit c1c3993edb7c ("net: mscc: ocelot: generalize existing code for VCAP"), which I just realized, and which needs a separate fix from this one, for "stable" kernels that lack the commit blamed below. Fixes: 226e9cd82a96 ("net: mscc: ocelot: only install TCAM entries into a specific lookup and PAG") Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/ethernet/mscc/ocelot_vcap.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/mscc/ocelot_vcap.c b/drivers/net/ethernet/mscc/ocelot_vcap.c index f5f513d87642..c01cbc4f7a1a 100644 --- a/drivers/net/ethernet/mscc/ocelot_vcap.c +++ b/drivers/net/ethernet/mscc/ocelot_vcap.c @@ -373,7 +373,6 @@ static void is2_entry_set(struct ocelot *ocelot, int ix, OCELOT_VCAP_BIT_0); vcap_key_set(vcap, &data, VCAP_IS2_HK_IGR_PORT_MASK, 0, ~filter->ingress_port_mask); - vcap_key_bit_set(vcap, &data, VCAP_IS2_HK_FIRST, OCELOT_VCAP_BIT_ANY); vcap_key_bit_set(vcap, &data, VCAP_IS2_HK_HOST_MATCH, OCELOT_VCAP_BIT_ANY); vcap_key_bit_set(vcap, &data, VCAP_IS2_HK_L2_MC, filter->dmac_mc); -- 2.35.1