Re: [RFC PATCH glibc 25/34] hurd: Improve reply port handling when exiting signal handlers

[Sergey Bugaev]

On Tue, Apr 11, 2023 at 1:03 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> I tend to be very cautious with reply port reuse since it can confuse
> servers a lot when e.g. interrupted, so it's generally safer not to try
> to reuse them.

Huh? Confuse how?

For one thing, the servers are unable to even tell if two send-once
rights point to the same port (which is actually something that I'd
very much like to change, since it would greatly benefit rpctrace, but
that's a topic that deserves its own wall-of-text email). The servers
can still notice if their send-once right dies though.

If a call has been interrupted and we have not received a reply (EINTR
or not), we surely must destroy the reply port used, if only for
security reasons (so a malicious server won't be able to inject a fake
reply to some other RPC we make later). But I don't see a reason to
destroy the *current* reply port, the one used during signal handling,
which we're longjumping out of. On the other hand it doesn't hurt much
either, and signal handling is a slow path anyway, so we may just play
it safe.

Sergey