[PATCH] mbuf: fix mbuf operations history recording

Morten Brørup mb at smartsharesystems.com
Mon Apr 20 13:24:17 CEST 2026


> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Monday, 20 April 2026 12.06
> 
> 20/04/2026 00:12, 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().
> >
> > Fixes: d265a24a32a4 ("mbuf: record mbuf operations history")
> > Cc: stable at dpdk.org
> >
> > Signed-off-by: Morten Brørup <mb at smartsharesystems.com>
> [...]
> 
> It would be better to make an explicit comparison != 0 below:
> 
> > +	if (unlikely(rc))
> > +		return rc;

I would normally have done that, but decided to do it like rte_pktmbuf_alloc_bulk().
If it was a pointer, I would probably have compared != NULL regardless of conventions in the file.

> 
> Thank you for the fixes.
> 
> Acked-by: Thomas Monjalon <thomas at monjalon.net>

Thanks for the fast review response.



More information about the stable mailing list