From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4AF2A455BB; Sun, 7 Jul 2024 20:46:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 37CA5402CF; Sun, 7 Jul 2024 20:46:10 +0200 (CEST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by mails.dpdk.org (Postfix) with ESMTP id AA65D402C4 for ; Sun, 7 Jul 2024 20:46:08 +0200 (CEST) Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2ee910d6a9dso28615471fa.1 for ; Sun, 07 Jul 2024 11:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1720377968; x=1720982768; darn=dpdk.org; h=content-language:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=MSb5Xnxg49NI2Txj2qS6lnEnzGdTFECAQIz7gx7z1VI=; b=Ipri2SUtZHqI6y6Cg4KIIlFc2SOgWvSq8Id5MgQpBnhetlybuA/E7OrG16WcNZN5cT Onf80EURqftwUAhFawvjJO4FUuTj4YZoL5LltiNhdOlW1lA2Wl2Y8j5DZAwA41ficOcm F3QRePwiD2VINad665J0SRgJNG3lbh8bWavcY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720377968; x=1720982768; h=content-language:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=MSb5Xnxg49NI2Txj2qS6lnEnzGdTFECAQIz7gx7z1VI=; b=xGnELLWryCVW6s+P4BTNEvgdlnWHkveEPB4eZM3VCkjfbD+/5WaumqFjePgTvZiR7m hFJsie0ItsEIWUKaqd5cgURYXVvPGWEiT9Lj32m21iwXhubq0Eus/SSGQXuc3D1m9Xgl 5P+88gJIHxT+qxvi06S5Zq1n2Hzbw5POiFrVj1Oe1lmSxDya69XE0mEggQ1mOLT/Iay0 R3vx4tUsLszzkrNZAFseX9ZwwAtwM/Fm98EAWmuSImrI778oMjSCX0dqSNszUK+q19kP Fde1ENWxXCktEDT2ouK6T+LRClaI/PjjzgEk+V2Ffdw89+buSCcqlw4YT05OLtIH2+M3 qmXw== X-Gm-Message-State: AOJu0YwiKrBnybEUjwGD31immQ7jm3p386Cj1YUNEm6LgGiWRl7PoJp0 8fkZoMjKB3UDyDEBmFLYUOc1A/k7ggJjRaL9a2bYmxCst9oSTguWyHWr5BoYrRSRZMK6qGCU3Gd 6oQgi8BJEHib2QK4zePeiyF+WJt71XQ== X-Google-Smtp-Source: AGHT+IHa0LHIwv7BZdZNHjR+q7NihiKpYFwW1MlEcpiAaQGnPCfjSoHgIiVfY8BIJR8vusZU6e51dw== X-Received: by 2002:a2e:8193:0:b0:2ee:7a54:3b08 with SMTP id 38308e7fff4ca-2ee8ed62d3emr66668271fa.3.1720377967796; Sun, 07 Jul 2024 11:46:07 -0700 (PDT) Received: from [192.168.0.8] ([92.81.76.237]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4264a1d16b0sm135502085e9.7.2024.07.07.11.46.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jul 2024 11:46:06 -0700 (PDT) Message-ID: <2d6fba2f-f522-4d0a-abbb-38d938f61af2@broadcom.com> Date: Sun, 7 Jul 2024 21:46:03 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] net/memif: fix buffer overflow in zero copy Rx To: Ferruh Yigit , Jakub Grajciar Cc: dev@dpdk.org, stable@dpdk.org, Mihai Brodschi References: <8bf5e505-191b-46ea-8b90-0ed4fc15d306@broadcom.com> <75a9c5d9-da21-4e78-b637-84f152daae30@broadcom.com> From: Mihai Brodschi In-Reply-To: <75a9c5d9-da21-4e78-b637-84f152daae30@broadcom.com> Content-Language: en-US Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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. -- 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.