From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EDA4142B24; Tue, 16 May 2023 17:12:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DF3F54114A; Tue, 16 May 2023 17:12:10 +0200 (CEST) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id D9A524114A for ; Tue, 16 May 2023 17:12:09 +0200 (CEST) Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1aad5245571so98454125ad.1 for ; Tue, 16 May 2023 08:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1684249929; x=1686841929; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=8v/sehI6bWeI6pIWPpXlPZJlPvBJfVwAoTx/tyakA2I=; b=g/fxvg7BNNh2PpjWcj07IKHLiM5YjM1a7j95JEf1YeAyWYYyH39FmOtn9jF4+gMGi8 9ui0+PossH3nEjxeWvnW6dtoWC9CjfRe4zjII1Nh4BX2sxIXqyBXVJg0wwBSIxbNRyyz nZmApdSU4Ls6g5DtgSB8ysdaC1y3jXr9OHNctrs43tDUnKQCWBT9ybI1Yy7rJ7gFDFUA S21Ivkky8ryGg3seuJE/1HYK3A1OVscyTs+t4JNqJ8tdAmfhiixBpa7AXoHJxdUUKa6P 4tHsGJcmW6J0RfZeeB/CQoXCS3w3FqZTSpqcxWcN56l6SRR6/YKCQBZNmSm+4ODdIbY2 0fOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684249929; x=1686841929; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8v/sehI6bWeI6pIWPpXlPZJlPvBJfVwAoTx/tyakA2I=; b=BvAir9B6x//ykfAxQN4obxV/L5D1AQ/kPS6RCeuxyVn6/uwQGyZh/OkadRs5ECDXUt KHkLclsYzPbvzMb/dP/qD+nb/rUcpCIB9PW/XDXun+IyIKTJ6nCVg0ZbxWGM3k6jEMdF d4zydnGMHIcDFemhrYt3vVVYmCuFYRgMzk95uRT81VquMm00doBif/O+JzR6Ek5N7ntw h7QKK1gQKiIyvnyMtS9aTXW/rKgpExc5ZbHClKXz7zB7YilSRq2gc+J7MniYxXxfaCch kWsBtA4a1gLVhyWOf4v7ihWQuk0bGT1lYRzNNkN1gx+4BNgI+8i8ydebAMgYilgofTiS vjWg== X-Gm-Message-State: AC+VfDwDHNtLAKmZiJDL3Evrlv83sMhVOACgN2GMuv7uhgnIMiD14FI/ 2sqvr0Un70nCUyl0/rZRxa3IIA== X-Google-Smtp-Source: ACHHUZ5VU4ChJw5sU7cBg1TDbPKeKfu6aqBECVkSljfRpBb+AjYxN3WbSBzj9+x99hs4VGWXq70Nig== X-Received: by 2002:a17:903:484:b0:1ab:267e:2f2d with SMTP id jj4-20020a170903048400b001ab267e2f2dmr37195768plb.48.1684249929045; Tue, 16 May 2023 08:12:09 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id u4-20020a170902e5c400b001ae197fdbb2sm4544977plf.274.2023.05.16.08.12.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 08:12:08 -0700 (PDT) Date: Tue, 16 May 2023 08:12:06 -0700 From: Stephen Hemminger To: Dengdui Huang Cc: , , Subject: Re: [PATCH] app/testpmd: fix segment fault with invalid queue id Message-ID: <20230516081206.792072d0@hermes.local> In-Reply-To: <20230516110021.1801443-1-huangdengdui@huawei.com> References: <20230516110021.1801443-1-huangdengdui@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 16 May 2023 19:00:21 +0800 Dengdui Huang wrote: > When input queue id is invalid, it will lead to > Segmentation fault, like: > > dpdk-testpmd -a 0000:01:00.0 -- -i > testpmd> show port 0 txq/rxq 99 desc 0 status > Segmentation fault > > dpdk-testpmd -a 0000:01:00.0 -- -i > testpmd> show port 0 rxq 99 desc used count > Segmentation fault > > This patch fixes it. > > In addition, this patch add the check for the offset > of the descriptor in case of other anomalies. > > Fixes: fae9aa717d6c ("app/testpmd: support checking descriptor status") > Fixes: 3f9acb5c83bb ("ethdev: avoid non-dataplane checks in Rx queue count") > Cc: stable@dpdk.org > > Signed-off-by: Dengdui Huang What is the backtrace and device driver? The problem is that other users besides testpmd might hit same problem. It would make sense to have a function to test for valid rx and tx queue id in rte_ethdev. Similar to existing rte_eth_dev_is_valid_port() rather than open coding it. Maybe rte_eth_dev_is_valid_rxq(port_id, queue_id)? here was talk that the existing rx queue descriptor status is racy, and unused by any real application; and therefore would be good candidate for future removal.