Re: [uml-devel] IRQ handler reentrancy

[Anton Ivanov <anton.ivanov@kot-begemot.co.uk>]

On 20/11/15 12:26, stian@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