]> git.ipfire.org Git - thirdparty/systemd.git/commit - src/journal/journal-file.c
journal-file: we can't use a chain cache entry if we don't know where it starts ...
authorLennart Poettering <lennart@poettering.net>
Tue, 27 Mar 2018 07:36:49 +0000 (09:36 +0200)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Tue, 27 Mar 2018 07:36:49 +0000 (09:36 +0200)
commit96d4d0244bf6eabfd3598177101046653cb70e64
treee6498dd050bc52c35886d34bc3a4d2c083c23277
parent08c849815c8db19ab0ab1ca226354d4a104041f0
journal-file: we can't use a chain cache entry if we don't know where it starts (#8542)

It might happen that we try to bisect through a chain of offset arrays in the
journal whose last element was just allocated but no item yet written
to. In that case that array will be all NUL, but it might still end up
in our array chain cache. If it does, we cannot use it for bisection,
since for bisection we need to know the value of the first entry in that
array, but if it's uninitialized it does not have a first value. Hence,
as a simple fix, in this unlikely case, simply ignore the chain cache.

This is supposed to fix the issue pointed out in #8432, but in a more
permissive way, as this case isn't strictly a badly formatted journal
but actually a valid state (though one within a very short time window),
and we should make the best of it, and handle it gracefully.

Background: in each journal file entries are linked up in large arrays
of offsets. In each array the entries are strictly ordered by the
offsets of the entries, which permits search by bisection. These arrays
are allocated with a fixed size and then filled up as entries are added
to the journal file. If an array is fully filled up, a new array
(double in size as the old one) is appended to the journal file, and
linked up. This means, the journal file will contain a series of chained
up arrays, each time doubling in size, and strictly ordered. When
looking for an entry we maintain a "chain cache", which allows us to
bypass traversing the chain in full if we look for entries close to each
other in a short time. With the fix above we make sure we don't
erroneously use a chain cache item that doesn't carry enough information
for this bisection to work.

Original issue identified (with patch) by @Kxuan.

Replaces: #8432
src/journal/journal-file.c