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. In any case, the errata should be fixed, I will sort it out, organize it into a patch set and send it out by Monday. A. > > > > Stian > > ------------------------------------------------------------------------------ > _______________________________________________ > User-mode-linux-devel mailing list > User-mode-linux-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel > ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
