From: Thomas Monjalon <thomas@monjalon.net>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, Shani Peretz <shperetz@nvidia.com>,
Konstantin Ananyev <konstantin.ananyev@huawei.com>,
stable@dpdk.org
Subject: Re: [PATCH v2] mbuf: fix mbuf operations history recording
Date: Mon, 01 Jun 2026 15:31:22 +0200 [thread overview]
Message-ID: <yptfuIayTIumsvli3EeZ0A@monjalon.net> (raw)
In-Reply-To: <20260511133952.65539-1-mb@smartsharesystems.com>
11/05/2026 15:39, Morten Brørup:
> This addresses two bugs in mbuf operations history recording.
>
> 1. With mbuf operations history recording enabled, when allocating mbufs
> from a mempool failed, the array of fetched mbuf pointers was not set, but
> it was dereferenced for mbuf operations history recording anyway, which
> would trigger a segmentation fault or cause undefined behavior.
>
> This was fixed by changing how the return value from the mempool
> allocation is checked, so the function returns early on failure, and only
> proceeds on success.
>
> 2. When allocating a bulk of mbufs using rte_pktmbuf_alloc_bulk(), two
> mbuf library allocation operations were recorded on the mbuf, because the
> function calls rte_mbuf_raw_alloc_bulk() for allocation, and both
> functions record a mbuf library allocation operation.
>
> This was fixed by not recording a mbuf library allocation operation in
> rte_pktmbuf_alloc_bulk().
>
> 3. When freeing a bulk of segmented mbufs, the free operations were only
> recorded on the first segments.
>
> This was fixed by freeing the pending bulks of segments using
> rte_mbuf_raw_free_bulk(), which records the free operation on the mbufs,
> instead of calling rte_mempool_put_bulk() directly.
> The bulk operation recording at the start of the function, which only
> affected the first segments of segmented packets, was removed.
>
> Fixes: d265a24a32a4 ("mbuf: record mbuf operations history")
> Cc: stable@dpdk.org
>
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Applied, thanks.
prev parent reply other threads:[~2026-06-01 13:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 22:12 [PATCH] mbuf: fix mbuf operations history recording Morten Brørup
2026-04-20 10:06 ` Thomas Monjalon
2026-04-20 11:24 ` Morten Brørup
2026-04-22 12:29 ` Morten Brørup
2026-04-29 16:35 ` Konstantin Ananyev
2026-05-11 13:39 ` [PATCH v2] " Morten Brørup
2026-06-01 13:31 ` Thomas Monjalon [this message]
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=yptfuIayTIumsvli3EeZ0A@monjalon.net \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=shperetz@nvidia.com \
--cc=stable@dpdk.org \
/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.