malloc: fix size annotation for NUMA-aware realloc
Checks
Commit Message
__rte_alloc_size is mapped to compiler alloc_size attribute.
Quoting gcc documentation:
"""
alloc_size
The alloc_size attribute is used to tell the compiler that the
function return value points to memory, where the size is given by
one or two of the functions parameters. GCC uses this information
to improve the correctness of __builtin_object_size.
The function parameter(s) denoting the allocated size are specified
by one or two integer arguments supplied to the attribute.
The allocated size is either the value of the single function
argument specified or the product of the two function arguments
specified. Argument numbering starts at one.
"""
In rte_realloc_socket case, only 'size' matters.
Note: this has been spotted by Maxime trying to use rte_realloc_socket
and compiling with gcc 11.
Fixes: 17b347dab769 ("malloc: add alloc_size attribute to functions")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
lib/eal/include/rte_malloc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 6/10/21 2:09 PM, David Marchand wrote:
> __rte_alloc_size is mapped to compiler alloc_size attribute.
>
> Quoting gcc documentation:
> """
> alloc_size
> The alloc_size attribute is used to tell the compiler that the
> function return value points to memory, where the size is given by
> one or two of the functions parameters. GCC uses this information
> to improve the correctness of __builtin_object_size.
>
> The function parameter(s) denoting the allocated size are specified
> by one or two integer arguments supplied to the attribute.
> The allocated size is either the value of the single function
> argument specified or the product of the two function arguments
> specified. Argument numbering starts at one.
> """
>
> In rte_realloc_socket case, only 'size' matters.
>
> Note: this has been spotted by Maxime trying to use rte_realloc_socket
> and compiling with gcc 11.
>
> Fixes: 17b347dab769 ("malloc: add alloc_size attribute to functions")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> lib/eal/include/rte_malloc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/eal/include/rte_malloc.h b/lib/eal/include/rte_malloc.h
> index 3af64f8761..895bb6e849 100644
> --- a/lib/eal/include/rte_malloc.h
> +++ b/lib/eal/include/rte_malloc.h
> @@ -160,7 +160,7 @@ rte_realloc(void *ptr, size_t size, unsigned int align)
> __rte_experimental
> void *
> rte_realloc_socket(void *ptr, size_t size, unsigned int align, int socket)
> - __rte_alloc_size(2, 3);
> + __rte_alloc_size(2);
>
> /**
> * This function allocates memory from the huge-page area of memory. The memory
>
Tested-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Thanks!
Maxime
On Thu, Jun 10, 2021 at 2:09 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> __rte_alloc_size is mapped to compiler alloc_size attribute.
I get the following splat from dts.
I don't see how this patch could have an impact.
There is an odd mac address (00:00:00:00:51:14), so maybe a broken nic
/ firmware / forced mac address.
But I don't think it is the reason of the failure since other tests pass.
Can someone from DTS or net/i40e guys have a look?
Thanks.
10/06/2021 15:48:52 dut.172.18.0.20:
x86_64-native-linux-gcc/app/dpdk-testpmd -l 4,5 -n 6 -a 0000:18:00.0
-a 0000:3b:00.0 --file-prefix=dpdk_90027_20210610154417 -- -i
...
10/06/2021 15:49:03 dut.172.18.0.20: port stop all
10/06/2021 15:49:03 dut.172.18.0.20:
...
10/06/2021 15:49:03 dut.172.18.0.20: port config mtu 0 9000
10/06/2021 15:49:03 dut.172.18.0.20:
10/06/2021 15:49:03 dut.172.18.0.20: port config mtu 1 9000
10/06/2021 15:49:03 dut.172.18.0.20:
10/06/2021 15:49:03 dut.172.18.0.20: show port info 0
10/06/2021 15:49:03 dut.172.18.0.20:
...
10/06/2021 15:49:03 dut.172.18.0.20: port start all
10/06/2021 15:49:04 dut.172.18.0.20:
Port 0: 00:00:00:00:51:14
Port 1: 68:05:CA:34:88:48
Checking link statuses...
Done
10/06/2021 15:49:04 dut.172.18.0.20: set fwd mac
10/06/2021 15:49:04 dut.172.18.0.20:
10/06/2021 15:49:04 dut.172.18.0.20: start
10/06/2021 15:49:04 dut.172.18.0.20:
...
10/06/2021 15:49:04 tester: echo -n '' >
scapyResult.txt
10/06/2021 15:49:04 tester:
10/06/2021 15:49:04 tester: scapy
10/06/2021 15:49:04 tester: [39mINFO: Can't
import matplotlib. Won't be able to plot. [0m
[39mINFO: Can't import PyX. Won't be able to use psdump() or pdfdump(). [0m
[33m [1mWARNING: IPython not available. Using standard Python shell instead.
AutoCompletion, History are disabled. [0m [0m
[32m [1m [0m [34m [1m [0m
[32m [1m aSPY//YASa [0m [34m [1m [0m
[32m [1m apyyyyCY//////////YCa [0m [34m [1m | [0m
[32m [1m sY//////YSpcs scpCY//Pp [0m [34m [1m |
Welcome to Scapy [0m
[32m [1m ayp ayyyyyyySCP//Pp syY//C [0m [34m [1m |
Version 2.4.4 [0m
[32m [1m AYAsAYYYYYYYY///Ps cY//S [0m [34m [1m | [0m
[32m [1m pCCCCY//p cSSps y//Y [0m [34m [1m |
https://github.com/secdev/ [0m
[32m [1m SPPPP///a pP///AC//Y [0m [34m [1m | [0m
[32m [1m A//A cyP////C [0m [34m [1m | Have fun! [0m
[32m [1m p///Ac sC///a [0m [34m [1m | [0m
[32m [1m P////YCpc A//A [0m [34m [1m | Craft
me if you can. [0m
[32m [1m scccccp///pSP///p p//Y [0m [34m [1m |
-- IPv6 layer [0m
[32m [1m sY/////////y caa S//P [0m [34m [1m | [0m
[32m [1m cayCyayP//Ya pY/Ya [0m
[32m [1m sY/PsY////YCc aC//Yp [0m
[32m [1m sc sccaCY//PCypaapyCP//YSs [0m
[32m [1m spCPY//////YPSps [0m
[32m [1m ccaacs [0m
[32m [1m [0m
10/06/2021 15:49:06 tester: dutmac="00:00:00:00:51:14"
10/06/2021 15:49:06 tester: [34m [1m
10/06/2021 15:49:06 tester:
sendp(Ether(dst=dutmac,
src="52:00:00:00:00:00")/IP()/Raw(load="P"*8987), iface="enp134s0f0")
10/06/2021 15:49:06 tester: .
Sent 1 packets.
10/06/2021 15:49:08 tester: exit()
10/06/2021 15:49:09 tester:
10/06/2021 15:49:14 dut.172.18.0.20: show port stats 1
10/06/2021 15:49:14 dut.172.18.0.20:
######################## NIC statistics for port 1 ########################
RX-packets: 7 RX-missed: 0 RX-bytes: 770
RX-errors: 0
RX-nombuf: 0
TX-packets: 4 TX-errors: 0 TX-bytes: 440
Throughput (since last show)
Rx-pps: 0 Rx-bps: 352
Tx-pps: 0 Tx-bps: 352
############################################################################
10/06/2021 15:49:14 dut.172.18.0.20: show port stats 0
10/06/2021 15:49:14 dut.172.18.0.20:
######################## NIC statistics for port 0 ########################
RX-packets: 8 RX-missed: 0 RX-bytes: 9795
RX-errors: 0
RX-nombuf: 0
TX-packets: 4 TX-errors: 0 TX-bytes: 440
Throughput (since last show)
Rx-pps: 0 Rx-bps: 7736
Tx-pps: 0 Tx-bps: 352
############################################################################
10/06/2021 15:49:14 TestMtuUpdate: Test Case
test_mtu_checks_9000 Result FAILED: 'different numbers of packets sent
and received'
10/06/2021 15:49:14 dut.172.18.0.20: kill_all: called
by dut and prefix list has value.
10/06/2021 15:49:16 dut.172.18.0.20: Killed
On Fri, Jun 11, 2021 at 9:26 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Thu, Jun 10, 2021 at 2:09 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > __rte_alloc_size is mapped to compiler alloc_size attribute.
>
> I get the following splat from dts.
There is the exact same output in last night next-net-intel test:
https://lab.dpdk.org/results/dashboard/tarballs/15461/
On Thu, Jun 10, 2021 at 2:19 PM Maxime Coquelin <mcoqueli@redhat.com> wrote:
> > __rte_alloc_size is mapped to compiler alloc_size attribute.
> >
> > Quoting gcc documentation:
> > """
> > alloc_size
> > The alloc_size attribute is used to tell the compiler that the
> > function return value points to memory, where the size is given by
> > one or two of the functions parameters. GCC uses this information
> > to improve the correctness of __builtin_object_size.
> >
> > The function parameter(s) denoting the allocated size are specified
> > by one or two integer arguments supplied to the attribute.
> > The allocated size is either the value of the single function
> > argument specified or the product of the two function arguments
> > specified. Argument numbering starts at one.
> > """
> >
> > In rte_realloc_socket case, only 'size' matters.
> >
> > Note: this has been spotted by Maxime trying to use rte_realloc_socket
> > and compiling with gcc 11.
> >
> > Fixes: 17b347dab769 ("malloc: add alloc_size attribute to functions")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Applied.
That test suite has been disabled on the system. Someone of the Intel team
should be looking at it soon, since stats_checks also has similar issues.
On Fri, Jun 11, 2021 at 3:40 AM David Marchand <david.marchand@redhat.com>
wrote:
> On Fri, Jun 11, 2021 at 9:26 AM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Thu, Jun 10, 2021 at 2:09 PM David Marchand
> > <david.marchand@redhat.com> wrote:
> > >
> > > __rte_alloc_size is mapped to compiler alloc_size attribute.
> >
> > I get the following splat from dts.
>
> There is the exact same output in last night next-net-intel test:
> https://lab.dpdk.org/results/dashboard/tarballs/15461/
>
>
> --
> David Marchand
>
>
@@ -160,7 +160,7 @@ rte_realloc(void *ptr, size_t size, unsigned int align)
__rte_experimental
void *
rte_realloc_socket(void *ptr, size_t size, unsigned int align, int socket)
- __rte_alloc_size(2, 3);
+ __rte_alloc_size(2);
/**
* This function allocates memory from the huge-page area of memory. The memory