Message ID | 20230425140604.169881-1-ivecera@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp3446896vqo; Tue, 25 Apr 2023 07:28:59 -0700 (PDT) X-Google-Smtp-Source: AKy350arraSnP5gDKT5IV9SWSzj/XnxITbrBZgqysn1de9hnaDXt5pzEmUW1zmaBLB0AfjIiZlqf X-Received: by 2002:a05:6a21:998d:b0:f1:ff77:4a32 with SMTP id ve13-20020a056a21998d00b000f1ff774a32mr24375962pzb.9.1682432939614; Tue, 25 Apr 2023 07:28:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682432939; cv=none; d=google.com; s=arc-20160816; b=gpb41y9ILufiJxOl4tfT+sm187omH0yMXAYvfGMV/M3q0dAo0nAtU0EfmUp42pXLnO 5KVbrKbJ0WxPlpQ5iQD5dAdV7T8KYfTLmwgAlAbPZWqdb4mCLbNdU02pUU64Z4ESHmNv hIKjRbRzrqA5utzt1/wHhTIfehy+gWeGZAe3KFvqQ7BZx4nAkeieZzOeaOZd6cvxkmut 1eR5am74AcjPhdUy41apOYcOWvb1wFUZAU1m6xhDl4u13e8MG43snqI94TVLUqtIZ/oV vKZJN4FPdjNY7A4hQJoE4MAI2iyO75drZWqccty6yWCsPmKXdUXX8M0SqWdt6oJgdm7m ZHIw== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=ky4or7cbHu9y2lAhkNJDV4gPS/WcEX9x/ObLAA4vgOA=; b=HwEcgJK5o2qv0u4KJ5WiE0Yv5qvUdybOgg0trDY1Jd4ptgIQreJJGKbqPpTY7PQvhS blKf64kVhri13uCOdJnegg+9or3yWsmpKPdHxY/asDZvxKNTfb36xbgIu1eo5yd1I6jT cAK4f9UlWExzdrRXE/iJdfBu6KmwbHo/z6+/UfK7gxNwGdD+SLtwZRIJdk0DabD+dVEa QR7ihH3Bd9gdxayrZSkQC05zkWmsUByYSUZTCiGveWP/xIgAFqckB7yE4ujmADfII5QW +fA1oEpls3fAS3GnEeVgR02ptc4QMjgg6uPBX0VkiuFmZQMqUDCXQpelBKkkC97SdiOc Y1JQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Or81DViK; 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=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qe2-20020a17090b4f8200b00246d179dc81si15027394pjb.126.2023.04.25.07.28.46; Tue, 25 Apr 2023 07:28:59 -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=@redhat.com header.s=mimecast20190719 header.b=Or81DViK; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234320AbjDYOHC (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 99 others); Tue, 25 Apr 2023 10:07:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233704AbjDYOHB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Apr 2023 10:07:01 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98FB2E6A for <linux-kernel@vger.kernel.org>; Tue, 25 Apr 2023 07:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682431572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ky4or7cbHu9y2lAhkNJDV4gPS/WcEX9x/ObLAA4vgOA=; b=Or81DViKcry4UI8VdHBJohr8jp+0IwrG9SIyz0/zsRrL92uXACQSacD1i6HSRdf3O7ajcH hmdr1xVg8JrGjgkeINpKTzLRt66BoUJeEfxzCv2JlacTy6oyoVkGJEX13Fufpw2eCwA5oJ sprH3DZMndfa0w3PGAX7dlMtUKW41ho= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-183-bVPvqCw8PY-I2o_YWzJQCQ-1; Tue, 25 Apr 2023 10:06:09 -0400 X-MC-Unique: bVPvqCw8PY-I2o_YWzJQCQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6C573884EC5; Tue, 25 Apr 2023 14:06:08 +0000 (UTC) Received: from p1.luc.cera.cz.com (unknown [10.45.226.81]) by smtp.corp.redhat.com (Postfix) with ESMTP id 07EB840C2064; Tue, 25 Apr 2023 14:06:05 +0000 (UTC) From: Ivan Vecera <ivecera@redhat.com> To: netdev@vger.kernel.org Cc: Jamal Hadi Salim <jhs@mojatatu.com>, Cong Wang <xiyou.wangcong@gmail.com>, Jiri Pirko <jiri@resnulli.us>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Simon Horman <simon.horman@corigine.com>, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>, Paul Blakey <paulb@nvidia.com>, linux-kernel@vger.kernel.org (open list) Subject: [PATCH net] net/sched: flower: Fix wrong handle assignment during filter change Date: Tue, 25 Apr 2023 16:06:04 +0200 Message-Id: <20230425140604.169881-1-ivecera@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764158802463864335?= X-GMAIL-MSGID: =?utf-8?q?1764158802463864335?= |
Series |
[net] net/sched: flower: Fix wrong handle assignment during filter change
|
|
Commit Message
Ivan Vecera
April 25, 2023, 2:06 p.m. UTC
Commit 08a0063df3ae ("net/sched: flower: Move filter handle initialization
earlier") moved filter handle initialization but an assignment of
the handle to fnew->handle is done regardless of fold value. This is wrong
because if fold != NULL (so fold->handle == handle) no new handle is
allocated and passed handle is assigned to fnew->handle. Then if any
subsequent action in fl_change() fails then the handle value is
removed from IDR that is incorrect as we will have still valid old filter
instance with handle that is not present in IDR.
Fix this issue by moving the assignment so it is done only when passed
fold == NULL.
Prior the patch:
[root@machine tc-testing]# ./tdc.py -d enp1s0f0np0 -e 14be
Test 14be: Concurrently replace same range of 100k flower filters from 10 tc instances
exit: 123
exit: 0
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
Command failed tmp/replace_6:1885
All test results:
1..1
not ok 1 14be - Concurrently replace same range of 100k flower filters from 10 tc instances
Command exited with 123, expected 0
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
Command failed tmp/replace_6:1885
After the patch:
[root@machine tc-testing]# ./tdc.py -d enp1s0f0np0 -e 14be
Test 14be: Concurrently replace same range of 100k flower filters from 10 tc instances
All test results:
1..1
ok 1 14be - Concurrently replace same range of 100k flower filters from 10 tc instances
Fixes: 08a0063df3ae ("net/sched: flower: Move filter handle initialization earlier")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
net/sched/cls_flower.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Apr 25, 2023 at 04:06:04PM +0200, Ivan Vecera wrote: > Commit 08a0063df3ae ("net/sched: flower: Move filter handle initialization > earlier") moved filter handle initialization but an assignment of > the handle to fnew->handle is done regardless of fold value. This is wrong > because if fold != NULL (so fold->handle == handle) no new handle is > allocated and passed handle is assigned to fnew->handle. Then if any > subsequent action in fl_change() fails then the handle value is > removed from IDR that is incorrect as we will have still valid old filter > instance with handle that is not present in IDR. > Fix this issue by moving the assignment so it is done only when passed > fold == NULL. > > Prior the patch: > [root@machine tc-testing]# ./tdc.py -d enp1s0f0np0 -e 14be > Test 14be: Concurrently replace same range of 100k flower filters from 10 tc instances > exit: 123 > exit: 0 > RTNETLINK answers: Invalid argument > We have an error talking to the kernel > Command failed tmp/replace_6:1885 > > > All test results: > > 1..1 > not ok 1 14be - Concurrently replace same range of 100k flower filters from 10 tc instances > Command exited with 123, expected 0 > RTNETLINK answers: Invalid argument > We have an error talking to the kernel > Command failed tmp/replace_6:1885 > > After the patch: > [root@machine tc-testing]# ./tdc.py -d enp1s0f0np0 -e 14be > Test 14be: Concurrently replace same range of 100k flower filters from 10 tc instances > > All test results: > > 1..1 > ok 1 14be - Concurrently replace same range of 100k flower filters from 10 tc instances > > Fixes: 08a0063df3ae ("net/sched: flower: Move filter handle initialization earlier") > Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com>
Hello: This patch was applied to netdev/net.git (main) by Paolo Abeni <pabeni@redhat.com>: On Tue, 25 Apr 2023 16:06:04 +0200 you wrote: > Commit 08a0063df3ae ("net/sched: flower: Move filter handle initialization > earlier") moved filter handle initialization but an assignment of > the handle to fnew->handle is done regardless of fold value. This is wrong > because if fold != NULL (so fold->handle == handle) no new handle is > allocated and passed handle is assigned to fnew->handle. Then if any > subsequent action in fl_change() fails then the handle value is > removed from IDR that is incorrect as we will have still valid old filter > instance with handle that is not present in IDR. > Fix this issue by moving the assignment so it is done only when passed > fold == NULL. > > [...] Here is the summary with links: - [net] net/sched: flower: Fix wrong handle assignment during filter change https://git.kernel.org/netdev/net/c/32eff6bacec2 You are awesome, thank you!
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c index 475fe222a855..fa6c2bb0b626 100644 --- a/net/sched/cls_flower.c +++ b/net/sched/cls_flower.c @@ -2231,8 +2231,8 @@ static int fl_change(struct net *net, struct sk_buff *in_skb, kfree(fnew); goto errout_tb; } + fnew->handle = handle; } - fnew->handle = handle; err = tcf_exts_init_ex(&fnew->exts, net, TCA_FLOWER_ACT, 0, tp, handle, !tc_skip_hw(fnew->flags));