summaryrefslogtreecommitdiff
path: root/units/systemd-reboot.service.in
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@gnugeneration.com>2016-04-25 10:58:16 -0700
committerLennart Poettering <lennart@poettering.net>2016-04-25 19:58:16 +0200
commitb8f99e27e13658fd1e33c0e677f657514abc6538 (patch)
treec60e92b308841f584b7c69e8df38a04a7418213c /units/systemd-reboot.service.in
parentd2773e59de3dd970d861e9f996bc48de20ef4314 (diff)
journal: fix already offline check and thread leak (#2810)
Early in journal_file_set_offline() f->header->state is tested to see if it's != STATE_ONLINE, and since there's no need to do anything if the journal isn't online, the function simply returned here. Since moving part of the offlining process to a separate thread, there are two problems here: 1. We can't simply check f->header->state, because if there is an offline thread active it may modify f->header->state. 2. Even if the journal is deemed offline, the thread responsible may still need joining, so a bare return may leak the thread's resources like its stack. To address #1, the helper journal_file_is_offlining() is called prior to accessing f->header->state. If journal_file_is_offlining() returns true, f->header->state isn't even checked, because an offlining journal is obviously online, and we'll just continue with the normal set offline code path. If journal_file_is_offlining() returns false, then it's safe to check f->header->state, because the offline_state is beyond the point of modifying f->header->state, and there's a memory barrier in the helper. If we find f->header->state is != STATE_ONLINE, then we call the idempotent journal_file_set_offline_thread_join() on the way out of the function, to join a potential lingering offline thread.
Diffstat (limited to 'units/systemd-reboot.service.in')
0 files changed, 0 insertions, 0 deletions