DPDK patches and discussions
 help / color / mirror / Atom feed
From: Harman Kalra <hkalra@marvell.com>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	John Daley <johndale@cisco.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	Yuying Zhang <Yuying.Zhang@intel.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Qiming Yang <qiming.yang@intel.com>,
	Qi Zhang <qi.z.zhang@intel.com>, Wenjun Wu <wenjun1.wu@intel.com>,
	Dariusz Sosnowski <dsosnowski@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Ori Kam <orika@nvidia.com>, Suanming Mou <suanmingm@nvidia.com>,
	Matan Azrad <matan@nvidia.com>,
	Chaoyong He <chaoyong.he@corigine.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@amd.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [EXT] Re: [PATCH 1/2] ethdev: parsing multiple representor devargs string
Date: Fri, 12 Jan 2024 09:37:10 +0000	[thread overview]
Message-ID: <BN9PR18MB42041DDEBCC6224C4F62E0FCC56F2@BN9PR18MB4204.namprd18.prod.outlook.com> (raw)
In-Reply-To: <31463941-bfaf-4170-9889-90a860cea4ba@oktetlabs.ru>

Hi Andrew

Thanks for review
Please find response inline

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Friday, January 12, 2024 12:56 PM
> To: Harman Kalra <hkalra@marvell.com>; Ajit Khaparde
> <ajit.khaparde@broadcom.com>; Somnath Kotur
> <somnath.kotur@broadcom.com>; John Daley <johndale@cisco.com>;
> Hyong Youb Kim <hyonkim@cisco.com>; Yuying Zhang
> <Yuying.Zhang@intel.com>; Beilei Xing <beilei.xing@intel.com>; Qiming Yang
> <qiming.yang@intel.com>; Qi Zhang <qi.z.zhang@intel.com>; Wenjun Wu
> <wenjun1.wu@intel.com>; Dariusz Sosnowski <dsosnowski@nvidia.com>;
> Viacheslav Ovsiienko <viacheslavo@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan
> Azrad <matan@nvidia.com>; Chaoyong He <chaoyong.he@corigine.com>;
> Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>
> Cc: dev@dpdk.org
> Subject: [EXT] Re: [PATCH 1/2] ethdev: parsing multiple representor devargs
> string
> 
> External Email
> 
> ----------------------------------------------------------------------
> On 1/11/24 09:44, Harman Kalra wrote:
> > Adding support for parsing multiple representor devargs strings passed
> > to a PCI BDF. There may be scenario where port representors for
> > various PFs or VFs under PFs are required and all these are
> > representor ports shall be backed by single pci device. In such case
> > port representors can be created using devargs string:
> > <PCI
> > BDF>,representor=pf[0-1],representor=pf2vf[1,2-3],representor=[4-5]
> >
> > Signed-off-by: Harman Kalra <hkalra@marvell.com>
> 
> [snip]
> 
> > diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c
> > index bd917a15fc..62a06b75a2 100644
> > --- a/lib/ethdev/ethdev_driver.c
> > +++ b/lib/ethdev/ethdev_driver.c
> > @@ -470,15 +470,14 @@ eth_dev_devargs_tokenise(struct rte_kvargs
> *arglist, const char *str_in)
> >   }
> >
> >   int
> > -rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs
> > *eth_da)
> > +rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs
> > +*eth_devargs)
> >   {
> > -	struct rte_kvargs args;
> > +	struct rte_eth_devargs *eth_da;
> >   	struct rte_kvargs_pair *pair;
> > -	unsigned int i;
> > +	struct rte_kvargs args;
> > +	unsigned int i, j = 0;
> 
> Please, avoid multiple variable in one line declaration with initialization. It is
> too error prone. Also j is a bad name here. It is not a loop counter or
> seomthing like this.
> Maybe 'parsed' or 'devargs_parsed'?

Sure, will replace 'j' with a better name.

> 
> >   	int result = 0;
> >
> > -	memset(eth_da, 0, sizeof(*eth_da));
> > -
> >   	result = eth_dev_devargs_tokenise(&args, dargs);
> >   	if (result < 0)
> >   		goto parse_cleanup;
> > @@ -486,18 +485,16 @@ rte_eth_devargs_parse(const char *dargs, struct
> rte_eth_devargs *eth_da)
> >   	for (i = 0; i < args.count; i++) {
> >   		pair = &args.pairs[i];
> >   		if (strcmp("representor", pair->key) == 0) {
> > -			if (eth_da->type != RTE_ETH_REPRESENTOR_NONE) {
> > -				RTE_ETHDEV_LOG_LINE(ERR, "duplicated
> representor key: %s",
> > -					dargs);
> > -				result = -1;
> > -				goto parse_cleanup;
> > -			}
> > +			eth_da = &eth_devargs[j];
> > +			memset(eth_da, 0, sizeof(*eth_da));
> >   			result = rte_eth_devargs_parse_representor_ports(
> >   					pair->value, eth_da);
> >   			if (result < 0)
> >   				goto parse_cleanup;
> > +			j++;
> >   		}
> >   	}
> > +	result = (int)j;
> >
> >   parse_cleanup:
> >   	free(args.str);
> > diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> > index b482cd12bb..6f4f1a1606 100644
> > --- a/lib/ethdev/ethdev_driver.h
> > +++ b/lib/ethdev/ethdev_driver.h
> > @@ -1800,10 +1800,10 @@ rte_eth_representor_id_get(uint16_t port_id,
> >    * @param devargs
> >    *  device arguments
> >    * @param eth_devargs
> > - *  parsed ethdev specific arguments.
> > + *  contiguous memory populated with parsed ethdev specific arguments.
> 
> Caller must provide information about array size. Right now you simply
> introduce out-of-bound array access.
> All drivers just provide one entry and if I pass many-many devargs I can write
> far beyond that location and corrupt stack.

We thought of adding an additional third argument to the API:
int rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs *eth_devargs, uint8_t nb_da);

Later skipped just with an intention to have minimal changes to existing driver calls.
But yes, stack corruption case may happen without passing array size.

Will update the implementation as per above protype with 3 args.

@All, any thoughts on this??

Thanks
Harman


> 
> >    *
> >    * @return
> > - *   Negative errno value on error, 0 on success.
> > + *   Negative errno value on error, no of devargs parsed on success.
> >    */
> >   __rte_internal
> >   int


  reply	other threads:[~2024-01-12  9:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11  6:44 [PATCH 0/2] multiple representors in one device Harman Kalra
2024-01-11  6:44 ` [PATCH 1/2] ethdev: parsing multiple representor devargs string Harman Kalra
2024-01-12  7:25   ` Andrew Rybchenko
2024-01-12  9:37     ` Harman Kalra [this message]
2024-01-12 12:42   ` David Marchand
2024-01-15 16:01     ` [EXT] " Harman Kalra
2024-01-11  6:44 ` [PATCH 2/2] doc: multiple representors in one device Harman Kalra
2024-01-12  7:26   ` Andrew Rybchenko
2024-01-15 16:01     ` [EXT] " Harman Kalra
2024-01-15 15:57 ` [PATCH v2 0/1] " Harman Kalra
2024-01-15 15:57   ` [PATCH v2 1/1] ethdev: parsing multiple representor devargs string Harman Kalra
2024-01-16  9:55 ` [PATCH v3 0/1] multiple representors in one device Harman Kalra
2024-01-16  9:55   ` [PATCH v3 1/1] ethdev: parsing multiple representor devargs string Harman Kalra
2024-01-17  8:47     ` Andrew Rybchenko
2024-01-21 19:30       ` [EXT] " Harman Kalra
2024-01-21 19:19 ` [PATCH v4 0/1] multiple representors in one device Harman Kalra
2024-01-21 19:19   ` [PATCH v4 1/1] ethdev: parsing multiple representor devargs string Harman Kalra
2024-01-22  1:13     ` Chaoyong He
2024-01-22  9:07       ` Harman Kalra
2024-01-22 10:10         ` Chaoyong He
2024-01-25  5:28     ` Harman Kalra
2024-01-26 13:43     ` Ferruh Yigit
2024-01-29 18:20       ` [EXT] " Harman Kalra
2024-01-30 23:09         ` Ferruh Yigit
2024-02-01 10:10           ` Harman Kalra
2024-02-01 10:02 ` [PATCH v5 0/2] multiple representors in one device Harman Kalra
2024-02-01 10:02   ` [PATCH v5 1/2] ethdev: parsing multiple representor devargs string Harman Kalra
2024-02-01 10:02   ` [PATCH v5 2/2] test/devargs: add eth devargs parse cases Harman Kalra
2024-02-01 18:35   ` [PATCH v5 0/2] multiple representors in one device Ferruh Yigit

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=BN9PR18MB42041DDEBCC6224C4F62E0FCC56F2@BN9PR18MB4204.namprd18.prod.outlook.com \
    --to=hkalra@marvell.com \
    --cc=Yuying.Zhang@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=beilei.xing@intel.com \
    --cc=chaoyong.he@corigine.com \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=ferruh.yigit@amd.com \
    --cc=hyonkim@cisco.com \
    --cc=johndale@cisco.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=suanmingm@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=wenjun1.wu@intel.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).