public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Thomas Monjalon" <thomas@monjalon.net>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	dev@dpdk.org, stable@dpdk.org,
	Konstantin Ananyev <konstantin.ananyev@huawei.com>
Subject: Re: [PATCH v3] mbuf: fix packet copy
Date: Thu, 26 Feb 2026 10:01:03 +0000	[thread overview]
Message-ID: <49efe45f-e396-4a25-b789-17719a783921@redhat.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F6574F@smartserver.smartshare.dk>

On 25/02/2026 17:17, Morten Brørup wrote:
>> From: Kevin Traynor [mailto:ktraynor@redhat.com]
>> Sent: Wednesday, 25 February 2026 16.59
>>
>> On 10/02/2026 17:21, Thomas Monjalon wrote:
>>> 20/01/2026 08:24, Morten Brørup:
>>>> mbuf: fix packet copy
>>>>
>>>> Requests for copying the at the end of a packet incorrectly returned
>> NULL,
>>>> as if copying past the end of a packet.
>>>>
>>>> When allocating the mbuf for the copy from a mempool using pinned
>> external
>>>> buffers, the external flag in this mbuf was not preserved.
>>>>
>>>> Fixes: c3a90c381daa ("mbuf: add a copy routine")
>>>>
>>>> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
>>>
>>> Applied, thanks.
>>>
>>>
>>>
>> Hi All. I see this is not marked for stable release. Is it deliberate
>> because of the flags changes ?
> 
> IIRC, the consensus was that using pinned external buffers is considered exotic, so the bug is unlikely to occur in real applications. And if it did happen, we would have heard about it.
> 
> But, since you ask, we really should have left that decision to the stable tree maintainers.
> 

Thanks Morten. Background knowledge and context is important, so it's
fine you made a decision on it, I just wanted to check.

> -Morten
> 


      reply	other threads:[~2026-02-26 10:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 12:04 [PATCH] mbuf: fix packet copy Morten Brørup
2025-11-24 13:35 ` Morten Brørup
2025-11-28 10:50 ` Morten Brørup
2025-12-18 16:12 ` Morten Brørup
2026-01-03 17:46 ` Morten Brørup
2026-01-11 15:19   ` Konstantin Ananyev
2026-01-11 17:43     ` Morten Brørup
2026-01-12 10:56       ` Konstantin Ananyev
2026-01-12 10:58   ` Konstantin Ananyev
2026-01-16 11:16 ` [PATCH v2] " Morten Brørup
2026-01-16 17:06   ` Stephen Hemminger
2026-01-16 17:16     ` Morten Brørup
2026-01-16 17:18       ` Stephen Hemminger
2026-01-20  7:24 ` [PATCH v3] " Morten Brørup
2026-02-10 17:21   ` Thomas Monjalon
2026-02-25 15:58     ` Kevin Traynor
2026-02-25 17:17       ` Morten Brørup
2026-02-26 10:01         ` Kevin Traynor [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=49efe45f-e396-4a25-b789-17719a783921@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@huawei.com \
    --cc=mb@smartsharesystems.com \
    --cc=stable@dpdk.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox