On 11/12/15 08:16, Richard Weinberger wrote: > Am 11.12.2015 um 07:58 schrieb Anton Ivanov: >>>> 2. I cannot catch what is wrong with the current code in signal.c. When >>>> I read it, it should not produce re-entrancy. But it does. >>> Sorry for the delay. Until now I did not find the time to dig into that. >>> Did you find the offending code in signal.c? >> Yes. >> >> Unblock signals is logically incorrect - it will re-trigger an >> interrupts even if there is an interrupt in flight whose processing has >> not been finished. >> >> I tried several approaches both with the original poll() controller and >> with my epoll() based version, some show promise. >> >> I had to put it aside until next Friday as I have some stuff due at work >> so I cannot spare time to work on it until then. Once I get that out of >> the way I should be able to spare it a day or two which should be enough >> to finish it. >> >> Ditto for the UBD improvements. > One thing we have to consider is that's legit to have SIGIO nested.
Correct. That is considered :) Both when looking at poll() and epoll() However, it is not legit to have sigio on a specific fd nested. That is mostly safe for the poll() version, but will need to be accounted for in any surgery on the irq controller. A. > I'm currently investigating whether we use do_IRQ() correctly. > > Thanks, > //richard > ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
