[prev in list] [next in list] [prev in thread] [next in thread] 

List:       glibc-alpha
Subject:    Re: intr-msg / hurdsig looks broken, is my analysis correct?
From:       Samuel Thibault via Libc-alpha <libc-alpha () sourceware ! org>
Date:       2023-02-28 21:09:51
Message-ID: 20230228210951.6ifyk7cq4ztkfbxq () begin
[Download RAW message or body]

Sergey Bugaev, le mar. 28 févr. 2023 18:53:05 +0300, a ecrit:
> Really, why would it matter whether eip is after
> _hurd_intr_rpc_msg_about_to or not? What if it's 1 instruction before
> that? We skip the call, pretending it was interrupted, but does it
> really matter that we do that — can't we just admit that the signal
> arrived before the call, after all that's exactly how it would look if
> we catch the thread before it enters _hurd_intr_rpc_msg_about_to?

Yes, but we still need to know whether it was "about to" make an RPC,
to determine whether to interrupt it, or let the code flow until an
cancellation point.

> Any other code that would temporarily set esp to below the actual tip
> of the stack — no RPCing needs to be involved — would need similar
> special-casing in these two files.

That's not supposed to happen. Really it should have never be handled.

But properly supporting cancellation is a reason for the kludge.

> And so since 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0 has dropped the
> root cause of the kludge, _all of this code_ can be dropped too.
> 
> I will un-implement that and see whether that really works; in the
> meantime — does this make sense?

You'll most probably not easily meet the cases that matter: a
cancelation or interruption that is triggered right at the wrong time,
i.e. between the C check for cancellation etc., and the lcall.

Samuel
[prev in list] [next in list] [prev in thread] [next in thread]