RE: [PATCH dpdk 0/2] IPv6: Fix coverity issues
> -Original Message- > From: David Marchand > Sent: Tuesday, November 5, 2024 9:06 PM > To: Mcnamara, John ; Patrick Robb > > Cc: dev@dpdk.org; Robin Jarry ; Morten Brørup > > Subject: Re: [PATCH dpdk 0/2] IPv6: Fix coverity issues > > Hello John, Patrick, > > On Thu, Oct 24, 2024 at 5:20 PM Robin Jarry wrote: > > > > Here are fixes for three coverity issues: > > This series fixes two coverity issues. The fixes look correct. > But the Coverity reports are not obvious to me. > > Is there a way to pass those fixes through Coverity to confirm the two > issues are indeed fixed? There is no easy way to do that. The Coverity analysis only runs on the main after patches have been merged. It isn't structured to allow patch or fix based analysis.
[PATCH] vhost: clear ring addresses when getting vring base
From: "Jianping.zhao"
Clear ring addresses during vring base retrieval to handle guest reboot
scenarios correctly. This is particularly important for vdpa-blk devices
where the following issue occurs:
When a guest OS with vdpa-blk device reboots, during UEFI stage, only
one vring is actually used and configured. However, QEMU still sends
enable messages for all configured queues. The remaining queues retain
their addresses from before reboot, which reference invalid memory
mappings in the rebooted guest.
The issue manifests in vq_is_ready():
static bool
vq_is_ready(struct virtio_net *dev, struct vhost_virtqueue *vq)
{
/* Only checks pointer validity, not address freshness */
rings_ok = vq->desc && vq->avail && vq->used;
...
}
vq_is_ready() incorrectly considers these queues as ready because it
only checks if desc/avail/used pointers are non-NULL, but cannot
detect that these addresses are stale from the previous boot.
Clear the ring addresses in vhost_user_get_vring_base() to force
the guest driver to reconfigure them before use. This ensures that
vq_is_ready() will return false for queues with stale addresses
until they are properly reconfigured by the guest driver.
Fixes: 3ea7052f4b1b ("vhost: postpone rings addresses translation")
Cc: sta...@dpdk.org
Cc: Maxime Coquelin
Cc: Chenbo Xia
Signed-off-by: jianping.zhao
---
lib/vhost/vhost_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 6d92ad904e..52d8078d7c 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2277,6 +2277,7 @@ vhost_user_get_vring_base(struct virtio_net **pdev,
rte_rwlock_write_lock(&vq->access_lock);
vring_invalidate(dev, vq);
+ memset(&vq->ring_addrs, 0, sizeof(struct vhost_vring_addr));
rte_rwlock_write_unlock(&vq->access_lock);
return RTE_VHOST_MSG_RESULT_REPLY;
--
2.34.1
[PATCH v2] vhost/user: clear ring addresses when getting vring base
Clear ring addresses during vring base retrieval to handle guest reboot
scenarios correctly. This is particularly important for vdpa-blk devices
where the following issue occurs:
When a guest OS with vdpa-blk device reboots, during UEFI stage, only
one vring is actually used and configured. However, QEMU still sends
enable messages for all configured queues. The remaining queues retain
their addresses from before reboot, which reference invalid memory
mappings in the rebooted guest.
The issue manifests in vq_is_ready():
static bool
vq_is_ready(struct virtio_net *dev, struct vhost_virtqueue *vq)
{
/* Only checks pointer validity, not address freshness */
rings_ok = vq->desc && vq->avail && vq->used;
...
}
vq_is_ready() incorrectly considers these queues as ready because it
only checks if desc/avail/used pointers are non-NULL, but cannot
detect that these addresses are stale from the previous boot.
Clear the ring addresses in vhost_user_get_vring_base() to force
the guest driver to reconfigure them before use. This ensures that
vq_is_ready() will return false for queues with stale addresses
until they are properly reconfigured by the guest driver.
Fixes: 3ea7052f4b1b ("vhost: postpone rings addresses translation")
Signed-off-by: Jianping Zhao
---
lib/vhost/vhost_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 6d92ad904e..52d8078d7c 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2277,6 +2277,7 @@ vhost_user_get_vring_base(struct virtio_net **pdev,
rte_rwlock_write_lock(&vq->access_lock);
vring_invalidate(dev, vq);
+ memset(&vq->ring_addrs, 0, sizeof(struct vhost_vring_addr));
rte_rwlock_write_unlock(&vq->access_lock);
return RTE_VHOST_MSG_RESULT_REPLY;
--
2.34.1
[PATCH v3] vhost/user: clear ring addresses when getting vring base
Clear ring addresses during vring base retrieval to handle guest reboot
scenarios correctly. This is particularly important for vdpa-blk devices
where the following issue occurs:
When a guest OS with vdpa-blk device reboots, during UEFI stage, only
one vring is actually used and configured. However, QEMU still sends
enable messages for all configured queues. The remaining queues retain
their addresses from before reboot, which reference invalid memory
mappings in the rebooted guest.
The issue manifests in vq_is_ready():
static bool
vq_is_ready(struct virtio_net *dev, struct vhost_virtqueue *vq)
{
/* Only checks pointer validity, not address freshness */
rings_ok = vq->desc && vq->avail && vq->used;
...
}
vq_is_ready() incorrectly considers these queues as ready because it
only checks if desc/avail/used pointers are non-NULL, but cannot
detect that these addresses are stale from the previous boot.
Clear the ring addresses in vhost_user_get_vring_base() to force
the guest driver to reconfigure them before use. This ensures that
vq_is_ready() will return false for queues with stale addresses
until they are properly reconfigured by the guest driver.
Fixes: 3ea7052f4b1b ("vhost: postpone rings addresses translation")
Signed-off-by: Jianping Zhao
---
lib/vhost/vhost_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 6d92ad904e..52d8078d7c 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2277,6 +2277,7 @@ vhost_user_get_vring_base(struct virtio_net **pdev,
rte_rwlock_write_lock(&vq->access_lock);
vring_invalidate(dev, vq);
+ memset(&vq->ring_addrs, 0, sizeof(struct vhost_vring_addr));
rte_rwlock_write_unlock(&vq->access_lock);
return RTE_VHOST_MSG_RESULT_REPLY;
--
2.34.1
[PATCH v1] net/i40e: updated latest recommended matching list
Signed-off-by: hailinx --- doc/guides/nics/i40e.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index ca6caa0cff..35585efc44 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -104,6 +104,10 @@ For X710/XL710/XXV710, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |24.11 | 2.26.8| 9.52 | + +--+---+--+ + |24.07 | 2.25.9| 9.50 | + +--+---+--+ |24.03 | 2.24.6| 9.40 | +--+---+--+ |23.11 | 2.23.17 | 9.30 | @@ -171,6 +175,10 @@ For X722, +--+---+--+ | DPDK version | Kernel driver version | Firmware version | +==+===+==+ + |24.11 | 2.26.8| 6.50 | + +--+---+--+ + |24.07 | 2.25.9| 6.50 | + +--+---+--+ |24.03 | 2.24.6| 6.20 | +--+---+--+ |23.11 | 2.23.17 | 6.20 | -- 2.25.1
Recall: [PATCH v1] net/ice: updated latest recommended matching list
Xu, HailinX would like to recall the message, "[PATCH v1] net/ice: updated latest recommended matching list".
[PATCH v1] net/ice: updated latest recommended matching list
Signed-off-by: hailinx --- doc/guides/nics/ice.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index eac1f2627b..a32fb27b24 100644 --- a/doc/guides/nics/ice.rst +++ b/doc/guides/nics/ice.rst @@ -79,6 +79,10 @@ are listed in the Tested Platforms section of the Release Notes for each release +---+---+-+---+--+---+ |24.03 | 1.13.7| 1.3.35 | 1.3.45 |1.3.13| 4.4| +---+---+-+---+--+---+ + |24.07 | 1.14.11 | 1.3.36 | 1.3.46 |1.3.14| 4.5| + +---+---+-+---+--+---+ + |24.07 | 1.15.4| 1.3.36 | 1.3.46 |1.3.14| 4.6| + +---+---+-+---+--+---+ Dynamic Device Personalization (DDP) package loading -- 2.25.1
[PATCH] vhost: clear ring addresses when getting vring base
Clear ring addresses during vring base retrieval to handle guest reboot
scenarios correctly. This is particularly important for vdpa-blk devices
where the following issue occurs:
When a guest OS with vdpa-blk device reboots, during UEFI stage, only
one vring is actually used and configured. However, QEMU still sends
enable messages for all configured queues. The remaining queues retain
their addresses from before reboot, which reference invalid memory
mappings in the rebooted guest.
The issue manifests in vq_is_ready():
static bool
vq_is_ready(struct virtio_net *dev, struct vhost_virtqueue *vq)
{
/* Only checks pointer validity, not address freshness */
rings_ok = vq->desc && vq->avail && vq->used;
...
}
vq_is_ready() incorrectly considers these queues as ready because it
only checks if desc/avail/used pointers are non-NULL, but cannot
detect that these addresses are stale from the previous boot.
Clear the ring addresses in vhost_user_get_vring_base() to force
the guest driver to reconfigure them before use. This ensures that
vq_is_ready() will return false for queues with stale addresses
until they are properly reconfigured by the guest driver.
Fixes: 3ea7052f4b1b ("vhost: postpone rings addresses translation")
Signed-off-by: jianping.zhao
---
lib/vhost/vhost_user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 6d92ad904e..52d8078d7c 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2277,6 +2277,7 @@ vhost_user_get_vring_base(struct virtio_net **pdev,
rte_rwlock_write_lock(&vq->access_lock);
vring_invalidate(dev, vq);
+ memset(&vq->ring_addrs, 0, sizeof(struct vhost_vring_addr));
rte_rwlock_write_unlock(&vq->access_lock);
return RTE_VHOST_MSG_RESULT_REPLY;
--
2.34.1
[PATCH v1] net/ice: updated latest recommended matching list
Signed-off-by: hailinx --- doc/guides/nics/ice.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index eac1f2627b..a32fb27b24 100644 --- a/doc/guides/nics/ice.rst +++ b/doc/guides/nics/ice.rst @@ -79,6 +79,10 @@ are listed in the Tested Platforms section of the Release Notes for each release +---+---+-+---+--+---+ |24.03 | 1.13.7| 1.3.35 | 1.3.45 |1.3.13| 4.4| +---+---+-+---+--+---+ + |24.07 | 1.14.11 | 1.3.36 | 1.3.46 |1.3.14| 4.5| + +---+---+-+---+--+---+ + |24.11 | 1.15.4| 1.3.36 | 1.3.46 |1.3.14| 4.6| + +---+---+-+---+--+---+ Dynamic Device Personalization (DDP) package loading -- 2.25.1
Re: [PATCH] net/txgbe: fix a mass of interrupts
On Tue, 19 Nov 2024 10:02:23 +0800
Jiawen Wu wrote:
> On Tue, Nov 19, 2024 3:59 AM, Ferruh Yigit wrote:
> > On 11/15/2024 8:33 AM, Jiawen Wu wrote:
> > > Since firmware version 0x20010, GPIO interrupt enable is set to 0xd by
> > > default, which means enable bit 0 'tx_fault'. And GPIO interrupt polarity
> > > is set to 0xd by default too, which means these interrupts are rising-edge
> > > sensitive.
> > >
> > > So when unplug the SFP module, GPIO line 0 'tx_fault' is 0 -> 1 triggers
> > > the interrupt. However, the interrupt is not cleared. And GPIO interrupt
> > > mask is enabled and disabled to trigger the MISC interrupt repeatedly.
> > >
> > > Since this 'tx_fault' interrupt does not make much sense, simply clear it
> > > to fix the issue.
> > >
> > > Signed-off-by: Jiawen Wu
> > >
> >
> > Hi Jiawen,
> >
> > Can you please provide a fixes tag?
> > Also I believe you would like to backport this fix, if so please add the
> > stable tag as well.
>
> I have thought about it. But there are two changes based on two commits:
> 1. d3bb4a04eac1 ("net/txgbe: add SFP hotplug identification")
> 2. 12011b11a3d6 ("net/txgbe: adapt to MNG veto bit setting")
>
> Should I split the patch and add fixes tags separately?
>
>
It is ok, as is. I can add the fixes tag for you.
The purpose of the fixes is to help with discovering patches that need
to go into stable.
Applied to next-net
Re: [PATCH] app/testpmd: add L4 port to verbose output
On Thu, 15 Aug 2024 15:20:51 +0100 Alex Chapman wrote: > To help distinguish packets we want to add more identifiable > information and print port number for all packets. > This will make packet metadata more uniform as previously it > only printed port number for encapsulated packets. > > Bugzilla-ID: 1517 > > Signed-off-by: Alex Chapman > Reviewed-by: Luca Vizzarro > Reviewed-by: Paul Szczepanek Having more diagnostic output here is a good idea, the output is pretty verbose. So both printing here and having it in the dissect output is helpful. Applied to next-net
DPDK Release Status Meeting 2024-11-21
Release status meeting minutes 2024-11-21 = Agenda: * Release Dates * Subtrees * Roadmaps * LTS * Defects * Opens Participants: * ARM * Debian/Microsoft * Intel * Marvell * Nvidia Release Dates - The following are the current/updated working dates for 24.11: - Proposal deadline (RFC/v1 patches): 7 September 2024 - API freeze (-rc1): 19 October 2024 - PMD features freeze (-rc2): 12 November 2024 - Builtin applications features freeze (-rc3): 20 November 2024 - Release: 29 November 2023 https://core.dpdk.org/roadmap/#dates Subtrees * next-net * RC3 released. * next-net-intel * Most fixes merged in RC3. * next-net-mlx * Merged for RC3. * next-net-mvl * No update. * next-eventdev * No update. * next-baseband * No update. * next-virtio * No update. * next-crypto * Merged for RC3. * next-dts * No merges past RC3 except for fixes. * main * Docs and minor fixes only for RC4. * RC3 released on 20 November * RC4 targeted for 26 November 2024 * Release targeted for 29 November 2024 **Note**: We will look to move this meeting to a US friendly time slot at the start of December. LTS --- Status of the current LTSes * 23.11.3 - In progress. * 22.11.7 - In progress. * 21.11.9 - In progress. * 20.11.10 - Will only be updated with CVE and critical fixes. * 19.11.15 - Will only be updated with CVE and critical fixes. * Distros * Debian 12 contains DPDK v22.11 * Ubuntu 24.04 contains DPDK v23.11 * Ubuntu 23.04 contains DPDK v22.11 * RHEL 8/9 contains DPDK 23.11 Defects --- * Bugzilla links, 'Bugs', added for hosted projects * https://www.dpdk.org/hosted-projects/ DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on every Thursday at 9:30 DST over Jitsi on https://meet.jit.si/DPDK You don't need an invite to join the meeting but if you want a calendar reminder just send an email to "John McNamara john.mcnam...@intel.com" for the invite.
Re: [PATCH v3 3/3] net/hns3: fix Rx packet without CRC data
On Fri, 19 Jul 2024 17:04:15 +0800
Jie Hai wrote:
> From: Dengdui Huang
>
> When KEEP_CRC offload is enabled, the CRC data is still stripped
> in following cases:
> 1. For HIP08 network engine, the packet type is TCP and the length
>is less than or equal to 60B.
> 2. For HIP09 network engine, the packet type is IP and the length
>is less than or equal to 60B.
>
> So driver has to recaculate packet CRC for this rare scenarios.
>
> In addition, to avoid impacting performance, KEEP_CRC is not
> supported when NEON or SVE algorithm is used.
>
> Fixes: 8973d7c4ca12 ("net/hns3: support keeping CRC")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dengdui Huang
> Acked-by: Huisong Li
> +static inline void
> +hns3_recalculate_crc(struct rte_mbuf *m)
> +{
> + char *append_data;
> + uint32_t crc;
> +
> + crc = rte_net_crc_calc(rte_pktmbuf_mtod(m, void *),
> +m->data_len, RTE_NET_CRC32_ETH);
> +
> + /*
> + * The hns3 driver requires that mbuf size must be at least 512B.
> + * When CRC is stripped by hardware, the pkt_len must be less than
> + * or equal to 60B. Therefore, the space of the mbuf is enough
> + * to insert the CRC.
> + *
> + * In addition, after CRC is stripped by hardware, pkt_len and data_len
> + * do not contain the CRC length. Therefore, after CRC data is appended
> + * by PMD again, both pkt_len and data_len add the CRC length.
> + */
> + append_data = rte_pktmbuf_append(m, RTE_NET_CRC32_ETH);
> + /* The CRC data is binary data and does not care about the byte order.
> */
> + rte_memcpy(append_data, (void *)&crc, RTE_NET_CRC32_ETH);
> +}
Ok, but minor nits for future.
Trying to phase out use of rte_memcpy(), rte_memcpy() has no advantage except
in certain cases of unaligned variable length copies mostly on older non x86
distros.
And regular memcpy() enables compiler to do more checking.
And you don't need a void * cast there, in C there is implicit cast to void *
there.
Applied to next-net
[PATCH 2/3] eventdev: fix uninitialized variable
This patch fixes the variable 'events' may be used uninitialized.
Fixes: 7901eac3409a ("eventdev: add crypto adapter implementation")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
lib/eventdev/rte_event_crypto_adapter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/eventdev/rte_event_crypto_adapter.c
b/lib/eventdev/rte_event_crypto_adapter.c
index 939ca1cad9..1ca839510b 100644
--- a/lib/eventdev/rte_event_crypto_adapter.c
+++ b/lib/eventdev/rte_event_crypto_adapter.c
@@ -685,6 +685,7 @@ eca_ops_enqueue_burst(struct event_crypto_adapter *adapter,
nb_ev = 0;
retry = 0;
nb_enqueued = 0;
+ memset(events, 0, sizeof(events));
num = RTE_MIN(num, BATCH_SIZE);
for (i = 0; i < num; i++) {
struct rte_event *ev = &events[nb_ev++];
--
2.34.1
[PATCH 1/3] net/bnxt: fix uninitialized variable
This patch fixes the variable 'total_pages' may be used uninitialized.
Fixes: 80317ff6adfd ("net/bnxt/tf_core: support Thor2")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
drivers/net/bnxt/tf_core/v3/tfc_tbl_scope.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/tf_core/v3/tfc_tbl_scope.c
b/drivers/net/bnxt/tf_core/v3/tfc_tbl_scope.c
index 1770069295..3aed78dbeb 100644
--- a/drivers/net/bnxt/tf_core/v3/tfc_tbl_scope.c
+++ b/drivers/net/bnxt/tf_core/v3/tfc_tbl_scope.c
@@ -439,7 +439,7 @@ static int alloc_link_pbl(struct tfc_ts_mem_cfg *mem_cfg,
uint32_t page_size,
char mz_name[RTE_MEMZONE_NAMESIZE];
int mz_size;
uint64_t total_size;
- uint32_t total_pages;
+ uint32_t total_pages = 0;
/* tf_em_size_page_tbl_lvl */
rc = num_pages_get(mem_cfg, page_size);
--
2.34.1
[PATCH 0/3] fix uninitialized variable
fix uninitialized variables in batches Wenwu Ma (3): net/bnxt: fix uninitialized variable eventdev: fix uninitialized variable eventdev: fix uninitialized variable drivers/net/bnxt/tf_core/v3/tfc_tbl_scope.c | 2 +- lib/eventdev/rte_event_crypto_adapter.c | 1 + lib/eventdev/rte_event_dma_adapter.c| 1 + 3 files changed, 3 insertions(+), 1 deletion(-) -- 2.34.1
[PATCH 3/3] eventdev: fix uninitialized variable
This patch fixes the variable 'events' may be used uninitialized.
Fixes: 3c89e8c42022 ("eventdev/dma: support adapter service function")
Cc: sta...@dpdk.org
Signed-off-by: Wenwu Ma
---
lib/eventdev/rte_event_dma_adapter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/eventdev/rte_event_dma_adapter.c
b/lib/eventdev/rte_event_dma_adapter.c
index ff2bc408c1..3c05fb615f 100644
--- a/lib/eventdev/rte_event_dma_adapter.c
+++ b/lib/eventdev/rte_event_dma_adapter.c
@@ -655,6 +655,7 @@ edma_ops_enqueue_burst(struct event_dma_adapter *adapter,
struct rte_event_dma_a
nb_ev = 0;
retry = 0;
nb_enqueued = 0;
+ memset(events, 0, sizeof(events));
num = RTE_MIN(num, DMA_BATCH_SIZE);
for (i = 0; i < num; i++) {
struct rte_event *ev = &events[nb_ev++];
--
2.34.1
