DPDK patches and discussions
 help / color / mirror / Atom feed
From: Mihai Brodschi <mihai.brodschi@broadcom.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, Jakub Grajciar <jgrajcia@cisco.com>
Cc: dev@dpdk.org, stable@dpdk.org,
	Mihai Brodschi <mihai.brodschi@broadcom.com>
Subject: Re: [PATCH v2] net/memif: fix buffer overflow in zero copy Rx
Date: Mon, 8 Jul 2024 06:39:03 +0300	[thread overview]
Message-ID: <a4679798-5868-4f8b-a137-78abd36cf59e@broadcom.com> (raw)
In-Reply-To: <2d6fba2f-f522-4d0a-abbb-38d938f61af2@broadcom.com>

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]



On 07/07/2024 21:46, Mihai Brodschi wrote:
> 
> 
> On 07/07/2024 18:18, Mihai Brodschi wrote:
>>
>>
>> On 07/07/2024 17:05, Ferruh Yigit wrote:
>>>
>>> My expectation is numbers should be like following:
>>>
>>> Initially:
>>>  size = 256
>>>  head = 0
>>>  tail = 0
>>>
>>> In first refill:
>>>  n_slots = 256
>>>  head = 256
>>>  tail = 0
>>>
>>> Subsequent run that 32 slots used:
>>>  head = 256
>>>  tail = 32
>>>  n_slots = 32
>>>  rte_pktmbuf_alloc_bulk(mq, buf[head & mask], n_slots);
>>>   head & mask = 0
>>>   // So it fills first 32 elements of buffer, which is inbound
>>>
>>> This will continue as above, combination of only gap filled and head
>>> masked with 'mask' provides the wrapping required.
>>
>> If I understand correctly, this works only if eth_memif_rx_zc always processes
>> a number of packets which is a power of 2, so that the ring's head always wraps
>> around at the end of a refill loop, never in the middle of it.
>> Is there any reason this should be the case?
>> Maybe the tests don't trigger the crash because this condition holds true for them?
> 
> Here's how to reproduce the crash on DPDK stable 23.11.1, using testpmd:
> 
> Server:
> # ./dpdk-testpmd --vdev=net_memif0,id=1,role=server,bsize=1024,rsize=8 --single-file-segments -l2,3 --file-prefix test1 -- -i
> 
> Client:
> # ./dpdk-testpmd --vdev=net_memif0,id=1,role=client,bsize=1024,rsize=8,zero-copy=yes --single-file-segments -l4,5 --file-prefix test2 -- -i
> testpmd> start
> 
> Server:
> testpmd> start tx_first
> testpmt> set burst 15
> 
> At this point, the client crashes with a segmentation fault.
> Before the burst is set to 15, its default value is 32.
> If the receiver processes packets in bursts of size 2^N, the crash does not occur.
> Setting the burst size to any power of 2 works, anything else crashes.
> After applying this patch, the crashes are completely gone.

Sorry, this might not crash with a segmentation fault. To confirm the mempool is
corrupted, please compile DPDK with debug=true and the c_args -DRTE_LIBRTE_MEMPOOL_DEBUG.
You should see the client panic when changing the burst size to not be a power of 2.
This also works on the latest main branch.

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4215 bytes --]

  reply	other threads:[~2024-07-08  3:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 21:01 Mihai Brodschi
2024-07-01  4:57 ` Patrick Robb
2024-07-07  2:12 ` Ferruh Yigit
2024-07-07  5:50   ` Mihai Brodschi
2024-07-07 14:05     ` Ferruh Yigit
2024-07-07 15:18       ` Mihai Brodschi
2024-07-07 18:46         ` Mihai Brodschi
2024-07-08  3:39           ` Mihai Brodschi [this message]
2024-07-08 11:45             ` Ferruh Yigit
2024-07-19  9:03               ` Ferruh Yigit
2024-08-31 13:38                 ` Mihai Brodschi
2024-10-10  2:00                   ` Ferruh Yigit
2024-10-10  2:33 ` Ferruh Yigit
2024-07-07  5:31 Mihai Brodschi

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=a4679798-5868-4f8b-a137-78abd36cf59e@broadcom.com \
    --to=mihai.brodschi@broadcom.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=jgrajcia@cisco.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 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).