Am 20.11.2015 3:08 nachm. schrieb Anton Ivanov <anton.iva...@kot-begemot.co.uk>: > > On 20/11/15 13:48, st...@nixia.no wrote: > > 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(). > > I see it too, but I have not figured out how to deal with it. > > > > And code inside bar can do > > set_signals() magic. > > Correct, which is to some extent our issue. > > > > > 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. > > That is what signal.c is trying to simulate - you have a mask for ALRM > (or VTALRM with the older timers) and SIGIO and a global on/off. > > What that fails to emulate, however, is that an IRQ is usually blocked > until it is fully serviced. This, depending on IRQ controller design may > block all IRQs, all lower priority IRQs or none. > > The current code in uml tries to block all while processing an IRQ, but > for some reason fails. > > I will submit a patch to put some ducktape over this for the time being, > we should understand what is the root cause.
I hope the change in arch/um/kernel/skas/MMU.c isn't the cause of all this trouble! I wanted to disable interrupt processing and so the forwarding of timer interrupts to the user space process when the user space is currently in a critical section of forking itself, and no signal handler is installed yet! > > 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
