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 8159E42B39; Thu, 18 May 2023 10:39:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1496442BAC; Thu, 18 May 2023 10:39:21 +0200 (CEST) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by mails.dpdk.org (Postfix) with ESMTP id E116640E25 for ; Thu, 18 May 2023 10:39:19 +0200 (CEST) Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-30935d343f7so1648042f8f.1 for ; Thu, 18 May 2023 01:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684399159; x=1686991159; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FLrxVmrksSoBFk9fp/ZmzI5g0tvDWMEP1vpSgoCIpZg=; b=l6qIDZmMcsbrhRaV3ZzPSuYg6cF/Rjck8JG0k8fjpyfCaZgHJbUGfjgLBbwOLCXTV4 Pr2qdR12gMXoqdU8zY2E3/v+1SJy/IedZ6997PQEE26xMSuPZCP50QLk5Cu94nO8L/uR 6FptXd+q1Oh50XH7+FkZU7I8GXZFMTpD0PvHxx+1G6w5lH4bPmH5zlAeLGfGkLzWXPPA kdUK7efIIytUp7qgj9xSS7JInbob71hNgYktMQTVSPDNWcD0bmeyk4olY/GkzHRz9RpI zkHqtY2WE7WahG0zwyFsgkDloeiN5Af0Y/mOHunrpAkeGQ45xMAKyC2NafzwMGcYAbZO tUjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684399159; x=1686991159; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FLrxVmrksSoBFk9fp/ZmzI5g0tvDWMEP1vpSgoCIpZg=; b=Bl/UWM9C41B1WFRph2aCfAH+S9Z+DuLthLDpS+HMnU+/HneK/1NPh0QjnDKe3ZnDnA 3YP3GjCss/360H1410sWf4xvTjG+6D3QjZcGDzcS5NowReJ3w4NRUKsraa60c+bM4nYP h0iJehN0Ic7FG34E4+Jlr9/XnOWN24VuKtbVZ2Fo8QwpEJX2jfXdDjk3t+IrYuLJnU33 pryOjl3qbxyCao2HRBUcvh/tiZCLwcj4W/1HToeN6C7jvBhZ2q/DyO16YjI2RwOU//fU AJlly4auMC5hLTfiT3OBLIqWOv+7RTQJClDHVBF6AnoHGAIN+qmSn327KcC0s3LplQY5 73bA== X-Gm-Message-State: AC+VfDyfuLFaA5Zzj98+VRMLJffD9e7zRvfXjOSBHdsyzZNe3pwHDWM4 sYU8Tbn8YR4L2Tx0UVatB/19OgOI2QOiaGl8dIM= X-Google-Smtp-Source: ACHHUZ7/DC22t54b82bX1A2rdhmoCR67GVicsqy9h1GTLyhBzvpK8TyWKvclv8qhOcnP5US/KD0V2GEFGOpZCaBGFLY= X-Received: by 2002:a5d:4442:0:b0:2fe:f2d1:dcab with SMTP id x2-20020a5d4442000000b002fef2d1dcabmr766066wrr.58.1684399159394; Thu, 18 May 2023 01:39:19 -0700 (PDT) MIME-Version: 1.0 References: <20230516134146.480047-1-yasinncaner@gmail.com> <20230516082349.041c0e68@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35D87923@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87926@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87927@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87929@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87929@smartserver.smartshare.dk> From: Yasin CANER Date: Thu, 18 May 2023 11:37:24 +0300 Message-ID: Subject: Re: [PATCH] lib/mempool : rte_mempool_avail_count, fixing return bigger than mempool size To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: David Marchand , Stephen Hemminger , dev@dpdk.org, Yasin CANER , Olivier Matz , Andrew Rybchenko Content-Type: multipart/alternative; boundary="0000000000008e44a705fbf3bdeb" 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 --0000000000008e44a705fbf3bdeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I found a second free command in my code and removed it. David pointed to the right . On the other hand, do you think we need to avoid miscalculations? Is it better to patch it or not? or it needs to be aware of the second free command. Sharing more information about env. # ethtool -i mgmt driver: virtio_net version: 1.0.0 firmware-version: expansion-rom-version: bus-info: 0000:00:03.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no NAME=3D"Ubuntu" VERSION=3D"20.04.4 LTS (Focal Fossa)" ID=3Dubuntu ID_LIKE=3Ddebian PRETTY_NAME=3D"Ubuntu 20.04.4 LTS" VERSION_ID=3D"20.04" Linux spgw-dpdk 5.4.0-146-generic #163-Ubuntu SMP Fri Mar 17 18:26:02 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Best regards. Morten Br=C3=B8rup , 17 May 2023 =C3=87ar, 15:23 = tarihinde =C5=9Funu yazd=C4=B1: > > From: David Marchand [mailto:david.marchand@redhat.com] > > Sent: Wednesday, 17 May 2023 13.53 > > > > On Wed, May 17, 2023 at 11:05=E2=80=AFAM Morten Br=C3=B8rup > > > wrote: > > > > On Tue, 16 May 2023 13:41:46 +0000 > > > > Yasin CANER wrote: > > > > > > > > > From: Yasin CANER > > > > > > > > > > after a while working rte_mempool_avail_count function returns > bigger > > > > > than mempool size that cause miscalculation > rte_mempool_in_use_count. > > > > > > > > > > it helps to avoid miscalculation rte_mempool_in_use_count. > > > > Is this issue reproduced with an application of the reporter, or a > > DPDK in-tree application? > > > > > > > > > > > > > > Bugzilla ID: 1229 > > > > > > > > > > Signed-off-by: Yasin CANER > > > > > > > > An alternative that avoids some code duplication. > > > > > > > > diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c > > > > index cf5dea2304a7..2406b112e7b0 100644 > > > > --- a/lib/mempool/rte_mempool.c > > > > +++ b/lib/mempool/rte_mempool.c > > > > @@ -1010,7 +1010,7 @@ rte_mempool_avail_count(const struct > rte_mempool > > > > *mp) > > > > count =3D rte_mempool_ops_get_count(mp); > > > > > > > > if (mp->cache_size =3D=3D 0) > > > > - return count; > > > > + goto exit; > > > > > > This bug can only occur here (i.e. with cache_size=3D=3D0) if > > rte_mempool_ops_get_count() returns an incorrect value. The bug should = be > > fixed there instead. > > > > > > > > > > > > MB (continued): The bug must be in the underlying mempool driver. I > took a > > look at the ring and stack drivers, and they seem fine. > > > > Or it could indicate a double free (or equivalent) issue from the > > application (either through direct call to mempool API, or indirectly > > like sending/freeing an already sent/freed packet for example). > > Good point, David. > > @Yasin, if you build DPDK and your application with > RTE_LIBRTE_MEMPOOL_DEBUG set in config/rte_config.h, the mempool cookies > should catch any double frees. > > --0000000000008e44a705fbf3bdeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

