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 49627455B9 for ; 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 466284066D; Sun, 7 Jul 2024 20:46:11 +0200 (CEST) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by mails.dpdk.org (Postfix) with ESMTP id ABFD3402CF for ; Sun, 7 Jul 2024 20:46:08 +0200 (CEST) Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2eaa89464a3so33867331fa.3 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=pBXOckqjb73mNGJoP3L30v2J6EjoPVekQgP7AG+9+dEoy4Ux+s2l4jR9XswGwdpMMR W2UK8dVHBLDnPJ8j85eY0v0tq84KnJJCjeyXM0ISL7d6QNHgBxXKiFsV1UVYhyNM7KPi 09fH4n9/8WJc+jML8C7tzxZgP8nFBDb7mxg5vUUjmQ4aQMnmeLnVGTc2t0q1DKgszGyA wxVb7YR+GJMh+NnLZWVzQ0nY2/EElCbU+cUHegxMeP7dP3SOiImC+GK7TnmHxJsGEOyH WVC70MbTXNf4shIO9yYa/GygPJBOJWPGvRSxIC/0qy+03k0GyjWVwdnhf+Jx0cWJjyvD sDKg== X-Forwarded-Encrypted: i=1; AJvYcCWaoRF+wyhqtdJh6v986PTynt6xaxeAHMGvq2eFw960sDdJtjwNWM6FSG1x2w4zrPGrggPBbUdCC7prgdX02w4= X-Gm-Message-State: AOJu0Yysfy9V3aPjfjQ/47ClDzkeR8RhLPEXUryHg3J4MKx3bKXDugBy 2j43ZhCwqPCKbOXkyRbl9bFP5lAAkjqsMMZMNQXuaW2kfb4ST15kx9vkWoE2OmR9KBfVAxJz1JK Iskz66nz3hItrHahVVXBDf+0DglFKCyaO0g== 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-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.