diff options
author | Miloslav Trmač <mitr@redhat.com> | 2018-04-02 11:11:32 -0400 |
---|---|---|
committer | Ray Strode <rstrode@redhat.com> | 2018-04-02 17:32:25 -0400 |
commit | 4d3ad67431ff3efe9ae51d1f0cf00ffc91aafa89 (patch) | |
tree | bfbce00461ff52270147226d86b7845782c8c786 /src/examples/cancel.c | |
parent | 3345c10cf93dd42cb37f06c7074669ae315c3280 (diff) | |
download | polkit-4d3ad67431ff3efe9ae51d1f0cf00ffc91aafa89.tar.gz |
Fix a race condition when terminating runaway_killer_thread
The code used to call g_main_loop_quit() from the main thread, without
having any guarantee that runaway_killer_thread_func() has even entered
its g_main_loop_run(). If a main loop is not running,
g_main_loop_quit() has no effect.
This could occasionally be reproduced in
test-polkitbackendjsauthority.c, which is creating several very
short-lived PolkitBackendJSAuthority instances. Real polkitd should not
generally be affected, because it is using a single instance running for
the life of the process ~ for the uptime of the system, enough time to
enter the runaway_killer_thread main loop.
To fix this, use g_idle_source_new () to make sure g_main_loop_quit ()
is called from within the running main loop.
Also, simplify the initialization of runaway_killer_thread by moving the
creation of rkt_context and rkt_loop into the main thread; this makes
the condition variable and its associated mutex completely unnecessary.
Finally, only destroy rkt_timeout_pending_mutex _after_ the thread
terminates; before, we were certain that rkt_source was destroyed by
that time, but AFAICS that does not ensure that the rkt_on_timeout ()
callback has already terminated.
https://bugs.freedesktop.org/show_bug.cgi?id=95513
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Diffstat (limited to 'src/examples/cancel.c')
0 files changed, 0 insertions, 0 deletions