[Bug 60524] New: server: Keep an in-process mutex that a process closed while still using it

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60524

            Bug ID: 60524
           Summary: server: Keep an in-process mutex that a process closed
                    while still using it
           Product: Wine
           Version: 11.20
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wineserver
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

Follow-up to https://bugs.winehq.org/show_bug.cgi?id=60417 . A mutex that is
unowned when its last handle is closed is destroyed on the server and
forgotten, but a wait that was already pending on it holds a duplicate of its
fd and can still acquire it, for instance a wait-all whose other objects are
signaled later. If that thread then dies, nothing sends `NTSYNC_IOC_MUTEX_KILL`
to the mutex, so it is never abandoned and another pending waiter blocks
forever. Windows abandons it: in the new test, the second waiter gets
`WAIT_ABANDONED_0` as soon as its own event is set.

The client side can see when this may happen. The cache entry of an in-process
sync is reference counted and a thread in the middle of an operation on the
object holds a reference, so `NtClose()` (and `NtDuplicateObject()` with
`DUPLICATE_CLOSE_SOURCE`) can tell that another thread is still using a mutex.
In that case it passes the entry's serial number with the `close_handle` /
`dup_handle` request, and the server keeps a reference to the in-process sync
under (process, serial), which keeps the mutex on the list it kills at thread
death. The entry's last user releases it with the new `release_inproc_sync`
request; a process's records go away with the process. A handle closed while
nobody else uses the object, the common case, involves no extra request. This
is the arrangement the comment above `struct inproc_sync` in
`dlls/ntdll/unix/sync.c` already describes (the object outliving its handle
while a waiter uses it), with a serial instead of a handle.

Not covered: users of entries that are not cached (a handle value reused while
the old object is still in use, or more handles than the cache holds), which
`NtClose()` cannot see. Those stay with the orphan list of !<MR 3>.

Tested with `/dev/ntsync`: `kernel32:sync` and `ntdll:sync` pass; the new test
passes (without the change the second waiter times out); the sequence passes 30
of 30 times as a 64-bit and as a 32-bit program; and the server's fd count is
unchanged after 80 runs. The same test binary passes on Windows 11. The test is
ordered after the fix: the CI has no ntsync, so a `todo_wine` would succeed
there.

Patch is here, written by an LLM:
https://github.com/jegglest/wine/commit/ntsync-mutex-in-use-after-close

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.