On 22/02/2022 12:11, Johannes Berg wrote:
On Tue, 2022-02-22 at 10:57 +0000, anton.iva...@cambridgegreys.com
wrote:
From: Anton Ivanov <anton.iva...@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/
