From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 2A9D0A0582;
	Tue, 22 Nov 2022 16:52:30 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 1E34442D81;
	Tue, 22 Nov 2022 16:52:30 +0100 (CET)
Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com
 [209.85.167.48]) by mails.dpdk.org (Postfix) with ESMTP id 234A2427EB
 for <dev@dpdk.org>; Tue, 22 Nov 2022 16:52:28 +0100 (CET)
Received: by mail-lf1-f48.google.com with SMTP id g7so24202634lfv.5
 for <dev@dpdk.org>; Tue, 22 Nov 2022 07:52:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:from:to:cc:subject:date
 :message-id:reply-to;
 bh=MbXWuKG+tAEg9z9mrIYT473o0iTzbDoLL3pem1a2pSk=;
 b=DAzBwz94AAWzQLzcTVHjiGWIdhfrLRJw+yYafneNN5HUAMVcZ5aUOOhW6upLMMXYpP
 37/9ptTgvegqM0+TI3jDj1S/6edLtVf/2cetRJ5FCSGyD+dkYuxZuIlLkRIMAm/nGpOV
 qnoZhLwew52gEdAjal0HPsUxSamkTuVQgnpgfu9LSTAU5hDJLBTZwdZ8if3GuMD8528j
 RRl+q52Dd+HK6lKOnvS2scKyGHbjzNZ3vyVc8hSxF/CsrRmhV097XjLF6jI448tF7XAq
 jwtMnlncjC7AhC6sDlMWa8B58hwCnfSwYJms+bTj3PRgCAVo+l/CJ0gTQIPZeiobZtYu
 NUGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=MbXWuKG+tAEg9z9mrIYT473o0iTzbDoLL3pem1a2pSk=;
 b=pti1dt/eDpw07LPj5ZhsO6ogH9x7SVqoILdmufCfTQWr5wssMq65Cld/Z3Ua7lT7Yq
 dy3QVb7oQwib0k3yij3X1zLrF9Yk7Zjb60yCds4JBmQGhIU1l2ut5CuAcOMfhTxIAKpg
 FWw7WUEcA3ZLmg4zsOSwfR1Cj5K2Dy4vrHt6MszsVFGBazdhdRILmhioCXWJOgTGT39j
 zPAB45hDgDizID6/VCYTeuLFPtMDEAKyLV3Ok1Emrt10bkAVuWFP4aRfqUv0D/9wn23J
 W78y68bIxIlYBWkfEDsdQpvZtJtq0uj4vN6+sABfxudbH5rswhP08SugPLUZsXQN6KBD
 wHdA==
X-Gm-Message-State: ANoB5pn8fxV1pb2WoqBSU0SQdNxc/v8MHNJ0Vbrsq7SFbnnj29s1soiR
 6+cLNYyfERUQ+NfuJTRz9qsgtvyoBt0=
X-Google-Smtp-Source: AA0mqf5oyApoFocIzIkDk5idT16R8b6Lump+FAeBMONYJPlsn9/+SjsjeTeqUJnaJBpa2oXaJjpOpA==
X-Received: by 2002:a05:6512:4023:b0:4a2:5008:d235 with SMTP id
 br35-20020a056512402300b004a25008d235mr8687065lfb.7.1669132347757; 
 Tue, 22 Nov 2022 07:52:27 -0800 (PST)
Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru.
 [37.110.65.23]) by smtp.gmail.com with ESMTPSA id
 j8-20020ac24548000000b00499fe9ce5f2sm2561282lfm.175.2022.11.22.07.52.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 22 Nov 2022 07:52:27 -0800 (PST)
Date: Tue, 22 Nov 2022 18:52:26 +0300
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: okaya@kernel.org
Cc: dev@dpdk.org
Subject: Re: [PATCH v2 05/11] malloc: malloc_elem_join_adjacent_free can
 return null
Message-ID: <20221122185226.4662bd66@sovereign>
In-Reply-To: <20221121223208.1147154-6-okaya@kernel.org>
References: <20221121223208.1147154-1-okaya@kernel.org>
 <20221121223208.1147154-6-okaya@kernel.org>
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

2022-11-21 17:32 (UTC-0500), okaya@kernel.org:
> From: Sinan Kaya <okaya@kernel.org>
> 
> In malloc_heap_add_memory result of call to malloc_elem_join_adjacent_free
> is dereferenced here and may be null.

It may not:
"malloc_elem_join_adjacent_free()" never returns NULL by definition.
Would annotating "malloc_elem_join_adjacent_free()" result
(and maybe the argument too)
convince codeql that the check is not needed?

A comment to the series:

I'm against adding extra checks *only* to silence some tool,
not because they're overly defensive,
but because they misrepresent the code assumptions,
making the understanding harder.
Returning false if assumptions are broken is arguably no better then crashing,
because this means that either the internal state is inconsistent
or the caller has supplied invalid arguments (logical error up the stack).