* [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking
@ 2023-07-29 9:17 Mirsad Todorovac
2023-07-30 23:50 ` Luis Chamberlain
0 siblings, 1 reply; 6+ messages in thread
From: Mirsad Todorovac @ 2023-07-29 9:17 UTC (permalink / raw)
To: stable; +Cc: Luis Chamberlain, Greg Kroah-Hartman, Dan Carpenter
Dan Carpenter spotted a race condition in a couple of situations like
these in the test_firmware driver:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
u8 val;
int ret;
ret = kstrtou8(buf, 10, &val);
if (ret)
return ret;
mutex_lock(&test_fw_mutex);
*(u8 *)cfg = val;
mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
static ssize_t config_num_requests_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int rc;
mutex_lock(&test_fw_mutex);
if (test_fw_config->reqs) {
pr_err("Must call release_all_firmware prior to changing config\n");
rc = -EINVAL;
mutex_unlock(&test_fw_mutex);
goto out;
}
mutex_unlock(&test_fw_mutex);
rc = test_dev_config_update_u8(buf, count,
&test_fw_config->num_requests);
out:
return rc;
}
static ssize_t config_read_fw_idx_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
return test_dev_config_update_u8(buf, count,
&test_fw_config->read_fw_idx);
}
The function test_dev_config_update_u8() is called from both the locked
and the unlocked context, function config_num_requests_store() and
config_read_fw_idx_store() which can both be called asynchronously as
they are driver's methods, while test_dev_config_update_u8() and siblings
change their argument pointed to by u8 *cfg or similar pointer.
To avoid deadlock on test_fw_mutex, the lock is dropped before calling
test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8()
itself, but alas this creates a race condition.
Having two locks wouldn't assure a race-proof mutual exclusion.
This situation is best avoided by the introduction of a new, unlocked
function __test_dev_config_update_u8() which can be called from the locked
context and reducing test_dev_config_update_u8() to:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
int ret;
mutex_lock(&test_fw_mutex);
ret = __test_dev_config_update_u8(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
}
doing the locking and calling the unlocked primitive, which enables both
locked and unlocked versions without duplication of code.
The similar approach was applied to all functions called from the locked
and the unlocked context, which safely mitigates both deadlocks and race
conditions in the driver.
__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 thereof causing a race
condition.
The test_dev_config_update_bool(), test_dev_config_update_u8() and
test_dev_config_update_size_t() locked versions of the functions
are being called from driver methods without the unnecessary multiplying
of the locking and unlocking code for each method, and complicating
the code with saving of the return value across lock.
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: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
---
v5.1
resending to v5.4 stable branch verbatim according to Luis Chamberlain instruction
lib/test_firmware.c | 52 ++++++++++++++++++++++++++++++---------------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 05ed84c2fc4c..35417e0af3f4 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -353,16 +353,26 @@ static ssize_t config_test_show_str(char *dst,
return len;
}
-static int test_dev_config_update_bool(const char *buf, size_t size,
+static inline int __test_dev_config_update_bool(const char *buf, size_t size,
bool *cfg)
{
int ret;
- mutex_lock(&test_fw_mutex);
if (kstrtobool(buf, cfg) < 0)
ret = -EINVAL;
else
ret = size;
+
+ return ret;
+}
+
+static int test_dev_config_update_bool(const char *buf, size_t size,
+ bool *cfg)
+{
+ int ret;
+
+ mutex_lock(&test_fw_mutex);
+ ret = __test_dev_config_update_bool(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
@@ -373,7 +383,8 @@ static ssize_t test_dev_config_show_bool(char *buf, bool val)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
-static int test_dev_config_update_size_t(const char *buf,
+static int __test_dev_config_update_size_t(
+ const char *buf,
size_t size,
size_t *cfg)
{
@@ -384,9 +395,7 @@ static int test_dev_config_update_size_t(const char *buf,
if (ret)
return ret;
- mutex_lock(&test_fw_mutex);
*(size_t *)cfg = new;
- mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
@@ -402,7 +411,7 @@ static ssize_t test_dev_config_show_int(char *buf, int val)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
-static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
+static int __test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
u8 val;
int ret;
@@ -411,14 +420,23 @@ static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
if (ret)
return ret;
- mutex_lock(&test_fw_mutex);
*(u8 *)cfg = val;
- mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
+static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
+{
+ int ret;
+
+ mutex_lock(&test_fw_mutex);
+ ret = __test_dev_config_update_u8(buf, size, cfg);
+ mutex_unlock(&test_fw_mutex);
+
+ return ret;
+}
+
static ssize_t test_dev_config_show_u8(char *buf, u8 val)
{
return snprintf(buf, PAGE_SIZE, "%u\n", val);
@@ -471,10 +489,10 @@ static ssize_t config_num_requests_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_u8(buf, count,
- &test_fw_config->num_requests);
+ rc = __test_dev_config_update_u8(buf, count,
+ &test_fw_config->num_requests);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
@@ -518,10 +536,10 @@ static ssize_t config_buf_size_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_size_t(buf, count,
- &test_fw_config->buf_size);
+ rc = __test_dev_config_update_size_t(buf, count,
+ &test_fw_config->buf_size);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
@@ -548,10 +566,10 @@ static ssize_t config_file_offset_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_size_t(buf, count,
- &test_fw_config->file_offset);
+ rc = __test_dev_config_update_size_t(buf, count,
+ &test_fw_config->file_offset);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
--
2.30.2
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking
2023-07-29 9:17 [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking Mirsad Todorovac
@ 2023-07-30 23:50 ` Luis Chamberlain
2023-07-31 11:29 ` Mirsad Todorovac
0 siblings, 1 reply; 6+ messages in thread
From: Luis Chamberlain @ 2023-07-30 23:50 UTC (permalink / raw)
To: Mirsad Todorovac; +Cc: stable, Greg Kroah-Hartman, Dan Carpenter
On Sat, Jul 29, 2023 at 11:17:45AM +0200, Mirsad Todorovac wrote:
> ---
> v5.1
> resending to v5.4 stable branch verbatim according to Luis Chamberlain instruction
If this is a backport of an upstream patch you must mention the commit
ID at the top. After
For instance, here is a random commit from v5.15.y branch for stable:
bpf: Add selftests to cover packet access corner cases
commit b560b21f71eb4ef9dfc7c8ec1d0e4d7f9aa54b51 upstream.
<the upstream commit log>
If you make modifications to the patch to apply to v5.4.y which
otherwise would let the patch apply you need to specify that in
the commit log, you could do that after your signed-off-by, for
instance you can:
Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
[made some x, y and z changes to ensure it applies to v5.4.y]
If this is a new commit for a fix not yet merged on Linus tree
then your description quoted above does not make it clear.
Luis
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking
2023-07-30 23:50 ` Luis Chamberlain
@ 2023-07-31 11:29 ` Mirsad Todorovac
2023-07-31 11:33 ` Greg Kroah-Hartman
0 siblings, 1 reply; 6+ messages in thread
From: Mirsad Todorovac @ 2023-07-31 11:29 UTC (permalink / raw)
To: Luis Chamberlain; +Cc: stable, Greg Kroah-Hartman, Dan Carpenter
On 31.7.2023. 1:50, Luis Chamberlain wrote:
> On Sat, Jul 29, 2023 at 11:17:45AM +0200, Mirsad Todorovac wrote:
>> ---
>> v5.1
>> resending to v5.4 stable branch verbatim according to Luis Chamberlain instruction
>
> If this is a backport of an upstream patch you must mention the commit
> ID at the top. After
>
> For instance, here is a random commit from v5.15.y branch for stable:
>
> bpf: Add selftests to cover packet access corner cases
>
> commit b560b21f71eb4ef9dfc7c8ec1d0e4d7f9aa54b51 upstream.
>
> <the upstream commit log>
Hello,
I have reviewed the module again and I found no new weaknesses, so it is only
a backport from the same commit in torvalds, master, 6.4, 6.1, 5.15 and
5.10 trees/branches.
This is a bit confusing and I am doing this for the first time. In fact, there
was probably a glitch in the patchwork because the comment to the
Cc: stable@vger.kernel.org said "# 5.4" ...
However, I do not know which commit ID to refer to:
torvalds 4acfe3dfde685a5a9eaec5555351918e2d7266a1
master 4acfe3dfde685a5a9eaec5555351918e2d7266a1
6.4 4acfe3dfde685a5a9eaec5555351918e2d7266a1
6.1 6111f0add6ffc93612d4abe9fec002319102b1c0
5.15 bfb0b366e8ec23d9a9851898d81c829166b8c17b
5.10 af36f35074b10dda0516cfc63d209accd4ef4d17
Each of the branches 6.4, 6.1, 5.15 and 5.10 appear to have a different commit
ID.
Probably the right commit ID should be:
test_firmware: prevent race conditions by a correct implementation of locking
commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 master
Will the patchwork figure this out or should I RESEND with a clean slate?
But first I would appreciate a confirmation that I did it right this time ...
Thanks,
Mirsad
> If you make modifications to the patch to apply to v5.4.y which
> otherwise would let the patch apply you need to specify that in
> the commit log, you could do that after your signed-off-by, for
> instance you can:
>
> Signed-off-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
> [made some x, y and z changes to ensure it applies to v5.4.y]
>
> If this is a new commit for a fix not yet merged on Linus tree
> then your description quoted above does not make it clear.
>
> Luis
--
Mirsad Todorovac
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking
2023-07-31 11:29 ` Mirsad Todorovac
@ 2023-07-31 11:33 ` Greg Kroah-Hartman
2023-07-31 12:32 ` Mirsad Todorovac
0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2023-07-31 11:33 UTC (permalink / raw)
To: Mirsad Todorovac; +Cc: Luis Chamberlain, stable, Dan Carpenter
On Mon, Jul 31, 2023 at 01:29:19PM +0200, Mirsad Todorovac wrote:
> On 31.7.2023. 1:50, Luis Chamberlain wrote:
> > On Sat, Jul 29, 2023 at 11:17:45AM +0200, Mirsad Todorovac wrote:
> > > ---
> > > v5.1
> > > resending to v5.4 stable branch verbatim according to Luis Chamberlain instruction
> >
> > If this is a backport of an upstream patch you must mention the commit
> > ID at the top. After
> >
> > For instance, here is a random commit from v5.15.y branch for stable:
> >
> > bpf: Add selftests to cover packet access corner cases
> > commit b560b21f71eb4ef9dfc7c8ec1d0e4d7f9aa54b51 upstream.
> >
> > <the upstream commit log>
>
> Hello,
>
> I have reviewed the module again and I found no new weaknesses, so it is only
> a backport from the same commit in torvalds, master, 6.4, 6.1, 5.15 and
> 5.10 trees/branches.
>
> This is a bit confusing and I am doing this for the first time. In fact, there
> was probably a glitch in the patchwork because the comment to the
> Cc: stable@vger.kernel.org said "# 5.4" ...
>
> However, I do not know which commit ID to refer to:
>
> torvalds 4acfe3dfde685a5a9eaec5555351918e2d7266a1
> master 4acfe3dfde685a5a9eaec5555351918e2d7266a1
> 6.4 4acfe3dfde685a5a9eaec5555351918e2d7266a1
> 6.1 6111f0add6ffc93612d4abe9fec002319102b1c0
> 5.15 bfb0b366e8ec23d9a9851898d81c829166b8c17b
> 5.10 af36f35074b10dda0516cfc63d209accd4ef4d17
>
> Each of the branches 6.4, 6.1, 5.15 and 5.10 appear to have a different commit
> ID.
>
> Probably the right commit ID should be:
>
> test_firmware: prevent race conditions by a correct implementation of locking
>
> commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 master
>
> Will the patchwork figure this out or should I RESEND with a clean slate?
>
> But first I would appreciate a confirmation that I did it right this time ...
I don't understand at all what you are trying to do here.
Is this a patch for Linus's tree? If so, great, let's apply it there.
Is this a patch for the stable kernel(s)? If so, great, what is the git
id in Linus's tree and what stable kernel(s) should it be applied to?
That's all we need to know and right now, I have no idea...
confused,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking
2023-07-31 11:33 ` Greg Kroah-Hartman
@ 2023-07-31 12:32 ` Mirsad Todorovac
0 siblings, 0 replies; 6+ messages in thread
From: Mirsad Todorovac @ 2023-07-31 12:32 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Luis Chamberlain, stable, Dan Carpenter
On 31.7.2023. 13:33, Greg Kroah-Hartman wrote:
> On Mon, Jul 31, 2023 at 01:29:19PM +0200, Mirsad Todorovac wrote:
>> On 31.7.2023. 1:50, Luis Chamberlain wrote:
>>> On Sat, Jul 29, 2023 at 11:17:45AM +0200, Mirsad Todorovac wrote:
>>>> ---
>>>> v5.1
>>>> resending to v5.4 stable branch verbatim according to Luis Chamberlain instruction
>>>
>>> If this is a backport of an upstream patch you must mention the commit
>>> ID at the top. After
>>>
>>> For instance, here is a random commit from v5.15.y branch for stable:
>>>
>>> bpf: Add selftests to cover packet access corner cases
>>> commit b560b21f71eb4ef9dfc7c8ec1d0e4d7f9aa54b51 upstream.
>>>
>>> <the upstream commit log>
>>
>> Hello,
>>
>> I have reviewed the module again and I found no new weaknesses, so it is only
>> a backport from the same commit in torvalds, master, 6.4, 6.1, 5.15 and
>> 5.10 trees/branches.
>>
>> This is a bit confusing and I am doing this for the first time. In fact, there
>> was probably a glitch in the patchwork because the comment to the
>> Cc: stable@vger.kernel.org said "# 5.4" ...
>>
>> However, I do not know which commit ID to refer to:
>>
>> torvalds 4acfe3dfde685a5a9eaec5555351918e2d7266a1
>> master 4acfe3dfde685a5a9eaec5555351918e2d7266a1
>> 6.4 4acfe3dfde685a5a9eaec5555351918e2d7266a1
>> 6.1 6111f0add6ffc93612d4abe9fec002319102b1c0
>> 5.15 bfb0b366e8ec23d9a9851898d81c829166b8c17b
>> 5.10 af36f35074b10dda0516cfc63d209accd4ef4d17
>>
>> Each of the branches 6.4, 6.1, 5.15 and 5.10 appear to have a different commit
>> ID.
>>
>> Probably the right commit ID should be:
>>
>> test_firmware: prevent race conditions by a correct implementation of locking
>>
>> commit 4acfe3dfde685a5a9eaec5555351918e2d7266a1 master
>>
>> Will the patchwork figure this out or should I RESEND with a clean slate?
>>
>> But first I would appreciate a confirmation that I did it right this time ...
>
> I don't understand at all what you are trying to do here.
>
> Is this a patch for Linus's tree? If so, great, let's apply it there.
>
> Is this a patch for the stable kernel(s)? If so, great, what is the git
> id in Linus's tree and what stable kernel(s) should it be applied to?
>
> That's all we need to know and right now, I have no idea...
>
> confused,
>
> greg k-h
Hi, Mr. Greg,
PLEASE NOTE!
I've just checked the diff against the 5.4 stable branch, and simply applying it won't
suffice, because it fails, so I need to manually backport the 5.10 commit to the 5.4 branch.
This is the job for the patch developer, and I would have done it earlier if I was aware
that the patch didn't apply to the 5.4 branch out-of-the-box. Rather naively I assumed
that the patch will apply automagically to 5.4 as it does to 5.10+. As they say, assumption
is the mother of all screwups.
Apologies for the confusion and your lost time.
* * *
The problem is that the patch was meant to be applied to 5.10 onwards, but 5.4 branch omitted it.
The patch is already in the torvalds tree and stable master, 6.4, 6.1, 5.15 and 5.10.
I wanted to see why the 5.4 included only two out of series of three patches for test_firmware:
2023-05-31 48e156023059e57a8fc68b498439832f7600ffff test_firmware: fix the memory leak of the allocated firmware buffer
2023-05-31 be37bed754ed90b2655382f93f9724b3c1aae847 test_firmware: fix a memory leak with reqs buffer
2023-05-31 4acfe3dfde685a5a9eaec5555351918e2d7266a1 test_firmware: prevent race conditions by a correct implementation of locking
So, the last patch didn't propagate to 5.4 stable branch.
Now we know why exactly.
From the pragmatic point of view, it would suffice to apply the commit
"4acfe3dfde685a5a9eaec5555351918e2d7266a1 test_firmware: prevent race conditions by a correct implementation of locking"
to the 5.4 stable branch.
Kind regards,
Mirsad Todorovac
--
Mirsad Todorovac
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking
@ 2023-05-09 8:47 Mirsad Goran Todorovac
0 siblings, 0 replies; 6+ messages in thread
From: Mirsad Goran Todorovac @ 2023-05-09 8:47 UTC (permalink / raw)
To: Mirsad Goran Todorovac, linux-kernel
Cc: Luis Chamberlain, Greg Kroah-Hartman, Russ Weight, Takashi Iwai,
Tianfei Zhang, Shuah Khan, Colin Ian King, Randy Dunlap,
linux-kselftest, stable, Dan Carpenter
Dan Carpenter spotted a race condition in a couple of situations like
these in the test_firmware driver:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
u8 val;
int ret;
ret = kstrtou8(buf, 10, &val);
if (ret)
return ret;
mutex_lock(&test_fw_mutex);
*(u8 *)cfg = val;
mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
static ssize_t config_num_requests_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
int rc;
mutex_lock(&test_fw_mutex);
if (test_fw_config->reqs) {
pr_err("Must call release_all_firmware prior to changing config\n");
rc = -EINVAL;
mutex_unlock(&test_fw_mutex);
goto out;
}
mutex_unlock(&test_fw_mutex);
rc = test_dev_config_update_u8(buf, count,
&test_fw_config->num_requests);
out:
return rc;
}
static ssize_t config_read_fw_idx_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
return test_dev_config_update_u8(buf, count,
&test_fw_config->read_fw_idx);
}
The function test_dev_config_update_u8() is called from both the locked
and the unlocked context, function config_num_requests_store() and
config_read_fw_idx_store() which can both be called asynchronously as
they are driver's methods, while test_dev_config_update_u8() and siblings
change their argument pointed to by u8 *cfg or similar pointer.
To avoid deadlock on test_fw_mutex, the lock is dropped before calling
test_dev_config_update_u8() and re-acquired within test_dev_config_update_u8()
itself, but alas this creates a race condition.
Having two locks wouldn't assure a race-proof mutual exclusion.
This situation is best avoided by the introduction of a new, unlocked
function __test_dev_config_update_u8() which can be called from the locked
context and reducing test_dev_config_update_u8() to:
static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
int ret;
mutex_lock(&test_fw_mutex);
ret = __test_dev_config_update_u8(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
}
doing the locking and calling the unlocked primitive, which enables both
locked and unlocked versions without duplication of code.
The similar approach was applied to all functions called from the locked
and the unlocked context, which safely mitigates both deadlocks and race
conditions in the driver.
__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 thereof causing a race
condition.
The test_dev_config_update_bool(), test_dev_config_update_u8() and
test_dev_config_update_size_t() locked versions of the functions
are being called from driver methods without the unnecessary multiplying
of the locking and unlocking code for each method, and complicating
the code with saving of the return value across lock.
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: Takashi Iwai <tiwai@suse.de>
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>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
---
lib/test_firmware.c | 52 ++++++++++++++++++++++++++++++---------------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 05ed84c2fc4c..35417e0af3f4 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -353,16 +353,26 @@ static ssize_t config_test_show_str(char *dst,
return len;
}
-static int test_dev_config_update_bool(const char *buf, size_t size,
+static inline int __test_dev_config_update_bool(const char *buf, size_t size,
bool *cfg)
{
int ret;
- mutex_lock(&test_fw_mutex);
if (kstrtobool(buf, cfg) < 0)
ret = -EINVAL;
else
ret = size;
+
+ return ret;
+}
+
+static int test_dev_config_update_bool(const char *buf, size_t size,
+ bool *cfg)
+{
+ int ret;
+
+ mutex_lock(&test_fw_mutex);
+ ret = __test_dev_config_update_bool(buf, size, cfg);
mutex_unlock(&test_fw_mutex);
return ret;
@@ -373,7 +383,8 @@ static ssize_t test_dev_config_show_bool(char *buf, bool val)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
-static int test_dev_config_update_size_t(const char *buf,
+static int __test_dev_config_update_size_t(
+ const char *buf,
size_t size,
size_t *cfg)
{
@@ -384,9 +395,7 @@ static int test_dev_config_update_size_t(const char *buf,
if (ret)
return ret;
- mutex_lock(&test_fw_mutex);
*(size_t *)cfg = new;
- mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
@@ -402,7 +411,7 @@ static ssize_t test_dev_config_show_int(char *buf, int val)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
-static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
+static int __test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
{
u8 val;
int ret;
@@ -411,14 +420,23 @@ static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
if (ret)
return ret;
- mutex_lock(&test_fw_mutex);
*(u8 *)cfg = val;
- mutex_unlock(&test_fw_mutex);
/* Always return full write size even if we didn't consume all */
return size;
}
+static int test_dev_config_update_u8(const char *buf, size_t size, u8 *cfg)
+{
+ int ret;
+
+ mutex_lock(&test_fw_mutex);
+ ret = __test_dev_config_update_u8(buf, size, cfg);
+ mutex_unlock(&test_fw_mutex);
+
+ return ret;
+}
+
static ssize_t test_dev_config_show_u8(char *buf, u8 val)
{
return snprintf(buf, PAGE_SIZE, "%u\n", val);
@@ -471,10 +489,10 @@ static ssize_t config_num_requests_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_u8(buf, count,
- &test_fw_config->num_requests);
+ rc = __test_dev_config_update_u8(buf, count,
+ &test_fw_config->num_requests);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
@@ -518,10 +536,10 @@ static ssize_t config_buf_size_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_size_t(buf, count,
- &test_fw_config->buf_size);
+ rc = __test_dev_config_update_size_t(buf, count,
+ &test_fw_config->buf_size);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
@@ -548,10 +566,10 @@ static ssize_t config_file_offset_store(struct device *dev,
mutex_unlock(&test_fw_mutex);
goto out;
}
- mutex_unlock(&test_fw_mutex);
- rc = test_dev_config_update_size_t(buf, count,
- &test_fw_config->file_offset);
+ rc = __test_dev_config_update_size_t(buf, count,
+ &test_fw_config->file_offset);
+ mutex_unlock(&test_fw_mutex);
out:
return rc;
--
2.30.2
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-07-31 12:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-29 9:17 [RESEND PATCH v5 1/3] test_firmware: prevent race conditions by a correct implementation of locking Mirsad Todorovac
2023-07-30 23:50 ` Luis Chamberlain
2023-07-31 11:29 ` Mirsad Todorovac
2023-07-31 11:33 ` Greg Kroah-Hartman
2023-07-31 12:32 ` Mirsad Todorovac
-- strict thread matches above, loose matches on Subject: below --
2023-05-09 8:47 Mirsad Goran Todorovac
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox