DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
@ 2020-10-07  9:01 Ciara Loftus
  2020-10-07  9:40 ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Ciara Loftus @ 2020-10-07  9:01 UTC (permalink / raw)
  To: dev; +Cc: Ciara Loftus

strncpy may leave the destination buffer not NULL terminated so use
snprintf instead.

Coverity issue: 362975
Fixes: 339b88c6a91f ("net/af_xdp: support multi-queue")
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
---
 drivers/net/af_xdp/rte_eth_af_xdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
index eaf2c9c873..52495cb8fb 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -1362,7 +1362,7 @@ xdp_get_channels_info(const char *if_name, int *max_queues,
 
 	channels.cmd = ETHTOOL_GCHANNELS;
 	ifr.ifr_data = (void *)&channels;
-	strncpy(ifr.ifr_name, if_name, IFNAMSIZ);
+	snprintf(ifr.ifr_name, IFNAMSIZ, "%s", if_name);
 	ret = ioctl(fd, SIOCETHTOOL, &ifr);
 	if (ret) {
 		if (errno == EOPNOTSUPP) {
-- 
2.17.1


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-07  9:01 [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy Ciara Loftus
@ 2020-10-07  9:40 ` Ferruh Yigit
  2020-10-07  9:51   ` Olivier Matz
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2020-10-07  9:40 UTC (permalink / raw)
  To: Ciara Loftus, dev

On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> strncpy may leave the destination buffer not NULL terminated so use
> snprintf instead.

What do you think using 'strlcpy'?

> 
> Coverity issue: 362975
> Fixes: 339b88c6a91f ("net/af_xdp: support multi-queue")
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
>   drivers/net/af_xdp/rte_eth_af_xdp.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
> index eaf2c9c873..52495cb8fb 100644
> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> @@ -1362,7 +1362,7 @@ xdp_get_channels_info(const char *if_name, int *max_queues,
>   
>   	channels.cmd = ETHTOOL_GCHANNELS;
>   	ifr.ifr_data = (void *)&channels;
> -	strncpy(ifr.ifr_name, if_name, IFNAMSIZ);
> +	snprintf(ifr.ifr_name, IFNAMSIZ, "%s", if_name);
>   	ret = ioctl(fd, SIOCETHTOOL, &ifr);
>   	if (ret) {
>   		if (errno == EOPNOTSUPP) {
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-07  9:40 ` Ferruh Yigit
@ 2020-10-07  9:51   ` Olivier Matz
  2020-10-07 10:26     ` Bruce Richardson
  0 siblings, 1 reply; 10+ messages in thread
From: Olivier Matz @ 2020-10-07  9:51 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Ciara Loftus, dev

On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
> On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> > strncpy may leave the destination buffer not NULL terminated so use
> > snprintf instead.
> 
> What do you think using 'strlcpy'?

Or even better, rte_strscpy()
https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761

> 
> > 
> > Coverity issue: 362975
> > Fixes: 339b88c6a91f ("net/af_xdp: support multi-queue")
> > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > ---
> >   drivers/net/af_xdp/rte_eth_af_xdp.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
> > index eaf2c9c873..52495cb8fb 100644
> > --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> > +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> > @@ -1362,7 +1362,7 @@ xdp_get_channels_info(const char *if_name, int *max_queues,
> >   	channels.cmd = ETHTOOL_GCHANNELS;
> >   	ifr.ifr_data = (void *)&channels;
> > -	strncpy(ifr.ifr_name, if_name, IFNAMSIZ);
> > +	snprintf(ifr.ifr_name, IFNAMSIZ, "%s", if_name);
> >   	ret = ioctl(fd, SIOCETHTOOL, &ifr);
> >   	if (ret) {
> >   		if (errno == EOPNOTSUPP) {
> > 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-07  9:51   ` Olivier Matz
@ 2020-10-07 10:26     ` Bruce Richardson
  2020-10-07 10:28       ` Bruce Richardson
  0 siblings, 1 reply; 10+ messages in thread
From: Bruce Richardson @ 2020-10-07 10:26 UTC (permalink / raw)
  To: Olivier Matz; +Cc: Ferruh Yigit, Ciara Loftus, dev

On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
> On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
> > On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> > > strncpy may leave the destination buffer not NULL terminated so use
> > > snprintf instead.
> > 
> > What do you think using 'strlcpy'?
> 
> Or even better, rte_strscpy()
> https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
> 
I think this is largely a matter of preference, and unless there is a good
reason not to, I tend towards strlcpy as the older and more common (till
now) interface. The main thing is just to use a function that will
guarantee dest is null-terminated here, and both strlcpy and strscpy meet
that criteria.

/Bruce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-07 10:26     ` Bruce Richardson
@ 2020-10-07 10:28       ` Bruce Richardson
  2020-10-07 11:45         ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Bruce Richardson @ 2020-10-07 10:28 UTC (permalink / raw)
  To: Olivier Matz; +Cc: Ferruh Yigit, Ciara Loftus, dev

On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
> On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
> > On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
> > > On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> > > > strncpy may leave the destination buffer not NULL terminated so use
> > > > snprintf instead.
> > > 
> > > What do you think using 'strlcpy'?
> > 
> > Or even better, rte_strscpy()
> > https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
> > 
> I think this is largely a matter of preference, and unless there is a good
> reason not to, I tend towards strlcpy as the older and more common (till
> now) interface. The main thing is just to use a function that will
> guarantee dest is null-terminated here, and both strlcpy and strscpy meet
> that criteria.
> 
I'd also add that strlcpy is more likely to be recognised by tools like
coverity, compared to rte_strscpy which is DPDK-specific.

/Bruce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-07 10:28       ` Bruce Richardson
@ 2020-10-07 11:45         ` Ferruh Yigit
  2020-10-09 10:36           ` Gaëtan Rivet
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2020-10-07 11:45 UTC (permalink / raw)
  To: Bruce Richardson, Olivier Matz; +Cc: Ciara Loftus, dev

On 10/7/2020 11:28 AM, Bruce Richardson wrote:
> On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
>> On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
>>> On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
>>>> On 10/7/2020 10:01 AM, Ciara Loftus wrote:
>>>>> strncpy may leave the destination buffer not NULL terminated so use
>>>>> snprintf instead.
>>>>
>>>> What do you think using 'strlcpy'?
>>>
>>> Or even better, rte_strscpy()
>>> https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
>>>
>> I think this is largely a matter of preference, and unless there is a good
>> reason not to, I tend towards strlcpy as the older and more common (till
>> now) interface. The main thing is just to use a function that will
>> guarantee dest is null-terminated here, and both strlcpy and strscpy meet
>> that criteria.
>>
> I'd also add that strlcpy is more likely to be recognised by tools like
> coverity, compared to rte_strscpy which is DPDK-specific.
> 

+1 to 'strlcpy'

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-07 11:45         ` Ferruh Yigit
@ 2020-10-09 10:36           ` Gaëtan Rivet
  2020-10-09 10:49             ` Bruce Richardson
  2020-10-09 10:59             ` Ferruh Yigit
  0 siblings, 2 replies; 10+ messages in thread
From: Gaëtan Rivet @ 2020-10-09 10:36 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Bruce Richardson, Olivier Matz, Ciara Loftus, dev

On 07/10/20 12:45 +0100, Ferruh Yigit wrote:
> On 10/7/2020 11:28 AM, Bruce Richardson wrote:
> > On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
> > > On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
> > > > On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
> > > > > On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> > > > > > strncpy may leave the destination buffer not NULL terminated so use
> > > > > > snprintf instead.
> > > > > 
> > > > > What do you think using 'strlcpy'?
> > > > 
> > > > Or even better, rte_strscpy()
> > > > https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
> > > > 
> > > I think this is largely a matter of preference, and unless there is a good
> > > reason not to, I tend towards strlcpy as the older and more common (till
> > > now) interface. The main thing is just to use a function that will
> > > guarantee dest is null-terminated here, and both strlcpy and strscpy meet
> > > that criteria.
> > > 
> > I'd also add that strlcpy is more likely to be recognised by tools like
> > coverity, compared to rte_strscpy which is DPDK-specific.
> > 
> 
> +1 to 'strlcpy'

Using strlcpy will be more recognized by static analyzer indeed.

But strscpy API is better:

* It helps checking string truncation by making it easier:

  if (strlcpy(dst, src, dstsize) >= dstsize)
        /* Dev + reviewer needs to think about using >= and not >, dstsize is
         * repeated so either dst is an array or it needs a dedicated variable.
         * Deal with truncation.
         */

  if (rte_strscpy(dst, src, dstsize) < 0)
        /* deal with truncation. */

* It is safer when dealing with unknown data source. strlcpy will always
  read all of src, because the API (uselessly) defines the return value
  to strlen(src).

Having yet another string copy function is contentious, but we can avoid
using worse API to please tools.

And detecting string truncation *is* helpful. String are used as IDs in
DPDK for some objects. Using strlcpy / snprintf at least protects from
buffer overflow, which is a bare minimum. A good implementation would
also warn the user about a config error / memory corruption happening
sooner.

In any case, sure to fix a sanity check strlcpy / snprintf will work.

Cheers,
-- 
Gaëtan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-09 10:36           ` Gaëtan Rivet
@ 2020-10-09 10:49             ` Bruce Richardson
  2020-10-09 10:59             ` Ferruh Yigit
  1 sibling, 0 replies; 10+ messages in thread
From: Bruce Richardson @ 2020-10-09 10:49 UTC (permalink / raw)
  To: Gaëtan Rivet; +Cc: Ferruh Yigit, Olivier Matz, Ciara Loftus, dev

On Fri, Oct 09, 2020 at 12:36:30PM +0200, Gaëtan Rivet wrote:
> On 07/10/20 12:45 +0100, Ferruh Yigit wrote:
> > On 10/7/2020 11:28 AM, Bruce Richardson wrote:
> > > On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
> > > > On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
> > > > > On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
> > > > > > On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> > > > > > > strncpy may leave the destination buffer not NULL terminated so use
> > > > > > > snprintf instead.
> > > > > > 
> > > > > > What do you think using 'strlcpy'?
> > > > > 
> > > > > Or even better, rte_strscpy()
> > > > > https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
> > > > > 
> > > > I think this is largely a matter of preference, and unless there is a good
> > > > reason not to, I tend towards strlcpy as the older and more common (till
> > > > now) interface. The main thing is just to use a function that will
> > > > guarantee dest is null-terminated here, and both strlcpy and strscpy meet
> > > > that criteria.
> > > > 
> > > I'd also add that strlcpy is more likely to be recognised by tools like
> > > coverity, compared to rte_strscpy which is DPDK-specific.
> > > 
> > 
> > +1 to 'strlcpy'
> 
> Using strlcpy will be more recognized by static analyzer indeed.
> 
> But strscpy API is better:
> 
> * It helps checking string truncation by making it easier:
> 
>   if (strlcpy(dst, src, dstsize) >= dstsize)
>         /* Dev + reviewer needs to think about using >= and not >, dstsize is
>          * repeated so either dst is an array or it needs a dedicated variable.
>          * Deal with truncation.
>          */
> 
>   if (rte_strscpy(dst, src, dstsize) < 0)
>         /* deal with truncation. */
> 
> * It is safer when dealing with unknown data source. strlcpy will always
>   read all of src, because the API (uselessly) defines the return value
>   to strlen(src).
> 
> Having yet another string copy function is contentious, but we can avoid
> using worse API to please tools.
> 
> And detecting string truncation *is* helpful. String are used as IDs in
> DPDK for some objects. Using strlcpy / snprintf at least protects from
> buffer overflow, which is a bare minimum. A good implementation would
> also warn the user about a config error / memory corruption happening
> sooner.
> 
> In any case, sure to fix a sanity check strlcpy / snprintf will work.
> 

Yes.

My main issue with strscpy right now is that it's got to be a DPDK-specific
function, since AFAIK it's defined in no standard C library, just in the
Linux kernel. If we get strscpy added to e.g. glibc, then we can see about
starting to use it - letting meson do the work of detect if it's present
and allowing us to define a fallback only in case it's not (i.e. as is done
with strlcpy).

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-09 10:36           ` Gaëtan Rivet
  2020-10-09 10:49             ` Bruce Richardson
@ 2020-10-09 10:59             ` Ferruh Yigit
  2020-10-09 16:37               ` Gaëtan Rivet
  1 sibling, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2020-10-09 10:59 UTC (permalink / raw)
  To: Gaëtan Rivet; +Cc: Bruce Richardson, Olivier Matz, Ciara Loftus, dev

On 10/9/2020 11:36 AM, Gaëtan Rivet wrote:
> On 07/10/20 12:45 +0100, Ferruh Yigit wrote:
>> On 10/7/2020 11:28 AM, Bruce Richardson wrote:
>>> On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
>>>> On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
>>>>> On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
>>>>>> On 10/7/2020 10:01 AM, Ciara Loftus wrote:
>>>>>>> strncpy may leave the destination buffer not NULL terminated so use
>>>>>>> snprintf instead.
>>>>>>
>>>>>> What do you think using 'strlcpy'?
>>>>>
>>>>> Or even better, rte_strscpy()
>>>>> https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
>>>>>
>>>> I think this is largely a matter of preference, and unless there is a good
>>>> reason not to, I tend towards strlcpy as the older and more common (till
>>>> now) interface. The main thing is just to use a function that will
>>>> guarantee dest is null-terminated here, and both strlcpy and strscpy meet
>>>> that criteria.
>>>>
>>> I'd also add that strlcpy is more likely to be recognised by tools like
>>> coverity, compared to rte_strscpy which is DPDK-specific.
>>>
>>
>> +1 to 'strlcpy'
> 
> Using strlcpy will be more recognized by static analyzer indeed.
> 
> But strscpy API is better:
> 
> * It helps checking string truncation by making it easier:
> 
>    if (strlcpy(dst, src, dstsize) >= dstsize)
>          /* Dev + reviewer needs to think about using >= and not >, dstsize is
>           * repeated so either dst is an array or it needs a dedicated variable.
>           * Deal with truncation.
>           */
> 
>    if (rte_strscpy(dst, src, dstsize) < 0)
>          /* deal with truncation. */
> 
> * It is safer when dealing with unknown data source. strlcpy will always
>    read all of src, because the API (uselessly) defines the return value
>    to strlen(src).
> 
> Having yet another string copy function is contentious, but we can avoid
> using worse API to please tools.
> 
> And detecting string truncation *is* helpful. String are used as IDs in
> DPDK for some objects. Using strlcpy / snprintf at least protects from
> buffer overflow, which is a bare minimum. A good implementation would
> also warn the user about a config error / memory corruption happening
> sooner.
> 
> In any case, sure to fix a sanity check strlcpy / snprintf will work.
> 

I also think 'strscpy' is better API, and we had similar discussion before [1] 
and the decision was to prefer 'strlcpy'.

[1] http://inbox.dpdk.org/dev/b800d417-c33d-af4e-b506-8f31ae919410@intel.com/#t

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy
  2020-10-09 10:59             ` Ferruh Yigit
@ 2020-10-09 16:37               ` Gaëtan Rivet
  0 siblings, 0 replies; 10+ messages in thread
From: Gaëtan Rivet @ 2020-10-09 16:37 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Bruce Richardson, Olivier Matz, Ciara Loftus, dev

On 09/10/20 11:59 +0100, Ferruh Yigit wrote:
> On 10/9/2020 11:36 AM, Gaëtan Rivet wrote:
> > On 07/10/20 12:45 +0100, Ferruh Yigit wrote:
> > > On 10/7/2020 11:28 AM, Bruce Richardson wrote:
> > > > On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
> > > > > On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
> > > > > > On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrote:
> > > > > > > On 10/7/2020 10:01 AM, Ciara Loftus wrote:
> > > > > > > > strncpy may leave the destination buffer not NULL terminated so use
> > > > > > > > snprintf instead.
> > > > > > > 
> > > > > > > What do you think using 'strlcpy'?
> > > > > > 
> > > > > > Or even better, rte_strscpy()
> > > > > > https://git.dpdk.org/dpdk/commit/?id=b0236c7cf761
> > > > > > 
> > > > > I think this is largely a matter of preference, and unless there is a good
> > > > > reason not to, I tend towards strlcpy as the older and more common (till
> > > > > now) interface. The main thing is just to use a function that will
> > > > > guarantee dest is null-terminated here, and both strlcpy and strscpy meet
> > > > > that criteria.
> > > > > 
> > > > I'd also add that strlcpy is more likely to be recognised by tools like
> > > > coverity, compared to rte_strscpy which is DPDK-specific.
> > > > 
> > > 
> > > +1 to 'strlcpy'
> > 
> > Using strlcpy will be more recognized by static analyzer indeed.
> > 
> > But strscpy API is better:
> > 
> > * It helps checking string truncation by making it easier:
> > 
> >    if (strlcpy(dst, src, dstsize) >= dstsize)
> >          /* Dev + reviewer needs to think about using >= and not >, dstsize is
> >           * repeated so either dst is an array or it needs a dedicated variable.
> >           * Deal with truncation.
> >           */
> > 
> >    if (rte_strscpy(dst, src, dstsize) < 0)
> >          /* deal with truncation. */
> > 
> > * It is safer when dealing with unknown data source. strlcpy will always
> >    read all of src, because the API (uselessly) defines the return value
> >    to strlen(src).
> > 
> > Having yet another string copy function is contentious, but we can avoid
> > using worse API to please tools.
> > 
> > And detecting string truncation *is* helpful. String are used as IDs in
> > DPDK for some objects. Using strlcpy / snprintf at least protects from
> > buffer overflow, which is a bare minimum. A good implementation would
> > also warn the user about a config error / memory corruption happening
> > sooner.
> > 
> > In any case, sure to fix a sanity check strlcpy / snprintf will work.
> > 
> 
> I also think 'strscpy' is better API, and we had similar discussion before
> [1] and the decision was to prefer 'strlcpy'.
> 
> [1] http://inbox.dpdk.org/dev/b800d417-c33d-af4e-b506-8f31ae919410@intel.com/#t

Good memory! I hadn't seen this thread, thanks.

-- 
Gaëtan

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-10-09 16:37 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-07  9:01 [dpdk-dev] [PATCH] net/af_xdp: use snprintf instead of strncpy Ciara Loftus
2020-10-07  9:40 ` Ferruh Yigit
2020-10-07  9:51   ` Olivier Matz
2020-10-07 10:26     ` Bruce Richardson
2020-10-07 10:28       ` Bruce Richardson
2020-10-07 11:45         ` Ferruh Yigit
2020-10-09 10:36           ` Gaëtan Rivet
2020-10-09 10:49             ` Bruce Richardson
2020-10-09 10:59             ` Ferruh Yigit
2020-10-09 16:37               ` Gaëtan Rivet

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).