All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
To: linux-kernel@vger.kernel.org
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Russ Weight <russell.h.weight@intel.com>,
	Tianfei Zhang <tianfei.zhang@intel.com>,
	Shuah Khan <shuah@kernel.org>,
	Colin Ian King <colin.i.king@gmail.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-kselftest@vger.kernel.org, stable@vger.kernel.org,
	Dan Carpenter <error27@gmail.com>, Takashi Iwai <tiwai@suse.de>
Subject: Re: [RESEND PATCH v5 2/3] test_firmware: fix a memory leak with reqs buffer
Date: Fri, 12 May 2023 14:34:29 +0200	[thread overview]
Message-ID: <256bc822-ba20-c41a-1f3b-5b6aacead32e@alu.unizg.hr> (raw)
In-Reply-To: <20230509084746.48259-2-mirsad.todorovac@alu.unizg.hr>

Hi Dan,

On 5/9/23 10:47, Mirsad Goran Todorovac wrote:
> Dan Carpenter spotted that test_fw_config->reqs will be leaked if
> trigger_batched_requests_store() is called two or more times.
> The same appears with trigger_batched_requests_async_store().
> 
> This bug wasn't trigger by the tests, but observed by Dan's visual
> inspection of the code.
> 
> The recommended workaround was to return -EBUSY if test_fw_config->reqs
> is already allocated.
> 
> Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russ Weight <russell.h.weight@intel.com>
> Cc: Tianfei Zhang <tianfei.zhang@intel.com>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Colin Ian King <colin.i.king@gmail.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: linux-kselftest@vger.kernel.org
> Cc: stable@vger.kernel.org # v5.4
> Suggested-by: Dan Carpenter <error27@gmail.com>
> Suggested-by: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
> ---
>   lib/test_firmware.c | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/lib/test_firmware.c b/lib/test_firmware.c
> index 35417e0af3f4..91b232ed3161 100644
> --- a/lib/test_firmware.c
> +++ b/lib/test_firmware.c
> @@ -913,6 +913,11 @@ static ssize_t trigger_batched_requests_store(struct device *dev,
>   
>   	mutex_lock(&test_fw_mutex);
>   
> +	if (test_fw_config->reqs) {
> +		rc = -EBUSY;
> +		goto out_bail;
> +	}
> +
>   	test_fw_config->reqs =
>   		vzalloc(array3_size(sizeof(struct test_batched_req),
>   				    test_fw_config->num_requests, 2));
> @@ -1011,6 +1016,11 @@ ssize_t trigger_batched_requests_async_store(struct device *dev,
>   
>   	mutex_lock(&test_fw_mutex);
>   
> +	if (test_fw_config->reqs) {
> +		rc = -EBUSY;
> +		goto out_bail;
> +	}
> +
>   	test_fw_config->reqs =
>   		vzalloc(array3_size(sizeof(struct test_batched_req),
>   				    test_fw_config->num_requests, 2));

I was just thinking, since returning -EBUSY for the case of already allocated
test_fw_config->reqs was your suggestion and your idea, maybe it would be OK
to properly reflect that in Co-developed-by: or Signed-off-by: , but if I
understood well, the CoC requires that I am explicitly approved of those?

Thanks,
Mirsad

-- 
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu

System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia

"What’s this thing suddenly coming towards me very fast? Very very fast.
... I wonder if it will be friends with me?"

  reply	other threads:[~2023-05-12 12:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  8:47 [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking Mirsad Goran Todorovac
2023-05-09  8:47 ` [RESEND PATCH v5 2/3] test_firmware: fix a memory leak with reqs buffer Mirsad Goran Todorovac
2023-05-12 12:34   ` Mirsad Todorovac [this message]
2023-05-12 13:09     ` Dan Carpenter
2023-05-12 18:58       ` Mirsad Goran Todorovac
2023-05-18 15:20         ` Dan Carpenter
2023-05-18 18:31           ` Mirsad Goran Todorovac
2023-05-24  5:34           ` Luis Chamberlain
2023-05-26 19:21             ` Mirsad Goran Todorovac
2023-05-09  8:47 ` [RESEND PATCH v5 3/3] test_firmware: fix the memory leak of the allocated firmware buffer Mirsad Goran Todorovac

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=256bc822-ba20-c41a-1f3b-5b6aacead32e@alu.unizg.hr \
    --to=mirsad.todorovac@alu.unizg.hr \
    --cc=colin.i.king@gmail.com \
    --cc=error27@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=russell.h.weight@intel.com \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tianfei.zhang@intel.com \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.