Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp439857pxj; Wed, 2 Jun 2021 03:02:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwppcnHC9NqoT9glNZNKD5LERqPkgZOUCGBuUJG2WLffB2L/E1AfuveQVHzNjymo1lwUepm X-Received: by 2002:a17:906:489:: with SMTP id f9mr15366503eja.508.1622628169082; Wed, 02 Jun 2021 03:02:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622628169; cv=none; d=google.com; s=arc-20160816; b=D9qmU9hpJpwDE2Bai6akm1XQJd/FpY6G6kKRyJgGod6RAs5AZdvG78Q5rLFUx6PhDq JouFvRRNlK0+kJtAwxAhz2hCcX8TMIggLMOA8Jw93Nc7btVJMeDHTLKQ9niLuuyKnylH nk8mQAxyUvEQ+ku6AF6x4Z307j3jQgn+AXccZx7ndoemzvirfRlokoUW5ecilL/+ocRS lQRIVoIANEnUPDWAoZrF9N1gNe1umi3SRSHuwfnlyttPJuGb+023WdUt78acOs//f+Kt LK8EvGoGPIoAjXQ7vYeOypkDWmUTmgzO0+/h09bseY8EK41b9wDQ62cm/2uhhdJCDpnH 3nJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=LOZZvRb1HqjAeC8tqISJRRhXj+yb+V0HmK5v2m2FAgI=; b=NlCTi920Spd1GmqFbJWMfJ9GBaWvaNqA7RtQsaXpfYEe8iOrEcoVGzP+4jrdfyk2F1 XVsLLcCypLRClozJBjVVmPUTTFtLke9lcgYWAXguhEhJo4YHR5jniLD/3i+nbjYxvmRC MQYU/AIpDBHpov0c2Jg4cQzryhLnNY8OWh8XdlNrjRoa45R1blZy1eojvWrVjb7Q9DcL Pcg5h2AmdmoWgRSbLIzeT3oFdut8A428REZn3lVGHEUVoQqilt/d0i/QTDjwX9x2ReM2 c4cd6d/XkkpQGL9O6gsnmuJ33kOQCQDwNNK+gyk8OEYrk9849gzdViMOGeIl4Tmts70i 5F+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k2si18787436ejs.648.2021.06.02.03.02.25; Wed, 02 Jun 2021 03:02:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231872AbhFBJ3K (ORCPT + 99 others); Wed, 2 Jun 2021 05:29:10 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:2959 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229618AbhFBJ3K (ORCPT ); Wed, 2 Jun 2021 05:29:10 -0400 Received: from dggeme766-chm.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Fw3Wb3fwbz68S4; Wed, 2 Jun 2021 17:24:27 +0800 (CST) Received: from [10.174.176.245] (10.174.176.245) by dggeme766-chm.china.huawei.com (10.3.19.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 2 Jun 2021 17:27:24 +0800 Subject: Re: [PATCH net-next] xsk: Return -EINVAL instead of -EBUSY after xsk_get_pool_from_qid() fails To: Magnus Karlsson CC: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , "Karlsson, Magnus" , Jonathan Lemon , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Network Development , bpf , open list References: <20210602031001.18656-1-wanghai38@huawei.com> From: "wanghai (M)" Message-ID: <73777ee0-bf6e-ccd2-015f-7539a2cd7687@huawei.com> Date: Wed, 2 Jun 2021 17:27:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.245] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggeme766-chm.china.huawei.com (10.3.19.112) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry, I misunderstood here, this is a faulty patch and no changes are needed here. Please ignore this patch 在 2021/6/2 16:29, Magnus Karlsson 写道: > On Wed, Jun 2, 2021 at 6:02 AM Wang Hai wrote: >> xsk_get_pool_from_qid() fails not because the device's queues are busy, >> but because the queue_id exceeds the current number of queues. >> So when it fails, it is better to return -EINVAL instead of -EBUSY. >> >> Signed-off-by: Wang Hai >> --- >> net/xdp/xsk_buff_pool.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c >> index 8de01aaac4a0..30ece117117a 100644 >> --- a/net/xdp/xsk_buff_pool.c >> +++ b/net/xdp/xsk_buff_pool.c >> @@ -135,7 +135,7 @@ int xp_assign_dev(struct xsk_buff_pool *pool, >> return -EINVAL; >> >> if (xsk_get_pool_from_qid(netdev, queue_id)) >> - return -EBUSY; >> + return -EINVAL; > I guess your intent here is to return -EINVAL only when the queue_id > is larger than the number of active queues. Yes, I just confirmed that this has been implemented in xp_assign_dev(). int xp_assign_dev() { ...     err = xsk_reg_pool_at_qid(netdev, pool, queue_id);     if (err)         return err;     //return -EINVAL; ... } > But this patch also > changes the return code when the queue id is already in use and in > that case we should continue to return -EBUSY. As this function is > used by a number of drivers, the easiest way to accomplish this is to > introduce a test for queue_id out of bounds before this if-statement > and return -EINVAL there. > >> pool->netdev = netdev; >> pool->queue_id = queue_id; >> -- >> 2.17.1 >> > . >