Hi all, I have looked through this and I still have not figured it out completely. Moving from the old poll controller to the new epoll one triggers deep recursive invocations of the interrupt handlers. I still do not understand why it does it so I will park it for now and come back to it next week.
I did, however, find a number of small issues. Namely, various patches and fixes over the years have used calls to block/unblock signals and block/unblock irqs in a few places where these can create a recursion race (even with the old controller). If I understand os-Linux/irq.c correctly, block/unblock in UML does not block or unblock the signals. It blocks/unblocks the processing of them and unblock can (and will) result in the immediate processing any pending signals. So in most places, that should not be block/unblock (and respectively local_irq_enable/local_irq_disable which invoke that). It should be save+block and restore. Otherwise you recurse by invoking the IRQ handler the moment you unblock_signals(). Additionally, if you want just to wait and be interrupted by a signal, you do not need to enable/disable IRQs - signals are always received at present. If I understand the situation correctly, irq on/off only changes if they are processed or not. I am going to roll my tree back to the timer patch now and go through the ones I found so far one by one and submit them separately. Once that is out of the way we can look again at the epoll controller patch. It has potential, but it makes all gremlins come out of the woodwork so we might as well get the gremlins out of the way first. [snip] A. ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
