I have found a regression in userspace behaviour after commit 67b164a871a
got backported into 4.19.306 as commit 19af0310c8767. The regression
can be fixed by backporting two additional commits, detailed below.
The regression can be reproduced with the following sequence:
echo some text > plain.txt
openssl enc -k mysecret -aes-256-cbc -in plain.txt -out cipher.txt -engine afalg
It fails intermittently with the message "error writing to file", but
this error is a bit misleading, the actual problem is that the kernel
returns -16 (EBUSY) on the encoding operation.
The EBUSY comes from the newly added in-flight check. This check is correct,
however it fails on 4.19 kernel, because it is missing two earlier commits:
f3c802a1f3001 crypto: algif_aead - Only wake up when ctx->more is zero
21dfbcd1f5cbf crypto: algif_aead - fix uninitialized ctx->init
I was able to cherry-pick those into 4.19.y, with just a minor conflict
in one case. With those applied, the openssl command no longer fails.
Similar fixes are likely needed in 5.4.y, however I did not test this.
No change is needed in 5.10 or newer, as the two commits are present.
Please add the two commits to 4.19.y (and probably also 5.4.y).
Thanks,
-Ralph
[CCing the stable team, as it looks like two prerequisite changes for a
patch already applied are missing in at least 4.19.y]
On 15.03.24 18:55, Ralph Siemsen wrote:
>
> I have found a regression in userspace behaviour after this patch was
> merged into the 4.19.y kernel. The fix seems to involve backporting a
> few more changes. Could you review details below and confirm if this is
> the right approach?
FWIW, developers are totally free to not care about stable and longterm
kernels series. Not sure if Herbert is among those developers, but it
might explain why there is no reply yet. That's why I CCed the stable
maintainers, strictly speaking they are responsible.
> On Tue, Nov 28, 2023 at 04:25:49PM +0800, Herbert Xu wrote:
>> Having multiple in-flight AIO requests results in unpredictable
>> output because they all share the same IV. Fix this by only allowing
>> one request at a time.
> [...]
> This change got backported on the 4.19 kernel in January:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…
>
> Since then, I am seeCiao, ing a regression in a simple openssl encoding test:
>
> openssl enc -k mysecret -aes-256-cbc -in plain.txt -out cipher.txt
> -engine afalg
>
> It fails intermittently with the message "error writing to file", but
> this error is a bit misleading, the actual problem is that the kernel
> returns -16 (EBUSY) on the encoding operation.
>
> This happens only in 4.19, and not under 5.10. The patch seems correct,
> however it seems we are missing a couple of other patches on 4.19:
>
> f3c802a1f3001 crypto: algif_aead - Only wake up when ctx->more is zero
> 21dfbcd1f5cbf crypto: algif_aead - fix uninitialized ctx->init
>
> I was able to cherry-pick those into 4.19.y, with just a minor conflict
> in one case. With those applied, the openssl command no longer fails.
Some feedback here from Herbert would of course be splendid, but maybe
your tests are all the stable team needs to pick those up for a future
4.19.y release.
> I suspect similar changes would be needed also in 5.4 kernel, however I
> neither checked that, nor have I run any tests on that version.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
RISC-V PLIC cannot "end-of-interrupt" (EOI) disabled interrupts, as
explained in the description of Interrupt Completion in the PLIC spec:
"The PLIC signals it has completed executing an interrupt handler by
writing the interrupt ID it received from the claim to the claim/complete
register. The PLIC does not check whether the completion ID is the same
as the last claim ID for that target. If the completion ID does not match
an interrupt source that *is currently enabled* for the target, the
completion is silently ignored."
Commit 69ea463021be ("irqchip/sifive-plic: Fixup EOI failed when masked")
ensured that EOI is successful by enabling interrupt first, before EOI.
Commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask
operations") removed the interrupt enabling code from the previous
commit, because it assumes that interrupt should already be enabled at the
point of EOI. However, this is incorrect: there is a window after a hart
claiming an interrupt and before irq_desc->lock getting acquired,
interrupt can be disabled during this window. Thus, EOI can be invoked
while the interrupt is disabled, effectively nullify this EOI. This
results in the interrupt never gets asserted again, and the device who
uses this interrupt appears frozen.
Make sure that interrupt is really enabled before EOI.
Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Nam Cao <namcao(a)linutronix.de>
---
v2:
- add unlikely() for optimization
- re-word commit message to make it clearer
drivers/irqchip/irq-sifive-plic.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
index e1484905b7bd..0a233e9d9607 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -148,7 +148,13 @@ static void plic_irq_eoi(struct irq_data *d)
{
struct plic_handler *handler = this_cpu_ptr(&plic_handlers);
- writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
+ if (unlikely(irqd_irq_disabled(d))) {
+ plic_toggle(handler, d->hwirq, 1);
+ writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
+ plic_toggle(handler, d->hwirq, 0);
+ } else {
+ writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM);
+ }
}
#ifdef CONFIG_SMP
--
2.39.2
syzbot reports a memory leak in pppoe_sendmsg in 6.6 and 6.1 stable
releases. The problem has been fixed by the following patch which can be
cleanly applied to the 6.6 and 6.1 branches.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller
Gavrilov Ilia (1):
pppoe: Fix memory leak in pppoe_sendmsg()
drivers/net/ppp/pppoe.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
--
2.39.2