[PATCH] um: Fix uml_mconsole stop/go

[Anton Ivanov]

On 22/02/2022 12:11, Johannes Berg wrote:
> On Tue, 2022-02-22 at 10:57 +0000, anton.ivanov at cambridgegreys.com
> wrote:
>> From: Anton Ivanov <anton.ivanov at cambridgegreys.com>
>>
>> Moving to an EPOLL based IRQ controller broke uml_mconsole stop/go
>> commands. This fixes it and restores stop/go functionality.
>>
>> Fixes: ff6a17989c08b0bb0fd490cc500b084581b3a9b9 Epoll based IRQ controller
> The right format would be
>
> Fixes: ff6a17989c08 ("Epoll based IRQ controller")

Ack, will resubmit shortly.

>
> Don't think I can comment on the patch itself, sorry.

The old poll controller had all IO IRQs shared and disabled IRQ processing while in the IRQ loop. Thus a while(;;) in the IRQ loop combined with a blocking read was an effective way to stop processing.

That is no longer the case.

1. While individual IRQs are not reentrant (there is a check for that in the IRQ handler), other IRQs will be processed and each FD is allocated a separate one. So looping inside one will not stop the kernel. It will still handle timer IRQs and other IO.

2. In the old controller disable_fd() was the reentrance guard. It removed the fd from the poll set so that it is not triggered again until the IRQ is handled. It was used everywhere in the beginning of each handler (followed by re-enable at IRQ exit). It has different semantics, cost and should not be used without need in the epoll case. In fact, I removed it throughout, but somehow missed the mconsole. Still having it was a bug.

As we do not have any means to shut-off the IRQs in the IRQ controller itself, the easiest way to stop them is to kill signals - as per the patch.

>
> johannes
>
-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/