Den 2015-11-20 13:50, skrev Anton Ivanov: > On 20/11/15 12:26, st...@nixia.no wrote: >>>> 4. While I can propose a brutal patch for signal.c which sets >>>> guards >>>> against reentrancy which works fine, I suggest we actually get to >>>> the >>>> bottom of this. Why the code in unblock_signals() does not guard >>>> correctly against that? >>> Thanks for hunting this issue. >>> I fear I'll have to grab my speleologist's hat to figure out why >>> UML >>> works this way. >>> Cc'ing Al, do you have an idea? >> In the few stack-traces that I have seen posted here, I could see >> multiple calls to unlocking of signals (with a signal occurred >> directly >> after). That probably should not happen. Do we count the number of >> timers of time we try to block/unblock signals and only actual >> perform >> the action when the counter reaches/leaves 0? >> >> if this series of calls happens: >> block() >> foo() >> block() >> bar() >> unblock() <- this should be a no-op >> foobar() >> unblock() <- first here the signals should be unblocked again > > Block/unblock are not counting the number of enable/disable at > present. > It is either on or off. > > Any unblock will immediately re-trigger all pending interrupts. > > Some of the errata patches I have out of investigating this do > exactly > that - change: > > block to flags = set_signals(0); bar() ; set_signal(flags); > > This, if nested should be a NOP. > > However, even after fixing all of them (and their corresponding > kernel > side counterparts), I still get reentrancy, so there is something > else > at play too.
Please, share a stack-trace if possible. As a side-note: The small issue with the code example above I can see is that what if flags should have change during bar(). And code inside bar can do set_signals() magic. I am not linux kernel ABI expert. To me, it seems to be a more safe to have a ABI that tracks each signal blocked mask individually, and have a ref-counted block-all/unblock-all call. This would be like how you normally program on a CPU. You have a interrupt controller that you setup (masks), and a master interrupt enable/disable flag. -- Stian ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
