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;
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
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
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
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
linux-stable-mirror@lists.linaro.org