From: Markus Elfring <Markus.Elfring@web.de>
To: Michael Kelley <mhklinux@outlook.com>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>,
Dexuan Cui <decui@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, "cocci@inria.fr" <cocci@inria.fr>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Drivers: hv: vmbus: One function call less in create_gpadl_header() after error detection
Date: Wed, 10 Jan 2024 11:58:12 +0100 [thread overview]
Message-ID: <82054a0a-72e5-45b2-8808-e411a9587406@web.de> (raw)
In-Reply-To: <SN6PR02MB4157AA51AD8AEBB24D0668B7D4692@SN6PR02MB4157.namprd02.prod.outlook.com>
>> The kfree() function was called in two cases by
>> the create_gpadl_header() function during error handling
>> even if the passed variable contained a null pointer.
>> This issue was detected by using the Coccinelle software.
>>
>> Thus use another label.
>
> Interestingly, there's a third case in this function where
> "goto nomem" is done, and in this case, msgbody is NULL.
> Does Coccinelle not complain about that case as well?
>
> As I'm sure you know, the code is correct as is, because kfree()
> checks for a NULL argument. So this is really an exercise in
> making Coccinelle happy. To me, the additional label is
> incremental complexity for someone to deal with when
> reading the code at some time in the future. So I'd vote for
> leaving the code as is. But it's not a big deal either way. I
> can see you've been cleaning up a lot of Coccinelle-reported
> issues across the kernel, most of which result in code
> simplifications. If leaving this unchanged causes you problems,
> then I won't object (though perhaps that 3rd "goto nomem"
> should be dealt with as well for consistency).
How do you think about the clarification approach
“Reconsidering kfree() calls for null pointers (with SmPL)”?
https://lore.kernel.org/cocci/6cbcf640-55e5-2f11-4a09-716fe681c0d2@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2023-03/msg00096.html
Regards,
Markus
next prev parent reply other threads:[~2024-01-10 10:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-26 19:09 [PATCH] Drivers: hv: vmbus: One function call less in create_gpadl_header() after error detection Markus Elfring
2024-01-10 5:41 ` Michael Kelley
2024-01-10 10:58 ` Markus Elfring [this message]
2024-01-10 16:15 ` Michael Kelley
2024-01-10 17:08 ` Markus Elfring
2024-01-10 17:53 ` Michael Kelley
2024-01-10 18:37 ` Dan Carpenter
2024-01-10 22:17 ` Michael Kelley
2024-01-11 7:04 ` Dan Carpenter
2024-01-11 14:35 ` Michael Kelley
2024-01-10 11:29 ` [PATCH] " Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82054a0a-72e5-45b2-8808-e411a9587406@web.de \
--to=markus.elfring@web.de \
--cc=cocci@inria.fr \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox