Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2489808ybb; Mon, 30 Mar 2020 07:11:26 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtMYgDTn0YQOLoCDEl6IP/zAZoSCAHlzTyCDMnpI9iI/u4PD9kA6B0Xq8UXey0ER1m5xJMp X-Received: by 2002:aca:3889:: with SMTP id f131mr7226481oia.154.1585577486401; Mon, 30 Mar 2020 07:11:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585577486; cv=none; d=google.com; s=arc-20160816; b=1KeY/H+Gp9uGSsA1LKUQh6J0tEW3U17PcOv5hNXu7uq2uXVIZq/xpuIG20bKoEHX7X FRcL3nhClDmWoXB1F/RpDnqftmgwwXod5q+AwZgVNK6IZfwfCZ/RZTcNqLGwPJRJounb DEmhfR1Z2ZkKq7yTjNmnKrcaANLrpCo36kmhEdA7ud0RMjl0zuR3YYupdzf8h+xq4BWQ Tc1V+ykyuDHW67S9evm5EdIdEFEirvR1NUUNZAynRHcihAh8Ttz9fE8apiX+khXJyghc 9VGU/STRI2jGynxZbMzv7bO5ZIvFZ0erNa231VnXB/n1EIrWcxY95wpoxbWkwopTbSqt ySgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=W+kWQlCJg7TTScX4OMEMsH7Q1Fr+bmdpcHACupezV3E=; b=SRYa5oanfAYXKp7Q+kLfZKfjBGZ2y1AU+Uo+2xMO6qCheHLR59e3CtpGmpfIWkwGGY opYyvcPb9s2Y4u9Fnms+FLBrS78O+Q2hSjgrKnO01lxSxOPoIACyi8ZCF0PbtBvCU1bq SFlpOdEdPzSD3Nqzhe2NIDOo+PG3DUxp6xtUUoK/9FXGqHsFZlfQqmDdp+fLsqn/ke7c 9knNmr5Ldfmmuk58wx/twWBhKuzKdxN8WQ7SQI5wJSGqqK8xVmbacQpnVwaY4tOujJ80 o93NSeuX9Z9eHANXVqxTJWVUitFBTi55r0yHxfdNX97k6HzS5Cr674hFr/DNZKrtfEN1 AixA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 30si5994196oth.68.2020.03.30.07.11.07; Mon, 30 Mar 2020 07:11:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727800AbgC3OFr (ORCPT + 99 others); Mon, 30 Mar 2020 10:05:47 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:50000 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725978AbgC3OFr (ORCPT ); Mon, 30 Mar 2020 10:05:47 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id C7801625750368B4B8CA; Mon, 30 Mar 2020 22:05:34 +0800 (CST) Received: from [127.0.0.1] (10.173.223.234) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.487.0; Mon, 30 Mar 2020 22:05:32 +0800 Subject: Re: [PATCH net-next] xfrm: policy: Remove obsolete WARN while xfrm policy inserting To: Steffen Klassert References: <20200327123443.12408-1-yuehaibing@huawei.com> <20200328112302.GA13121@gauss3.secunet.de> CC: , , , , From: Yuehaibing Message-ID: <1d3596fb-c7e3-16c9-f48f-fe58e9a2569a@huawei.com> Date: Mon, 30 Mar 2020 22:05:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20200328112302.GA13121@gauss3.secunet.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.173.223.234] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/3/28 19:23, Steffen Klassert wrote: > On Fri, Mar 27, 2020 at 08:34:43PM +0800, YueHaibing wrote: >> Since commit 7cb8a93968e3 ("xfrm: Allow inserting policies with matching >> mark and different priorities"), we allow duplicate policies with >> different priority, this WARN is not needed any more. > > Can you please describe a bit more detailed why this warning > can't trigger anymore? No, this warning is triggered while detect a duplicate entry in the policy list regardless of the priority. If we insert policy like this: policy A (mark.v = 3475289, mark.m = 0, priority = 1) //A is inserted policy B (mark.v = 0, mark.m = 0, priority = 0) //B is inserted policy C (mark.v = 3475289, mark.m = 0, priority = 0) //C is inserted and B is deleted policy D (mark.v = 3475289, mark.m = 0, priority = 1) while finding delpol in xfrm_policy_insert_list, first round delpol is matched C, whose priority is less than D, so contiue the loop, then A is matched, WARN_ON is triggered. It seems the WARN is useless. > > Thanks! > >