DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: fengchengwen <fengchengwen@huawei.com>,
	thomas@monjalon.net, ferruh.yigit@amd.com
Cc: dev@dpdk.org, stephen@networkplumber.org,
	Vijay Kumar Srivastava <vsrivast@xilinx.com>
Subject: Re: [PATCH v5 2/5] net/sfc: use new API to parse kvargs
Date: Tue, 7 Nov 2023 10:18:15 +0300	[thread overview]
Message-ID: <52756c58-7081-4393-9e3d-88a96e5a5c4b@oktetlabs.ru> (raw)
In-Reply-To: <b9cc5b70-0b15-58c4-4a54-73cb0d46bb3c@huawei.com>

On 11/6/23 15:29, fengchengwen wrote:
> Hi Andrew,
> 
> On 2023/11/6 18:28, Andrew Rybchenko wrote:
>> On 11/6/23 10:31, Chengwen Feng wrote:
>>> The sfc_kvargs_process() and sfc_efx_dev_class_get() function could
>>> handle both key=value and only-key, so they should use
>>> rte_kvargs_process_opt() instead of rte_kvargs_process() to parse.
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> ---
>>>    drivers/common/sfc_efx/sfc_efx.c | 4 ++--
>>>    drivers/net/sfc/sfc_kvargs.c     | 2 +-
>>>    2 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/common/sfc_efx/sfc_efx.c b/drivers/common/sfc_efx/sfc_efx.c
>>> index 2dc5545760..3ebac909f1 100644
>>> --- a/drivers/common/sfc_efx/sfc_efx.c
>>> +++ b/drivers/common/sfc_efx/sfc_efx.c
>>> @@ -52,8 +52,8 @@ sfc_efx_dev_class_get(struct rte_devargs *devargs)
>>>            return dev_class;
>>>          if (rte_kvargs_count(kvargs, RTE_DEVARGS_KEY_CLASS) != 0) {
>>> -        rte_kvargs_process(kvargs, RTE_DEVARGS_KEY_CLASS,
>>> -                   sfc_efx_kvarg_dev_class_handler, &dev_class);
>>> +        rte_kvargs_process_opt(kvargs, RTE_DEVARGS_KEY_CLASS,
>>> +                       sfc_efx_kvarg_dev_class_handler, &dev_class);
>>
>> LGTM from code point of view, but I'm not sure that I understand the
>> idea behind handling NULL value in sfc_efx_kvarg_dev_class_handler().
>>
>> Cc: Vijay
>>
>>>        }
>>>          rte_kvargs_free(kvargs);
>>> diff --git a/drivers/net/sfc/sfc_kvargs.c b/drivers/net/sfc/sfc_kvargs.c
>>> index 783cb43ae6..24bb896179 100644
>>> --- a/drivers/net/sfc/sfc_kvargs.c
>>> +++ b/drivers/net/sfc/sfc_kvargs.c
>>> @@ -70,7 +70,7 @@ sfc_kvargs_process(struct sfc_adapter *sa, const char *key_match,
>>>        if (sa->kvargs == NULL)
>>>            return 0;
>>>    -    return -rte_kvargs_process(sa->kvargs, key_match, handler, opaque_arg);
>>> +    return -rte_kvargs_process_opt(sa->kvargs, key_match, handler, opaque_arg);
>>
>> It looks wrong to me since many handlers do not handle NULL string gracefully. As I understand some handlers where fixed to avoid crash
>> and correct fix would be to keep  rte_kvargs_process() and remove
>> unnecessary checks for NULL string value.
> 
> The scope is large, I suggest creates a new patchset later which remove unnecessary checks for NULL string value.

I just want to highlight that it will not make this patch correct. So,

Nack

> 
>>
>>>    }
>>>      int
>>
>> .


  reply	other threads:[~2023-11-07  7:18 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 12:48 [PATCH 0/5] fix segment fault when parse args Chengwen Feng
2023-03-14 12:48 ` [PATCH 1/5] app/pdump: " Chengwen Feng
2023-03-16 17:34   ` Ferruh Yigit
2023-03-14 12:48 ` [PATCH 2/5] net/memif: fix segment fault when parse devargs Chengwen Feng
2023-03-16 18:20   ` Ferruh Yigit
2023-03-14 12:48 ` [PATCH 3/5] net/pcap: " Chengwen Feng
2023-03-16 18:20   ` Ferruh Yigit
2023-03-14 12:48 ` [PATCH 4/5] net/ring: " Chengwen Feng
2023-03-14 12:48 ` [PATCH 5/5] net/sfc: " Chengwen Feng
2023-03-16 18:20   ` Ferruh Yigit
2023-03-16 18:18 ` [PATCH 0/5] fix segment fault when parse args Ferruh Yigit
2023-03-17  2:43   ` fengchengwen
2023-03-21 13:50     ` Ferruh Yigit
2023-03-22  1:15       ` fengchengwen
2023-03-22  8:53         ` Ferruh Yigit
2023-03-22 13:49           ` Thomas Monjalon
2023-03-23 11:58             ` fengchengwen
2023-03-23 12:51               ` Thomas Monjalon
2023-03-20  9:20 ` [PATCH v2 00/44] " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 01/44] app/pdump: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 02/44] ethdev: " Chengwen Feng
2023-04-09  8:10     ` Andrew Rybchenko
2023-03-20  9:20   ` [PATCH v2 03/44] net/memif: fix segment fault when parse devargs Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 04/44] net/pcap: " Chengwen Feng
2023-07-04  3:04     ` Stephen Hemminger
2023-03-20  9:20   ` [PATCH v2 05/44] net/ring: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 06/44] net/sfc: " Chengwen Feng
2023-04-09  8:09     ` Andrew Rybchenko
2023-03-20  9:20   ` [PATCH v2 07/44] net/af_xdp: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 08/44] net/ark: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 09/44] net/cnxk: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 10/44] net/cxgbe: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 11/44] net/dpaa2: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 12/44] net/ena: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 13/44] net/enic: " Chengwen Feng
2023-03-20 21:37     ` John Daley (johndale)
2023-03-20  9:20   ` [PATCH v2 14/44] net/fm10k: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 15/44] net/i40e: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 16/44] net/iavf: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 17/44] net/ice: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 18/44] net/idpf: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 19/44] net/ionic: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 20/44] net/mana: " Chengwen Feng
2023-03-21 22:19     ` Long Li
2023-03-20  9:20   ` [PATCH v2 21/44] net/mlx4: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 22/44] net/mvneta: " Chengwen Feng
2023-03-20  9:33     ` [EXT] " Liron Himi
2023-03-20  9:20   ` [PATCH v2 23/44] net/mvpp2: " Chengwen Feng
2023-03-20  9:33     ` [EXT] " Liron Himi
2023-03-20  9:20   ` [PATCH v2 24/44] net/netvsc: " Chengwen Feng
2023-03-21 22:20     ` Long Li
2023-07-04  3:02     ` Stephen Hemminger
2023-03-20  9:20   ` [PATCH v2 25/44] net/octeontx: " Chengwen Feng
2023-04-12  7:54     ` [EXT] " Harman Kalra
2023-03-20  9:20   ` [PATCH v2 26/44] net/pfe: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 27/44] net/qede: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 28/44] baseband/la12xx: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 29/44] bus/pci: fix segment fault when parse args Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 30/44] common/mlx5: fix segment fault when parse devargs Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 31/44] crypto/cnxk: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 32/44] crypto/dpaa_sec: " Chengwen Feng
2023-03-20  9:20   ` [PATCH v2 33/44] crypto/dpaa2_sec: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 34/44] crypto/mvsam: " Chengwen Feng
2023-03-20  9:33     ` [EXT] " Liron Himi
2023-03-20  9:21   ` [PATCH v2 35/44] crypto/scheduler: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 36/44] dma/dpaa2: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 37/44] event/cnxk: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 38/44] event/dlb2: " Chengwen Feng
2023-03-24 16:26     ` Sevincer, Abdullah
2023-03-20  9:21   ` [PATCH v2 39/44] event/dpaa: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 40/44] event/octeontx: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 41/44] event/opdl: " Chengwen Feng
2023-03-23 13:48     ` Liang Ma
2023-03-20  9:21   ` [PATCH v2 42/44] event/sw: " Chengwen Feng
2023-03-20 11:58     ` Van Haaren, Harry
2023-03-20  9:21   ` [PATCH v2 43/44] mempool/cnxk: " Chengwen Feng
2023-03-20  9:21   ` [PATCH v2 44/44] raw/cnxk_gpio: " Chengwen Feng
2023-04-15  1:38   ` [PATCH v2 00/44] fix segment fault when parse args fengchengwen
2023-04-17 16:37     ` Ferruh Yigit
2023-10-31 20:46       ` Stephen Hemminger
2023-10-31 20:58 ` [RFC] kvargs: don't pass parse handler a NULL pointer Stephen Hemminger
2023-11-01  1:16   ` fengchengwen
2023-11-03  7:38 ` [PATCH v3 0/5] fix segment fault when parse args Chengwen Feng
2023-11-03  7:38   ` [PATCH v3 1/5] kvargs: add one new process API Chengwen Feng
2023-11-03 13:09     ` Ferruh Yigit
2023-11-05  5:55       ` fengchengwen
2023-11-03  7:38   ` [PATCH v3 2/5] net/af_packet: use new API to parse kvargs Chengwen Feng
2023-11-03 13:11     ` Ferruh Yigit
2023-11-05  5:56       ` fengchengwen
2023-11-03  7:38   ` [PATCH v3 3/5] net/sfc: " Chengwen Feng
2023-11-03 13:23     ` Ferruh Yigit
2023-11-03  7:38   ` [PATCH v3 4/5] net/tap: " Chengwen Feng
2023-11-03 13:34     ` Ferruh Yigit
2023-11-05  5:57       ` fengchengwen
2023-11-03  7:38   ` [PATCH v3 5/5] net/mvneta: fix possible out-of-bounds write Chengwen Feng
2023-11-03 13:39     ` Ferruh Yigit
2023-11-03 13:41   ` [PATCH v3 0/5] fix segment fault when parse args Ferruh Yigit
2023-11-05  5:50     ` fengchengwen
2023-11-05  5:45 ` [PATCH v4 " Chengwen Feng
2023-11-05  5:45   ` [PATCH v4 1/5] kvargs: add one new process API Chengwen Feng
2023-11-06  3:18     ` Stephen Hemminger
2023-11-06  7:13       ` fengchengwen
2023-11-06 16:19         ` Stephen Hemminger
2023-11-07  3:21           ` fengchengwen
2023-11-05  5:45   ` [PATCH v4 2/5] net/sfc: use new API to parse kvargs Chengwen Feng
2023-11-05  5:45   ` [PATCH v4 3/5] net/tap: " Chengwen Feng
2023-11-05  5:45   ` [PATCH v4 4/5] common/nfp: " Chengwen Feng
2023-11-06  3:19     ` Stephen Hemminger
2023-11-06  7:22       ` fengchengwen
2023-11-05  5:45   ` [PATCH v4 5/5] net/mvneta: fix possible out-of-bounds write Chengwen Feng
2023-11-06  7:31 ` [PATCH v5 0/5] fix segment fault when parse args Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 1/5] kvargs: add one new process API Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 2/5] net/sfc: use new API to parse kvargs Chengwen Feng
2023-11-06 10:28     ` Andrew Rybchenko
2023-11-06 12:29       ` fengchengwen
2023-11-07  7:18         ` Andrew Rybchenko [this message]
2023-11-06  7:31   ` [PATCH v5 3/5] net/tap: " Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 4/5] common/nfp: " Chengwen Feng
2023-11-06  7:31   ` [PATCH v5 5/5] net/mvneta: fix possible out-of-bounds write Chengwen Feng
2023-11-21  2:11     ` lihuisong (C)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52756c58-7081-4393-9e3d-88a96e5a5c4b@oktetlabs.ru \
    --to=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=ferruh.yigit@amd.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=vsrivast@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).