From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: <dev@dpdk.org>, "Thomas Monjalon" <thomas@monjalon.net>,
"Konstantin Ananyev" <konstantin.ananyev@huawei.com>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
"Bruce Richardson" <bruce.richardson@intel.com>,
"Ali Alnubani" <alialnu@nvidia.com>
Subject: RE: [PATCH] stack: fix pile GCC memcpy warnings
Date: Tue, 20 Oct 2026 17:16:14 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65ACD@smartserver.smartshare.dk> (raw)
In-Reply-To: <20261020072333.30593486@phoenix.local>
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 20 October 2026 16.24
>
> On Tue, 20 Oct 2026 08:49:44 +0000
> Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > On architectures where rte_memcpy() is defined as memcpy(),
> > GCC warns about source/destination overflow when copying more than
> the
> > source/destination size, even for code paths that are not taken in
> cases
> > where the sizes are smaller.
> >
> > The relevant compiler warnings were disabled for GCC at the two
> > occurrences, and comments describing the reason were added.
> >
> > NB:
> > It has not been investigated which GCC versions are affected.
> > GCC version 10 and up was chosen because that was what the previous
> > versions of x86 rte_memcpy() disabled sligthly similar warnings for.
> >
> > PS:
> > The alternative was to obfuscate the code, but that would make the
> code
> > less readable, and might have unintended effects on architectures and
> > compilers not suffering by this issue.
> >
> > Bugzilla ID: 2061
> > Fixes: ee0822a0ef41 ("stack: introduce pile")
> >
> > The pile was introduce with this DPDK release, so no need to
> backport.
> >
> > Reported-by: Ali Alnubani <alialnu@nvidia.com>
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
>
> I don't like using compiler pragmas for this. It also means that if
> compiler gets fixed or behaves differently you will never see it.
>
>
> AI analysis shows some other options.
>
> Root cause is --buildtype=debug, i.e. -O0, not the GCC version. At -O0
> nothing removes the dead n_bulk > 0 path for rte_stack_push(s, &obj,
> 1), so the constant 256-byte memcpy is checked against obj (8 bytes)
> and warns. Reproduced with GCC 13.3 and 14.2 at -O0; silent at -Og and
> above. That means the GCC_VERSION >= 100000 gate is wrong at both ends:
> any GCC with the warning fires (overflow since 8, overread since 11),
> and on GCC 10 the -Wstringop-overread pragma itself is a -Wpragmas
> error under -Werror. If the pragma stays, drop the version gate (keep
> RTE_TOOLCHAIN_GCC) and fix the comment: GCC does not “know” the path is
> dead, that is the whole problem.
Continuing this line of thinking...
GCC defines an "__OPTIMIZE__" macro if any optimization above level 0 is turned on.
We could gate such pragmas with:
#if defined(RTE_TOOLCHAIN_GCC) && !defined(__OPTIMIZE__)
>
>
> This should have a big ass comment, and it should use same pragma set
> as existing one in lib/ring.
I generally prefer having the pragma coverage as narrow as possible, so they don't prevent catching unrelated bugs in the same file.
On the other hand,
I also like the suggestion in your other email - disabling these false-positive GCC warnings globally across DPDK for non-optimized builds.
And since the default build type is debugoptimized, it will not prevent GCC from emitting relevant warnings during normal development.
>
> Other alternative is to use bulk object array as structure and do
> assignment.
> But that replaces ugly pragmas with ugly casts...
Yeah, let's not do that.
But thank you for exploring!
>
> --- a/lib/stack/rte_stack_pile.h
> +++ b/lib/stack/rte_stack_pile.h
> @@
> +/* Bulk object array as a single object, so a copy is one assignment.
> */
> +struct rte_stack_pile_bulk_objs {
> + void *objs[RTE_STACK_PILE_BULK_SIZE];
> +};
> +
> @@ __rte_stack_pile_bulk_pop_elems
> for (unsigned int i = 0; i < num; i++, tmp = tmp->next)
> - rte_memcpy(&obj_table[i * RTE_STACK_PILE_BULK_SIZE],
> - ((struct rte_stack_pile_bulk_elem *)tmp)-
> >objs,
> - sizeof(void *) *
> RTE_STACK_PILE_BULK_SIZE);
> + *(struct rte_stack_pile_bulk_objs *)&obj_table[i *
> RTE_STACK_PILE_BULK_SIZE] =
> + *(struct rte_stack_pile_bulk_objs *)((struct
> rte_stack_pile_bulk_elem *)tmp)->objs;
> @@ __rte_stack_pile_push
> for (i = 0; i < n_bulk; i++, tmp = tmp->next)
> - rte_memcpy(((struct rte_stack_pile_bulk_elem *)tmp)->objs,
> - &obj_table[(n_bulk - i - 1) *
> RTE_STACK_PILE_BULK_SIZE],
> - sizeof(void *) * RTE_STACK_PILE_BULK_SIZE);
> + *(struct rte_stack_pile_bulk_objs *)((struct
> rte_stack_pile_bulk_elem *)tmp)->objs =
> + *(const struct rte_stack_pile_bulk_objs
> *)&obj_table[(n_bulk - i - 1) * RTE_STACK_PILE_BULK_SIZE];
>
next prev parent reply other threads:[~2026-10-20 15:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 8:49 [PATCH] stack: fix pile GCC memcpy warnings Morten Brørup
2026-10-20 9:18 ` Bruce Richardson
2026-10-20 9:59 ` Morten Brørup
2026-10-20 10:18 ` Ali Alnubani
2026-10-20 14:23 ` Stephen Hemminger
2026-10-20 15:16 ` Morten Brørup [this message]
2026-10-20 15:39 ` Morten Brørup
2026-10-20 14:34 ` Stephen Hemminger
2026-10-20 15:27 ` Morten Brørup
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=98CBD80474FA8B44BF855DF32C47DC35F65ACD@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=alialnu@nvidia.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.