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 82BF7431E0; Mon, 23 Oct 2023 11:07:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6E55040689; Mon, 23 Oct 2023 11:07:36 +0200 (CEST) Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by mails.dpdk.org (Postfix) with ESMTP id 67D0F40270 for ; Mon, 23 Oct 2023 11:07:33 +0200 (CEST) Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-1e9e4636ce6so590639fac.0 for ; Mon, 23 Oct 2023 02:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1698052053; x=1698656853; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dLVmWsTh9de9YCgZApy97aUPvgxYGLlheEj/SwHu8HE=; b=JltW5+TdludG+WaSvCZscOZ/q/dLQ/4u8NikhzJ0k1xfJ9Y0sG03nzVS16gwbfR0e8 GDs+8x5huP1b++psRKjwzrQEd4lIjC7UD/aiM0jQdYUGCLAYMaVegziIhHH8H4yV3Tyz xe2f3TkMq0m/cyRkqgisG57UVIh/3kiOe7gu/D2KyI3q5w4uTGkWuwAsL0HmY13eOk9U Xak1PolqgXDfjeIQ6uYJtjpbRKAY09gPP5mKtnbYUBWG/6ITUeczNtlCWdHRoIhKznF1 u5hYB5Yi3I8oJY0Jc6+B8S3q7SvNHfrc8DJPEyYZuri55nqRq8URf5yH8kQEc+kSl6i1 vvIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698052053; x=1698656853; 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=dLVmWsTh9de9YCgZApy97aUPvgxYGLlheEj/SwHu8HE=; b=pyNliePM10pjFcvmW5tPRf0jLvgEGTDZKpN4ClGDQ8BsWc004xaZxeP2f26uiNDJuo rnG2GVev4xhsGnIM/YtJ4IHux1H2Eq28MTfUbuqnphWw3ctKkG21H+0EvYnI8FV+OuCG cHq39uiq6ENDi5ucztwMHrvX8wGrDqNWsRZKXOowUqd739IlsZDsIlaZFP4RQjyPC7s2 srSinoWKW9w5UOrFSTWccpBvz5xFMlKMCv6ZaQMvSYQDgE8LbRFAYMyo1cmJ6N9oQiCG /LAUZ6dcGMTdKM1q1lgsgS6umhARdh/LeO6F1IxGBQJuTgCayMrtONQjNxKfaXkg9buN Kszg== X-Gm-Message-State: AOJu0Yyw8N8vDu7M8lLc3sBr+WaXY3AL9yukYBv3oNUH0FhtFzPvxLWI ++SBglNTIu9xP8Rl0QDPG2IcFg5FjGesAEwmB3MxBA== X-Google-Smtp-Source: AGHT+IEUSuPXp1dGnRfM1mpRlaMOD6mUSra4p0AzB9Zt5ibHjhedmTQt4ehXAzCc4cQD9XTTCdAJH4p1HKOjrls64Jg= X-Received: by 2002:a05:6870:96a1:b0:1e9:8ab9:11ca with SMTP id o33-20020a05687096a100b001e98ab911camr9672667oaq.3.1698052052384; Mon, 23 Oct 2023 02:07:32 -0700 (PDT) MIME-Version: 1.0 References: <20230912090415.48709-1-changfengnan@bytedance.com> <20231022232234.42168129@sovereign> In-Reply-To: <20231022232234.42168129@sovereign> From: Fengnan Chang Date: Mon, 23 Oct 2023 17:07:21 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] eal: fix modify data area after memset To: Dmitry Kozlyuk Cc: anatoly.burakov@intel.com, dev@dpdk.org, xuemingl@mellanox.com Content-Type: multipart/alternative; boundary="00000000000065360d06085e8d7b" 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 --00000000000065360d06085e8d7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dmitry Kozlyuk =E4=BA=8E2023=E5=B9=B410=E6=9C=88= 23=E6=97=A5=E5=91=A8=E4=B8=80 04:22=E5=86=99=E9=81=93=EF=BC=9A > > 2023-09-22 16:12 (UTC+0800), Fengnan Chang: > > ping > > > > Fengnan Chang =E4=BA=8E2023=E5=B9=B49=E6= =9C=8812=E6=97=A5=E5=91=A8=E4=BA=8C 17:05=E5=86=99=E9=81=93=EF=BC=9A > > > > > > Let's look at this path: > > > malloc_elem_free > > > ->malloc_elem_join_adjacent_free > > > ->join_elem(elem, elem->next) > > > > > > 0. cur elem's pad > 0 > > > 1. data area memset in malloc_elem_free first. > > > 2. next elem is free, try to join cur elem and next. > > > 3. in join_elem, try to modify inner->size, this address had > > > memset in step 1, it casue the content of addrees become non-zero. > > > > > > If user call rte_zmalloc, and pick this elem, it can't get all > > > zero'd memory. > > malloc_elem_join_adjacent_free() always calls memset() after join_elem(), > for the next and the previous element respectively. when try to call join_elem() for the next element in malloc_elem_join_adjacent_free(), the memset is try to memset *next* element, but join_elem() is update *current* element's content, which shoudn't happen, it's two different element. > How to reproduce this bug? when I test this patch, https://patches.dpdk.org/project/dpdk/patch/20230831111937.60975-1-changfen= gnan@bytedance.com/ I have a case try to alloc 64/128/192 size object and free with 16 threads, after every alloc I'll check wheather all content is 0 or not. It's not easy to reproduce, you can have a try, it's easier to find this problem in code level. --00000000000065360d06085e8d7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> =E4=BA=8E2023=E5=B9=B410=E6= =9C=8823=E6=97=A5=E5=91=A8=E4=B8=80 04:22=E5=86=99=E9=81=93=EF=BC=9A
>= ;
> 2023-09-22 16:12 (UTC+0800), Fengnan Chang:
> > ping
= > >
> > Fengnan Chang <changfengnan@bytedance.com> =E4=BA=8E2023=E5=B9=B49=E6= =9C=8812=E6=97=A5=E5=91=A8=E4=BA=8C 17:05=E5=86=99=E9=81=93=EF=BC=9A
>= ; > >
> > > Let's look at this path:
> > >= ; malloc_elem_free
> > > =C2=A0 =C2=A0->malloc_elem_join_adj= acent_free
> > > =C2=A0 =C2=A0 =C2=A0 ->join_elem(elem, elem= ->next)
> > >
> > > 0. cur elem's pad > 0=
> > > 1. data area memset in malloc_elem_free first.
> &= gt; > 2. next elem is free, try to join cur elem and next.
> > = > 3. in join_elem, try to modify inner->size, this address had
>= ; > > memset in step 1, it casue the content of addrees become non-ze= ro.
> > >
> > > If user call rte_zmalloc, and pick = this elem, it can't get all
> > > zero'd memory.
>= ;
> malloc_elem_join_adjacent_free() always calls memset() after join= _elem(),
> for the next and the previous element respectively.
whe= n try to call join_elem() for the next element in malloc_elem_join_adjacent= _free(),
the memset is try to memset next element, but join_elem(= ) is update current element's
content, which shoudn't ha= ppen, it's two different element.

> How to reproduce t= his bug?
when I test this patch,
I have a case try to alloc = 64/128/192 size object and free with 16 threads, after every
allo= c I'll check wheather all content is 0 or not.
It's not e= asy to reproduce, you can have a try, it's easier to find
thi= s problem in code level.
--00000000000065360d06085e8d7b--