• Johannes Berg's avatar
    um: time-travel/signals: fix ndelay() in interrupt · d6b399a0
    Johannes Berg authored
    We should be able to ndelay() from any context, even from an
    interrupt context! However, this is broken (not functionally,
    but locking-wise) in time-travel because we'll get into the
    time-travel code and enable interrupts to handle messages on
    other time-travel aware subsystems (only virtio for now).
    
    Luckily, I've already reworked the time-travel aware signal
    (interrupt) delivery for suspend/resume to have a time travel
    handler, which runs directly in the context of the signal and
    not from the Linux interrupt.
    
    In order to fix this time-travel issue then, we need to do a
    few things:
    
     1) rework the signal handling code to call time-travel handlers
        (only) if interrupts are disabled but signals aren't blocked,
        instead of marking it only pending there. This is needed to
        not deadlock other communication.
     2) rework time-travel to not enable interrupts while it's
        waiting for a message;
     3) rework time-travel to not (just) disable interrupts but
        rather block signals at a lower level while it needs them
        disabled for communicating with the controller.
    
    Finally, since now we can actually spend even virtual time
    in interrupts-disabled sections, the delay warning when we
    deliver a time-travel delayed interrupt is no longer valid,
    things can (and should) now get delayed.
    Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
    d6b399a0
time.c 22.4 KB