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 21891A00C5; Thu, 7 May 2020 14:12:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F0A531DC27; Thu, 7 May 2020 14:12:37 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 8E65E1DA91 for ; Thu, 7 May 2020 14:12:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588853555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VGVudG78Nsf/ZobIzkVvHBVSmvd0I6NUyy85uHGkcxE=; b=GWTt4FgSS2TPFYZIGtak0FLT1RohmIdv6o+8yPm+Pe8yTEF8foEmkNdx0hxI7zTSkCwhbY 8EggmDqggv0riulg39huaVKTSAtX3MJoNYVx0w+tKe1IVcrS3c/OUfSJAyNd+mCt9RNU6Y pVQUBp+YqizlMwp8ZEwS0OgvI+pMIR4= Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-315-xOtFl8plOxObTAzcd_0e6Q-1; Thu, 07 May 2020 08:12:34 -0400 X-MC-Unique: xOtFl8plOxObTAzcd_0e6Q-1 Received: by mail-vk1-f199.google.com with SMTP id j3so1871805vkk.8 for ; Thu, 07 May 2020 05:12:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hPf8izMaI5wjwp3GjULKlq7QlA00cU1DYiQE8gWmdAU=; b=t5qf13Vgg5cY8KMUbxRnUqsAYcQhzKPeCaKuwEILKnt+bVraUTcUGBfsZg0F5SKlXy CzMF8tNHLA4jfJr9vUglL+K6ssv6FOYZUPPsK2darWghnSUcQ7Z7XE3N4a8Kksz+GWOT MMScjEngM8uTxU4QwYVYyUszetZW+U2pW8n8n7sW3PqsKMtLToDv1R8K2RWKSr9YqbtU sKlFg0PwUdAI4RM6KSZTPjHuMvVQeR3prMfiHWb2w4NsfguTiccetnc/kleMShzJc1nZ mB4w/cjbr942yYcp+GtNbABYHZBpfV7GH4/JsUPtvpPZ38220YsrcUgf8WPkYDXHFz7Q p5JA== X-Gm-Message-State: AGi0PuYuDQ+WQSusNo6g2Ae75dy2IZUK8EtTXtBLwyq+QY9xPu+JQERw czctJP2OmalPVNrfL+EK5Z4Dm9jdVnYh+GuJOjJXJ/Oure1xaFUC/OO5xXTwelr9CTb5Jv3mYMj wDlFYSOlTLQMGfsdHms0= X-Received: by 2002:a67:ff95:: with SMTP id v21mr12267874vsq.105.1588853553181; Thu, 07 May 2020 05:12:33 -0700 (PDT) X-Google-Smtp-Source: APiQypINW45oYfGtjXrlmz1JU+SmWCWZt24at0sX8oo/OvH3/o2Yuueq1uh8PcBG8aol9cw1L1nad9Fa0zNKM5hBENc= X-Received: by 2002:a67:ff95:: with SMTP id v21mr12267838vsq.105.1588853552614; Thu, 07 May 2020 05:12:32 -0700 (PDT) MIME-Version: 1.0 References: <1586256364-185699-1-git-send-email-bingz@mellanox.com> <1588837269-360196-1-git-send-email-bingz@mellanox.com> In-Reply-To: From: David Marchand Date: Thu, 7 May 2020 14:12:21 +0200 Message-ID: To: "Burakov, Anatoly" , Bing Zhao Cc: Thomas Monjalon , dev , dpdk stable , sergio.gonzalez.monroy@intel.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] mem: fix the alloc size roundup overflow 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" On Thu, May 7, 2020 at 1:55 PM Burakov, Anatoly wrote: > > On 07-May-20 8:41 AM, Bing Zhao wrote: > > The size checking is done in the caller. The size parameter is an > > unsigned (64b wide) right now, so the comparison with zero should be > > enough in most cases. But it won't help in the following case. > > If the allocating request input a huge number by mistake, e.g., some > > overflow after the calculation (especially subtraction), the checking > > in the caller will succeed since it is not zero. Indeed, there is not > > enough space in the system to support such huge memory allocation. > > Usually it will return failure in the following code. But if the > > input size is just a little smaller than the UINT64_MAX, like -2 in > > signed type. > > The roundup will cause an overflow and then "reset" the size to 0, > > and then only a header (128B now) with zero length will be returned. > > The following will be the previous allocation header. > > It should be OK in most cases if the application won't access the > > memory body. Or else, some critical issue will be caused and not easy > > to debug. So this issue should be prevented at the beginning, like > > other big size failure, NULL pointer should be returned also. > > > > Fixes: fdf20fa7bee9 ("add prefix to cache line macros") > > Cc: stable@dpdk.org > > > > Signed-off-by: Bing Zhao > > --- > > v2: add unit test for this case > > --- > > app/test/test_malloc.c | 12 ++++++++++++ > > lib/librte_eal/common/malloc_heap.c | 3 +++ > > 2 files changed, 15 insertions(+) > > > > diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c > > index 40a2f50..a96c060 100644 > > --- a/app/test/test_malloc.c > > +++ b/app/test/test_malloc.c > > @@ -846,6 +846,18 @@ > > if (bad_ptr !=3D NULL) > > goto err_return; > > > > + /* rte_malloc expected to return null with size will cause overfl= ow */ > > + align =3D RTE_CACHE_LINE_SIZE; > > + size =3D (size_t)-8; > > + > > + bad_ptr =3D rte_malloc(type, size, align); > > + if (bad_ptr !=3D NULL) > > + goto err_return; > > + > > + bad_ptr =3D rte_realloc(NULL, size, align); > > + if (bad_ptr !=3D NULL) > > + goto err_return; > > You're mixing space and tabs as indentation here. Will fix while applying. > > Otherwise, > > Reviewed-by: Anatoly Burakov You acked the v1, so I will go with it. Thanks for the work Bing, Anatoly. --=20 David Marchand