From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, david.marchand@redhat.com, ktraynor@redhat.com
Subject: Re: [PATCH 0/4] clean up zero-length arrays
Date: Wed, 8 Jun 2022 08:23:02 -0700 [thread overview]
Message-ID: <20220608082302.09de7deb@hermes.local> (raw)
In-Reply-To: <20220602150834.643745-1-bruce.richardson@intel.com>
On Thu, 2 Jun 2022 16:08:30 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> This patchset adds a coccinelle script to clean-up zero-length
> arrays in structures. The final patches are the result of running
> that script on the DPDK repository.
>
> Bruce Richardson (4):
> cocci: add script for zero-length arrays in structs
> drivers: replace zero-length arrays with undimensioned ones
> lib: replace zero-length arrays with undimensioned ones
> app: examples: replace zero-length arrays with undimensioned ones
>
> app/test/test_table_tables.c | 2 +-
> devtools/cocci/zero_length_array.cocci | 21 +++++++++++++++
> drivers/bus/dpaa/include/netcfg.h | 4 +--
> drivers/bus/vmbus/rte_vmbus_reg.h | 4 +--
> drivers/common/cnxk/roc_se.h | 2 +-
> drivers/common/dpaax/caamflib/desc/ipsec.h | 2 +-
> drivers/common/dpaax/dpaax_iova_table.h | 2 +-
> drivers/common/mlx5/mlx5_prm.h | 10 +++----
> drivers/crypto/ipsec_mb/ipsec_mb_private.h | 4 +--
> drivers/crypto/virtio/virtio_ring.h | 4 +--
> drivers/crypto/virtio/virtqueue.h | 2 +-
> drivers/net/atlantic/hw_atl/hw_atl_utils.h | 2 +-
> drivers/net/cxgbe/clip_tbl.h | 2 +-
> drivers/net/cxgbe/l2t.h | 2 +-
> drivers/net/cxgbe/mps_tcam.h | 2 +-
> drivers/net/cxgbe/smt.h | 2 +-
> drivers/net/enic/base/vnic_devcmd.h | 2 +-
> drivers/net/hinic/hinic_pmd_tx.h | 2 +-
> drivers/net/mlx5/mlx5_tx.h | 2 +-
> drivers/net/nfp/nfpcore/nfp_nsp.h | 2 +-
> drivers/net/virtio/virtio_ring.h | 4 +--
> drivers/net/virtio/virtio_user/vhost_kernel.c | 2 +-
> drivers/net/virtio/virtio_user/vhost_vdpa.c | 2 +-
> drivers/net/virtio/virtqueue.h | 2 +-
> drivers/regex/mlx5/mlx5_rxp.h | 4 +--
> examples/ip_reassembly/main.c | 2 +-
> examples/ptpclient/ptpclient.c | 4 +--
> lib/cryptodev/cryptodev_pmd.h | 2 +-
> lib/cryptodev/rte_cryptodev.h | 2 +-
> lib/eventdev/rte_event_timer_adapter.h | 2 +-
> lib/ip_frag/ip_reassembly.h | 2 +-
> lib/ipsec/sa.h | 2 +-
> lib/rib/rte_rib.c | 2 +-
> lib/rib/rte_rib6.c | 2 +-
> lib/table/rte_swx_table_learner.c | 4 +--
> lib/table/rte_table_hash_key16.c | 4 +--
> lib/table/rte_table_hash_key32.c | 4 +--
> lib/table/rte_table_hash_key8.c | 4 +--
> lib/vhost/rte_vhost.h | 4 +--
> 40 files changed, 101 insertions(+), 54 deletions(-)
> create mode 100644 devtools/cocci/zero_length_array.cocci
> create mode 100644 lib/count_comments.py
>
> --
> 2.34.1
>
Bruce, looking at this commit, it looks like the underlying cause
of the problem with iavf was it is using array size of one
when flex array should be used:
commit b5b3ea803e4741ad6a46a38d8227c78226d9054d
Author: Kevin Traynor <ktraynor@redhat.com>
Date: Fri Apr 17 16:43:35 2020 +0100
eal/x86: ignore gcc 10 stringop-overflow warnings
stringop-overflow warns when it sees a possible overflow
in a string operation.
In the rte_memcpy functions different branches are taken
depending on the size. stringop-overflow is raised for the
branches in the function where it sees the static size of the
src could be overflowed.
However, in reality a correct size argument and in some cases
dynamic allocation would ensure that this does not happen.
For example, in the case below for key, the correct path will be
chosen in rte_memcpy_generic at runtime based on the size argument
but as some paths in the function could lead to a cast to 32 bytes
a warning is raised.
In function ‘_mm256_storeu_si256’,
inlined from ‘rte_memcpy_generic’
at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:315:2,
inlined from ‘iavf_configure_rss_key’
at ../lib/librte_eal/common/include/arch/x86/rte_memcpy.h:869:10:
/usr/lib/gcc/x86_64-redhat-linux/10/include/avxintrin.h:928:8:
warning: writing 32 bytes into a region of size 1 [-Wstringop-overflow=]
928 | *__P = __A;
| ~~~~~^~~~~
In file included
from ../drivers/net/iavf/../../common/iavf/iavf_prototype.h:10,
from ../drivers/net/iavf/iavf.h:9,
from ../drivers/net/iavf/iavf_vchnl.c:22:
../drivers/net/iavf/iavf_vchnl.c:
In function ‘iavf_configure_rss_key’:
../drivers/net/iavf/../../common/iavf/virtchnl.h:508:5:
note: at offset 0 to object ‘key’ with size 1 declared here
508 | u8 key[1]; /* RSS hash key, packed bytes */
| ^~~
Ignore the stringop-overflow warnings for rte_memcpy.h functions.
Bugzilla ID: 394
Bugzilla ID: 421
Cc: stable@dpdk.org
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
next prev parent reply other threads:[~2022-06-08 15:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 15:08 Bruce Richardson
2022-06-02 15:08 ` [PATCH 1/4] cocci: add script for zero-length arrays in structs Bruce Richardson
2022-06-02 15:08 ` [PATCH 2/4] drivers: replace zero-length arrays with undimensioned ones Bruce Richardson
2022-06-02 15:08 ` [PATCH 3/4] lib: " Bruce Richardson
2022-06-02 15:08 ` [PATCH 4/4] app: examples: " Bruce Richardson
2022-06-02 15:20 ` [PATCH 0/4] clean up zero-length arrays Morten Brørup
2022-06-02 15:35 ` Stephen Hemminger
2022-06-02 16:13 ` [PATCH v2 " Bruce Richardson
2022-06-02 16:13 ` [PATCH v2 1/4] cocci: add script for zero-length arrays in structs Bruce Richardson
2022-06-02 16:13 ` [PATCH v2 2/4] drivers: replace zero-length arrays with undimensioned ones Bruce Richardson
2022-06-03 7:19 ` David Marchand
2022-06-03 7:36 ` Bruce Richardson
2022-06-03 9:18 ` Bruce Richardson
2022-06-02 16:13 ` [PATCH v2 3/4] lib: " Bruce Richardson
2022-06-02 16:13 ` [PATCH v2 4/4] app: examples: " Bruce Richardson
2022-06-03 6:56 ` [PATCH v2 0/4] clean up zero-length arrays Hemant Agrawal
2022-06-03 10:13 ` [PATCH v3 " Bruce Richardson
2022-06-03 10:13 ` [PATCH v3 1/4] cocci: add script for zero-length arrays in structs Bruce Richardson
2022-06-03 10:30 ` Morten Brørup
2022-06-03 10:38 ` Bruce Richardson
2022-06-03 10:13 ` [PATCH v3 2/4] drivers: replace zero-length arrays with undimensioned ones Bruce Richardson
2022-06-03 10:13 ` [PATCH v3 3/4] lib: " Bruce Richardson
2022-06-03 10:13 ` [PATCH v3 4/4] app: examples: " Bruce Richardson
2022-06-03 11:13 ` [PATCH v3 0/4] clean up zero-length arrays Bruce Richardson
2022-06-03 11:16 ` [PATCH v4 " Bruce Richardson
2022-06-03 11:16 ` [PATCH v4 1/4] cocci: add script for zero-length arrays in structs Bruce Richardson
2022-06-03 11:16 ` [PATCH v4 2/4] drivers: replace zero-length arrays with undimensioned ones Bruce Richardson
2022-06-03 11:16 ` [PATCH v4 3/4] lib: " Bruce Richardson
2022-06-03 11:16 ` [PATCH v4 4/4] app: examples: " Bruce Richardson
2022-06-07 14:16 ` [PATCH v4 0/4] clean up zero-length arrays David Marchand
2022-06-09 15:19 ` Tyler Retzlaff
2022-06-08 15:23 ` Stephen Hemminger [this message]
2022-06-14 9:40 ` [PATCH " Bruce Richardson
2022-06-14 9:45 ` Bruce Richardson
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=20220608082302.09de7deb@hermes.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ktraynor@redhat.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).