Commit 15483b1a12 (server: Allow calling async_handoff() with status
code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result
handler which calls async_set_initial_status().
However, the async_set_initial_status() call does nothing since
async->terminated is set, leaving the async in a confusing state
(unknown_status = 1 but pending/completed).
So far, this issue is unlikely to have been a problem in practice for
the following reasons:
1. async_set_initial_status() would have unset unknown_status, but it
remains set instead. This is usually not a problem, since
unknown_status is usually ever read by code paths effectively
unreachable for non-device (e.g. socket) asyncs.
It would still potentially allow set_async_direct_result to be called
multiple times, but it wouldn't actually happen in practice unless
something goes wrong.
2. async_set_initial_status() would have set initial_status; however,
it is left with the default value STATUS_PENDING. If the actual
status is something other than that, the handler closes the wait
handle and async_satisfied (the only real consumer of initial_status)
would never be called anyway.
For reasons above, this issue is not effectively observable or testable.
Nonetheless, the current code does leave the async object in an
inconsistent state.
Fix this by removing the !async->terminated check in
async_set_initial_status().
Also, remove assert( async->unknown_status ). The client can now
trigger the assert() by calling set_async_direct_result on a device
async, thereby causing async_set_initial_status() to be called twice.
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
b632ddedcd