Jan,

On Fri, Oct 11, 2019 at 8:50 AM Jan Kiszka <jan.kis...@siemens.com> wrote:
> >          if (likely(p->coflags & __IPIPE_TRAP_E)) {
> >                  p->coflags |= __IPIPE_TRAP_R;
> >                  hard_local_irq_restore(flags);
> >                  data.exception = exception;
> >                  data.regs = regs;
> >                  ret = ipipe_trap_hook(&data);
> >                  flags = hard_local_irq_save();
> >                  p->coflags &= ~__IPIPE_TRAP_R;
> >          }
> >
> > Why do you restore interrupts before calling ipipe_trap_hook?
> > So depending in the saved state, IRQs could be enabled again?
> >
>
> This heavily depends on the type of exception. Some of them enter their
> low-level handler with interrupts off, and those will keep them off for
> ipipe_trap_hook. Others start with interrupts enabled (there are many
> "harmless" synchronous faults), and this is what we preserve here for
> the callback. Seems the description is out of sync though.

Yeah, the description indicates that ipipe guarantees that IRQs are off
but you leave them as-is and just disable them for a short time to deal with
p->coflags.

Thanks a lot for the clarification!

---
Thanks,
//richard

Reply via email to