Re: [uml-devel] IRQ handler reentrancy

[stian@nixia.no]

>> 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