From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4FC1AA00C5; Thu, 11 Jun 2020 09:27:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 59B303195; Thu, 11 Jun 2020 09:27:22 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id B71E32E81; Thu, 11 Jun 2020 09:27:20 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ED0445C00AF; Thu, 11 Jun 2020 03:27:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 11 Jun 2020 03:27:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= 5av1rw+9p/zGOEdw8dkfT3zqWiIKei86jLMyyyx4kqg=; b=tY0zBPng5PYKSqj8 9Hgpg2DKf35WjZ4cZdkMTNUr+Uz/WpQd5+FDZ8nT7zVnMS+s+pwXooGzU1aMfTcQ vCWFIzZ0SC7MR5ePpuNAf4QhTQ90eWjXp6+MUECK5QiW8q4csX/+iNRpSdCb3tF2 tXv42w3xPB37/eihU3SSFVJ/Lu78WB+dHU4POJ1ju5cH9aqtB6vRUUIENfy8FCPT 2A0wWFW+aH5fYXjJX0hPWOPhNT+FVg+5yli0vWwPYHcfH0u4HZ47ObEl6kRc4KMH ozpY+eH4Lt29fi3Nk4AoZx/dybnWs3Nnr+FEYjtEq9RjFcQ1L1yM6rj6U81VJ1Nn C8Ls0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=5av1rw+9p/zGOEdw8dkfT3zqWiIKei86jLMyyyx4k qg=; b=Cg1TI8JRyMDXtXNXLALIzWiLOb/5OlKVRX+PMGkvaH6FxDU0CAmvTJteO WrOrH98nkV6CjODageVe/4rBZm/smCwIis9FdFjvTHiJ2NBHdYxiUgVhcm2bDec+ bW/hbjRAosFLgcfEkTlT9uGiCqePbwKZ/ni/w9+9+vf3dDrz/HLnC1mDuyFDySQk 6WwYwTBisoY1r5mCPvxshiHLoJrJGyOCHzQU99PkBKeurwtwiHm3CF2cipDuFKGL 69qlHdyZCLNKj4tfG2pj79sk9VgC2jQFyuY5ZPpLyNDNPkc2PlFZQ65kj9R3kqLr yKuXDrMiieQWSVrkb/erBUCz40I7A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehjedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8ADEE3280059; Thu, 11 Jun 2020 03:27:17 -0400 (EDT) From: Thomas Monjalon To: Alexander Kozyrev Cc: stable@dpdk.org, dev@dpdk.org, rasland@mellanox.com, viacheslavo@mellanox.com, Olivier Matz Date: Thu, 11 Jun 2020 09:27:16 +0200 Message-ID: <21226006.vskTBKe033@thomas> In-Reply-To: <20200608075011.GN12564@platinum> References: <1591025056-16031-1-git-send-email-akozyrev@mellanox.com> <20200608075011.GN12564@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] mbuf: fix external mbufs pool boundaries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 08/06/2020 09:50, Olivier Matz: > On Mon, Jun 01, 2020 at 03:24:16PM +0000, Alexander Kozyrev wrote: > > Memzones are created in testpmd in order to test external data > > buffers functionality. Each memzone is 2Mb in size and divided among > > the pool of external memory buffers. > > > > Memzone may not always be fully utilized because mbufs size can vary > > and some space can be left unused at the tail of a memzone. This is > > not handled properly and mbuf can get the address of this leftover > > space since this address is still valid (part of memzone), but there > > is not enough space to fit the whole packet data. As a result packet > > data may overflow and cause the memory corruption. > > > > Take mbuf size into account when distributing memory addresses from > > a memzone to external mbufs. Skip the remaining tail in case there > > is not enough room for a packet and move to a next memzone instead. > > > > Fixes: 6c8e50c2e5 ("mbuf: create pool with external memory buffers") > > Cc: stable@dpdk.org > > Signed-off-by: Alexander Kozyrev > > Acked-by: Viacheslav Ovsiienko > > Acked-by: Olivier Matz Applied, thanks Note: there is a blank line between Fixes/Cc block and Signed/Acked block.