On Thu, 07 Mar 2024, Jakub Kicinski wrote:
> On Thu, 7 Mar 2024 15:59:29 +0000 Lee Jones wrote:
> > From: Jakub Kicinski <kuba@xxxxxxxxxx>
> >
> > [ Upstream commit e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb ]
> >
> > Similarly to previous commit, the submitting thread (recvmsg/sendmsg)
> > may exit as soon as the async crypto handler calls complete().
> > Reorder scheduling the work before calling complete().
> > This seems more logical in the first place, as it's
> > the inverse order of what the submitting thread will do.
> >
> > Reported-by: valis <sec@valis.email>
> > Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance")
> > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
> > Reviewed-by: Simon Horman <horms@xxxxxxxxxx>
> > Reviewed-by: Sabrina Dubroca <sd@xxxxxxxxxxxxxxx>
> > Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
> > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> > (cherry picked from commit 6db22d6c7a6dc914b12c0469b94eb639b6a8a146)
> > [Lee: Fixed merge-conflict in Stable branches linux-6.1.y and older]
> > Signed-off-by: Lee Jones <lee@xxxxxxxxxx>
>
> LG, thank you!
>
> The 5.15 / 5.10 / 5.4 fixes won't be effective, tho. I don't see
> commit aec7961916f3f9e88766 in the other LTS branches. Without that
> (it's still correct but) it doesn't fix the problem, because we still
> touch the context after releasing the reference (unlocking the spin
> lock).
No problem.
Should I accompany aec7961916f3 with this fix into the aforementioned
branches then? Would that then be effective?
--
Lee Jones [李琼斯]
