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@xxxxxxxxxxxxxxx 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
