[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20240102113117.b2b4ffa2998eb51b674b0304@linux-foundation.org>
Date: Tue, 2 Jan 2024 11:31:17 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Markus Elfring <Markus.Elfring@....de>
Cc: kernel-janitors@...r.kernel.org, Ahelenia ZiemiaĆska
<nabijaczleweli@...ijaczleweli.xyz>, Li kunyu <kunyu@...china.com>, Michal
Hocko <mhocko@...e.com>, Sebastian Reichel
<sebastian.reichel@...labora.com>, Suren Baghdasaryan <surenb@...gle.com>,
Zhang Zhengming <zhang.zhengming@....com>, Zhou Kete <zhou.kete@....com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel: relay: Improve exception handling in
relay_create_buf()
On Sun, 31 Dec 2023 10:38:10 +0100 Markus Elfring <Markus.Elfring@....de> wrote:
> From: Markus Elfring <elfring@...rs.sourceforge.net>
> Date: Sun, 31 Dec 2023 10:26:25 +0100
>
> The kfree() function was called in one case by
> the relay_create_buf() function during error handling
> even if the passed data structure member contained a null pointer.
> This issue was detected by using the Coccinelle software.
>
> Thus use another label.
>
> ...
>
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -161,14 +161,15 @@ static struct rchan_buf *relay_create_buf(struct rchan *chan)
>
> buf->start = relay_alloc_buf(buf, &chan->alloc_size);
> if (!buf->start)
> - goto free_buf;
> + goto free_padding;
>
> buf->chan = chan;
> kref_get(&buf->chan->kref);
> return buf;
>
> -free_buf:
> +free_padding:
> kfree(buf->padding);
> +free_buf:
> kfree(buf);
> return NULL;
> }
kfree(NULL) is an OK thing to do, and is a well-known pattern. Can we
arrange for Coccinelle to understand this?
Powered by blists - more mailing lists