>> 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
Stian
------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
