[PATCH] ntdll: Add SIGQUIT to server block set.

[Alexandre Julliard]

Paul Gofman <pgofman at codeweavers.com> writes:

> On 9/14/20 16:01, Alexandre Julliard wrote:
>> Paul Gofman <pgofman at codeweavers.com> writes:
>>
>>> Receiving SIGQUIT for forced thread termination may leave sync
>>> objects (like virtual_mutex) locked.
>> I suspect that this will only create a different class of deadlocks,
>> with threads that can't be killed. Avoiding locks at process exit is
>> probably safer.
>>
> The same problem may potentially happen if some thread is killed by
> NtTerminateThread without relation to process exit. SIGQUIT is
> probably not the only scenario, I guess we can potentially leave the
> lock when processing, e. g., SEGFAULT during the lock and returning to
> the syscall frame. Should not we try harder to avoid leaving ntdll.so
> object locked? Maybe we can instead store the mutex pointer in thread
> data and unlock it when leaving the ntdll.so scope due to SIGQUIT or
> SEGFAULT?

In general you can't unwind a mutex lock from an asynchronous signal. In
theory of course we should never hang inside the kernel, but
NtTerminateThread can just as well hang on a user space lock that can't
be recovered from either, so it's not clear that it's a big issue in
practice, outside of the process exit case. I'd suggest to fix that one
first and see how far it gets us.

-- 
Alexandre Julliard
julliard at winehq.org