mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>,
	Scott Branden <sbranden@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Russ Weight <russell.h.weight@intel.com>,
	linux-kernel@vger.kernel.org,
	Tianfei zhang <tianfei.zhang@intel.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Zhengchao Shao <shaozhengchao@huawei.com>,
	Colin Ian King <colin.i.king@gmail.com>,
	Takashi Iwai <tiwai@suse.de>, Kees Cook <keescook@chromium.org>,
	Dan Carpenter <error27@gmail.com>,
	Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Subject: Re: [PATCH RESEND v4 1/1] test_firmware: fix some memory leaks and racing conditions
Date: Tue, 25 Apr 2023 11:27:30 -0700	[thread overview]
Message-ID: <ZEgbkoSjHcVLcCcp@bombadil.infradead.org> (raw)
In-Reply-To: <20230421185205.28743-1-mirsad.todorovac@alu.unizg.hr>

On Fri, Apr 21, 2023 at 08:52:06PM +0200, Mirsad Goran Todorovac wrote:
> Some functions were called both from locked and unlocked context, so
> the lock was dropped prematurely, introducing a race condition when
> deadlock was avoided.
> 
> Having two locks wouldn't assure a race-proof mutual exclusion.
> 
> __test_dev_config_update_bool(), __test_dev_config_update_u8() and
> __test_dev_config_update_size_t() unlocked versions of the functions
> were introduced to be called from the locked contexts as a workaround
> without releasing the main driver's lock and causing a race condition.
> 
> This should guarantee mutual exclusion and prevent any race conditions.
> 
> Locked versions simply allow for mutual exclusion and call the unlocked
> counterparts, to avoid duplication of code.
> 
> trigger_batched_requests_store() and trigger_batched_requests_async_store()
> now return -EBUSY if called with test_fw_config->reqs already allocated,
> so the memory leak is prevented.
> 
> The same functions now keep track of the allocated buf for firmware in
> req->fw_buf as release_firmware() will not deallocate this storage for us.
> 
> Additionally, in __test_release_all_firmware(), req->fw_buf is released
> before calling release_firmware(req->fw),
> foreach test_fw_config->reqs[i], i = 0 .. test_fw_config->num_requests-1
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
> Cc: Luis Chamberlain <mcgrof@kernel.org> 
> Cc: Russ Weight <russell.h.weight@intel.com> 
> Cc: Tianfei zhang <tianfei.zhang@intel.com> 
> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> 
> Cc: Zhengchao Shao <shaozhengchao@huawei.com> 
> Cc: Colin Ian King <colin.i.king@gmail.com> 
> Cc: linux-kernel@vger.kernel.org 
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Scott Branden <sbranden@broadcom.com>
> Cc: Luis R. Rodriguez <mcgrof@kernel.org>
> Suggested-by: Dan Carpenter <error27@gmail.com>
> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>

Mirad, thanks for this work, good stuff! So the patch just needs to be
adjust with:

Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf"
Cc: stable@vger.kernel.org # v5.4

Then, can you split the patch in two, one which fixes the memory leaks
and another that deals with the mutexes. The second patch might be a fix
for the original code but I can't tell until I see the changes split out.

The commit log should account for the memory leak and be clear how it
happens. The other commit log for the second patch should clarify what
it fixes and why as well.

  Luis

  reply	other threads:[~2023-04-25 18:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21 18:52 Mirsad Goran Todorovac
2023-04-25 18:27 ` Luis Chamberlain [this message]
2023-07-27  6:16   ` Mirsad Todorovac
2023-07-27 15:36     ` Luis Chamberlain
2023-07-27 22:14       ` Mirsad Todorovac
2023-07-27 22:45         ` Luis Chamberlain

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=ZEgbkoSjHcVLcCcp@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=colin.i.king@gmail.com \
    --cc=error27@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mirsad.todorovac@alu.unizg.hr \
    --cc=russell.h.weight@intel.com \
    --cc=sbranden@broadcom.com \
    --cc=shaozhengchao@huawei.com \
    --cc=tianfei.zhang@intel.com \
    --cc=tiwai@suse.de \
    --cc=vincenzopalazzodev@gmail.com \
    /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

all inboxes | Powered by JetHome®