journal: deal better with reading from zeroed out journal mmaps #15557
Conversation
When accessing journal files we generally are fine when values change beneath our feet, while we are looking at them, as long as they change from something valid to zero. This is required since we nowadays forcibly unallocate journal files on vacuuming, to ensure they are actually released. However, we need to make sure that the validity checks we enforce are done on suitable copies of the fields in the file. Thus provide a macro that forces a copy, and disallows the compiler from merging our copy with the actually memory where it is from.
The value might change beneath what we do, and hence let's avoid any chance of underflow.
Mappings canbe replaced by all zeroes under our feet if vacuuming decides to unallocate some file. Hence let's not check for this kind of stuff in an assert. (Typically, we should genreate runtime errors in this case, in particular EBADMSG, which the callers generally look for. But in this case this is just an extra precaution check anyway, so let's just remove it.)
… arithmetics on them Our journal code is generally supposed to be written in a fashion that the underlying file can be deallocated any time, i.e. our mmap of it suddenly becomes all zeroes. The idea is that we catch that when parsing everything. For that to work safely we need to make sure that when doing arithmetics or comparisons on values read from the map we don't run into TTOCTTOU issues when determining validity. Hence we need to copy out the values before use and operate on the copies. This requires some special care since the C compiler could suppress our copies as optimization. Hence use the new READ_NOW() macro to force a copy by using memcpy(), and use it whenever we start doing an arithmetic operation on it, or validity checking of multiple steps. Fixes: systemd#14943
|
LGTM |
|
Hi @poettering we are getting below crash in our CI environment with systemd v244, so could you please confirm whether this PR will fix it? If yes then I will send back port of these PR to v244 as well: |
A fix for #14943