[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023052847-festival-moistness-9a14@gregkh>
Date: Sun, 28 May 2023 10:00:14 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Prathu Baronia <prathubaronia2011@...il.com>
Cc: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
"Fabio M. De Francesco" <fmdefrancesco@...il.com>,
Khadija Kamran <kamrankhadijadj@...il.com>,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
dan.carpenter@...aro.org, error27@...il.com, lkp@...el.com,
oe-kbuild-all@...ts.linux.dev, oe-kbuild@...ts.linux.dev
Subject: Re: [PATCH v4 2/3] axis-fifo: use devm_kasprintf() for allocating
formatted strings
On Sat, May 27, 2023 at 05:20:59PM +0530, Prathu Baronia wrote:
> In various places, string buffers of a fixed size are allocated, and
> filled using snprintf() with the same fixed size, which is error-prone.
>
> Replace this by calling devm_kasprintf() instead, which always uses the
> appropriate size.
>
> Signed-off-by: Prathu Baronia <prathubaronia2011@...il.com>
> ---
> drivers/staging/axis-fifo/axis-fifo.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/axis-fifo/axis-fifo.c b/drivers/staging/axis-fifo/axis-fifo.c
> index 271cab805cad..d71bdc6dd961 100644
> --- a/drivers/staging/axis-fifo/axis-fifo.c
> +++ b/drivers/staging/axis-fifo/axis-fifo.c
> @@ -816,10 +816,6 @@ static int axis_fifo_probe(struct platform_device *pdev)
> * ----------------------------
> */
>
> - device_name = devm_kzalloc(dev, 32, GFP_KERNEL);
> - if (!device_name)
> - return -ENOMEM;
> -
> /* allocate device wrapper memory */
> fifo = devm_kzalloc(dev, sizeof(*fifo), GFP_KERNEL);
> if (!fifo)
> @@ -857,7 +853,11 @@ static int axis_fifo_probe(struct platform_device *pdev)
> dev_dbg(fifo->dt_device, "remapped memory to 0x%p\n", fifo->base_addr);
>
> /* create unique device name */
> - snprintf(device_name, 32, "%s_%pa", DRIVER_NAME, &r_mem->start);
> + device_name = devm_kasprintf(dev, GFP_KERNEL, "%s_%pa", DRIVER_NAME, &r_mem->start);
we should not be using a kernel address as a device name, please fix
this up to just use a unique number instead.
thanks,
greg k-h
Powered by blists - more mailing lists