Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7941787rdb; Thu, 4 Jan 2024 12:40:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IExkNpGm6yDAVl4In0aPjxiT8DvApznF2D77Ln+SMyQ9wTOzFpdMl5rBi6kde4fvCs1+7Fe X-Received: by 2002:a0d:e890:0:b0:5e7:43f2:38a with SMTP id r138-20020a0de890000000b005e743f2038amr1195361ywe.100.1704400852919; Thu, 04 Jan 2024 12:40:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704400852; cv=none; d=google.com; s=arc-20160816; b=WQlMj++iJOi26SK6DCFYPRShdgIVuX7aWwwJbx/EoFAaV/FeaN2GLMVixns5+hKEer Xl9kqQey4jsy8lWgiYqeuPszG2STNF9KeX7jhW4jCiXORxOQjZQslhdOPKPAPOjT7i7S qsaUu7bhPhNhVMlbAbpdfrZryu0xK1K82upevB6Uebb4aRoQK1a7OgwcQqqoBRvtF2lU 0Mh50LxaKiI+xW6Rn/5FoPK8qQZlDQMj/5+OLwGzdlLpDto7zk560hrM3S9zKmHvkoCX cKCQLyVlJmOW0+DPKaGYZapwaToxuQMcnWfNSkyca0tdSX4EsgPE1aNhdzMl1CU6rFXo SJXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=k/hXnl0ZwBMpejWqlz2pCsEgW8c1xMAgjNOrifWixGA=; fh=72oIVmoWZu0bRLQQhhoxZjadzq410CBoQhi4GleQpuY=; b=pdTyt2x76YXeQ0Sw98T587aTdmPqojclaOGHT2eXlhNnVjZ7Dzvcrx768dwRYN27to rnNp38QaL6WqzIvzatFC6Ichb6UU19gxMDIplCmKu86MFxQ8deLCjMHzCXyRvak3kQ7a QxQ8bql+jOUtuQGdvJvufXgUhzsVlGJ1+vgnvt0AezDmFVOMXCpCDDcEShmm6jjATdfC RSTfWmhNC+a1KodbK4SI1T05vZVOT6dUiAGVShipVvTZE2CmEqL6L53/KTNuP3+ZncPr 1ATmTbcL+PtMUkN2CmAmVyCJuyZuScZJ9Xx8i8bxHZGz/bBPDd1oKXkxLEAYvVb+gbbK 8RXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=serrNK0u; spf=pass (google.com: domain of linux-kernel+bounces-17201-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17201-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id y3-20020a05620a0e0300b007815e61f3dfsi232574qkm.322.2024.01.04.12.40.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 12:40:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17201-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=serrNK0u; spf=pass (google.com: domain of linux-kernel+bounces-17201-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17201-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A267D1C22974 for ; Thu, 4 Jan 2024 20:40:52 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 827C72C191; Thu, 4 Jan 2024 20:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="serrNK0u" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A65631E503; Thu, 4 Jan 2024 20:40:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 068EAC433C7; Thu, 4 Jan 2024 20:40:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704400838; bh=wfKfnH7YLdSwjVnqaoKaRKpcS4tFflrKLF1bSoIVlwM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=serrNK0urNmROd5qJ+kO4+UwWgxa+6ka/RPhkgLxXQHzVriygEOQXFv9sbdvtk+fX rgNw2YV7FFrfwqtYZLOoMvdVWODN/LvnnZtnu2jZ7smKDicT02FhqMHxr/fmEeAZYv V5TBQacG6XFc1uDnzuY9g66djqTTOLwXoU7fpzT3ZzKP2bpmXWW04ba8bMTG5plsIM XBPoAdJVkr1VVR99DSpzkPLvK3V6ASHOze3gAgZpxoIArFYZyoGGDYCgEhrl9UdPLm jtXA38azvMaZaPJn8u9dSLq2K59Yv+OE+PLBS1lDl313YI9QFIG8Tbrkn92idNehYn hfUiryATznPNg== Date: Thu, 4 Jan 2024 20:40:32 +0000 From: Simon Horman To: Wen Gu Cc: Markus Elfring , linux-s390@vger.kernel.org, netdev@vger.kernel.org, kernel-janitors@vger.kernel.org, "David S. Miller" , "D. Wythe" , Eric Dumazet , Jakub Kicinski , Jan Karcher , Paolo Abeni , Tony Lu , Wenjia Zhang , LKML Subject: Re: [0/2] net/smc: Adjustments for two function implementations Message-ID: <20240104204032.GN31813@kernel.org> References: <8ba404fd-7f41-44a9-9869-84f3af18fb46@web.de> <93033352-4b9c-bf52-1920-6ccf07926a21@linux.alibaba.com> <46fe66f7-dc3b-4863-96e8-7a855316e8bd@web.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jan 02, 2024 at 07:33:18PM +0800, Wen Gu wrote: > > > On 2024/1/2 16:51, Markus Elfring wrote: > > … > > > > A few update suggestions were taken into account > > > > from static source code analysis. > > … > > > >    Return directly after a failed kzalloc() in smc_fill_gid_list() > > > >    Improve exception handling in smc_llc_cli_add_link_invite() > > > > > > > >   net/smc/af_smc.c  |  2 +- > > > >   net/smc/smc_llc.c | 15 +++++++-------- > > > >   2 files changed, 8 insertions(+), 9 deletions(-) > > … > > > I see you want to fix the kfree(NULL) issues in these two patches. > > > > I propose to avoid redundant function calls at various source code places. > > > > > > > But I am wondering if this is necessary, since kfree() can handle NULL correctly. > > > > Would you prefer only required data processing in affected function implementations? > > > > Thank you Markus. I understood that you want to avoid redundant function calls. > > But it is not very attractive to me since the calls occur on low-frequency paths > or unlikely condition, resulting in limited performance loss and the current > kfree() usage is fine and common. So what is the benfit? > > I noticed that some other discussions are on-going. It seems like you are trying > to change other similiar places. Let's collect more opinions. > > https://lore.kernel.org/netdev/828bb442-29d0-4bb8-b90d-f200bdd4faf6@web.de/ > https://lore.kernel.org/netdev/90679f69-951c-47b3-b86f-75fd9fde3da3@web.de/ > https://lore.kernel.org/netdev/dc0a1c9d-ceca-473d-9ad5-89b59e6af2e7@web.de/ > https://lore.kernel.org/netdev/cde82080-c715-473c-97ac-6ef66bba6d64@web.de/ As as been explained to Markus many times recently, calling kfree(NULL) is not only perfectly fine, it is the preferred way of handling things. Markus, please stop posting patches of this nature to Netdev. -- pw-bot: rejected