On Mon, Sep 28, 2026 at 12:06:22PM +0200, Kirill A. Korinsky wrote:
> From 8636d1b7d6412861f72d8c9ebfe9064b3337e5c8 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Korinsky" <kirill@korins.ky>
> Date: Sun, 27 Sep 2026 12:57:24 +0200
> Subject: [PATCH 05/11] sys/qwz: wait for confirmed peer release
> 
> Wait for both an explicit peer-unmap event and the delete response
> before releasing a peer. This also covers a creation that timed out
> before its mapping event arrived.

All the other diffs are OK by me.

Only this one commit looks a bit strange, and I cannot understand
the reasoning behind it without more details.

I cannot tell what the first part of your log message is trying to say
with "Wait for both an explicit peer-unmap event and the delete response".
The code which unmaps and deletes a peer already handles both events.
How is the existing code broken?

Previously, the peer_mapped flag was used to track both map and unmap events,
for no particular reason other than that the same flag can be used for both.

Now you've added a dedicated unmapped flag to track unmap events separately,
but still report unmapping events to code which sleeps on &sc->peer_mapped.
Is this intentional? Is this what the following part of your log message is
referring to? "This also covers a creation that timed out before its mapping
event arrived."  What problem does this solve exactly? A timeout would rather
be handled via error codes returned from tsleep, wouldn't it?