Re: intr-msg / hurdsig looks broken, is my analysis correct?

[Samuel Thibault]

Hello,

Sergey Bugaev, le lun. 27 févr. 2023 16:39:19 +0300, a ecrit:
> Does my reasoning make sense? Am I missing anything? Was this a simple
> oversight of 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0,

It most probably was, yes.

> Are there any tests for this at all?

It's very difficult to test since it's all about race conditions, with
the interruption happening exactly at the wrong moment.

> As for fixing this:
> - we should drop the ecx kludge indeed, meaning, remove everything
> related to ecx from all of these files

Actually, we probably need a kludge, precisely because of the pushes.

> - there should be an explicit way for hurdsig.c to tell INTR_MSG_TRAP
> to not do the syscall.

Yes, but as much as you'll try, you'll still have a very tiny window
(1-instruction at least) between the moment you check, and the moment
you run lcall. That's why the whole thing. It's simpler to just reset to
a known state.

We can use ecx for that, by saving esp to ecx before the pushes.
If interruption happens between the start of the pushes and the lcall,
we can easily revert the pushes by copying ecx to esp (i.e. without
having to care exactly how many pushes did get achieved), and directly
branch to _hurd_intr_rpc_msg_sp_restored.

> - INTR_MSG_BACK_OUT will become empty; we can still leave it in, or
> drop it entirely

BTW, I don't thing the else part of it is needed any more.

Samuel