I found a second free comm= and in my code and removed it. David pointed to the right .

<= /div>
On the other hand, do you think we need to avoid miscalculations?= Is it better to patch it or not?

or it needs = to be aware of the second free command.=C2=A0

Shar= ing more information about env.

# ethtool -i mgmt<= br>driver: virtio_net
version: 1.0.0
firmware-version:
expansion-r= om-version:
bus-info: 0000:00:03.0
supports-statistics: yes
suppor= ts-test: no
supports-eeprom-access: no
supports-register-dump: no
= supports-priv-flags: no

NAME=3D"Ubuntu&qu= ot;
VERSION=3D"20.04.4 LTS (Focal Fossa)"
ID=3Dubuntu
ID= _LIKE=3Ddebian
PRETTY_NAME=3D"Ubuntu 20.04.4 LTS"
VERSION_I= D=3D"20.04"

Linux spgw-dpdk 5.4.0-14= 6-generic #163-Ubuntu SMP Fri Mar 17 18:26:02 UTC 2023 x86_64 x86_64 x86_64= GNU/Linux



Best regar= ds.

Morten Br=C3=B8rup <mb@smartsharesystems.com>, 17 May 2023 =C3=87ar, 15:23 t= arihinde =C5=9Funu yazd=C4=B1:
> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Wednesday, 17 May 2023 13.53
>
> On Wed, May 17, 2023 at 11:05=E2=80=AFAM Morten Br=C3=B8rup <mb@smartsharesystem= s.com>
> wrote:
> > > On Tue, 16 May 2023 13:41:46 +0000
> > > Yasin CANER <yasinncaner@gmail.com> wrote:
> > >
> > > > From: Yasin CANER <yasin.caner@ulakhaberlesme.com.tr= >
> > > >
> > > > after a while working rte_mempool_avail_count function = returns bigger
> > > > than mempool size that cause miscalculation rte_mempool= _in_use_count.
> > > >
> > > > it helps to avoid miscalculation rte_mempool_in_use_cou= nt.
>
> Is this issue reproduced with an application of the reporter, or a
> DPDK in-tree application?
>
>
> > > >
> > > > Bugzilla ID: 1229
> > > >
> > > > Signed-off-by: Yasin CANER <yasin.caner@ulakhaberlesme.c= om.tr>
> > >
> > > An alternative that avoids some code duplication.
> > >
> > > diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mem= pool.c
> > > index cf5dea2304a7..2406b112e7b0 100644
> > > --- a/lib/mempool/rte_mempool.c
> > > +++ b/lib/mempool/rte_mempool.c
> > > @@ -1010,7 +1010,7 @@ rte_mempool_avail_count(const struct r= te_mempool
> > > *mp)
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0count =3D rte_mempool_ops_g= et_count(mp);
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (mp->cache_size =3D= =3D 0)
> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retu= rn count;
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0goto= exit;
> >
> > This bug can only occur here (i.e. with cache_size=3D=3D0) if
> rte_mempool_ops_get_count() returns an incorrect value. The bug should= be
> fixed there instead.
> >
> >
> >
> > MB (continued): The bug must be in the underlying mempool driver.= I took a
> look at the ring and stack drivers, and they seem fine.
>
> Or it could indicate a double free (or equivalent) issue from the
> application (either through direct call to mempool API, or indirectly<= br> > like sending/freeing an already sent/freed packet for example).

Good point, David.

@Yasin, if you build DPDK and your application with RTE_LIBRTE_MEMPOOL_DEBU= G set in config/rte_config.h, the mempool cookies should catch any double f= rees.

--0000000000008e44a705fbf3bdeb--