Even more than with the previous commit, this is not a trivial function
and there's no reason to believe this will actually be inlined nor that
it would be beneficial.
The function isn't necessarily fast (it's O(n)), and there's no reason
to have it defined as inline function, since it's neither fast, nor
entirely trivial.
This is preparation for #28891, which adds a bunch more helpers around
"struct iovec", at which point this really deserves its own .c/.h file.
The idea is that we sooner or later can consider "struct iovec" as an
entirely generic mechanism to reference some binary blob, and is the
go-to type for this purpose whenever we need one.
PAGE_ALIGN() and friends take size_t, while offset is uint64_t.
Let's use macros for uint64_t.
Also, mmap() takes size_t for size. So, let's also use size_t to
calculate a window size.
Prompted by CID#1491286.
Let's support enumerating over devices that match all of the given
properties instead of any of the given properties by adding a new
function sd_device_enumerator_add_match_property_required() which
specifies properties that should all be matched instead of just one.
Fixes#28372
When verifying seals produced with forward secure sealing, the verification
currently does not check that old entries are only sealed with the key for
their epoch and not a more recent one. This missing check allows an attacker
to remove seals, and create new ones with the currently available key, and
verify will claim everything is in order, although all entries could have
been modified.
This resolves CVE-2023-31439.
Co-authored-by: Felix Dörre <felix.doerre@kit.edu>
Previously, if the input offset 'p' does not point to an entry object,
the function returns the next of the nearest entry object on
DIRECTION_DOWN, as generic_array_bisect() already returns the nearest
entry object.
If the first call of generic_array_bisect_plus_one() provides the same
offset, then it is not necessary to call the next one, as we already
know the entry object is also liked to the input data object.
Also, this make the function reuse the object returned by
generic_array_bisect_plus_one().
No functional change, just optimization.
Follow-up for ec50313d4e.
The function generic_array_bisect_plus_one() does not read any new data
objects, so the data object is still valid, and not necessary to re-read it.
And MMapFileDescriptor always references MMapCache, hence it is not
necessary Window to have a reference to MMapCache.
This also renames the list fields 'by_fd' -> 'windows', to make them
consistent with the name of the head.
No functional change, just refactoring.
The post operations (attach the found or new window to a context, update
the keep_always flag, and calculate the address) in three steps are
equivalent, and the two searching logics are quite simple.
Let's merge them to decrease the total lines.
No functional change, just refactoring.
This reverts the following commits.
- a1640191b4
- 231741d355
These were done by my misunderstanding of the mmap cache behavior.
Also, this updates the comments added by
df04b9ed86.
On normal systems, triggering a timeout should be a bug in code or
configuration error, so I do not think we should extend the default
timeout. Also, we should not introduce a 'first class' configuration
option about that. But, making it configurable may be useful for cases
such that "an extremely highly utilized system (lots of OOM kills,
very high CPU utilization, etc)".
Closes#25441.
Then, timout_compare() becomes simplar, the timeout value becomes
consistent with what sd_netlink_get_timeout() provides.
This also drop unnecessary assignment of reply_callback.timeout after
the slot is dropped from the prioq.
Because journal_file_next_entry_for_data() provides the first entry, while
journal_file_next_entry() actually provides the next entry of the input,
this also renames it to journal_file_move_to_entry_for_data().
Also, previously, on DIRECTION_UP the function did not fall back to the
'extra' entry when all entries linked in the chained array are broken.
This also fixes the issue, and now it fall back to the extra entry.
When we reach an empty array, there are at least two possibilities:
- journal file is corrupted,
- invalid index is requested.
We cannot distinguish them here, let's simply return earlier.
If there's corruption and we are going upwards, then the 'total'
must be decreased when we go to the previous array. However,
previously, we wrongly kept or increased the number. This fixes
the behavior.
This effectively reverts d9b61db922.
In the do-while loop, we do not read any other entry array object, hence
the current object is always in the mmap cache and not necessary to re-read it.
Consider the following situation:
- There are two journal files (x and y), that contains entries for two boots (X and Y).
- The journal file x contains entries of the boot X, and y contains
entries of Y.
- Nevertheless x does not contains entries of boot Y, it contains
the _BOOT_ID= data object of boot Y. Of course, the data object is not
referenced by any entries in the journal file x.
In such situation, when the current location of sd_journal is the head
of journal y, that is, the first entry of the boot Y,
sd_journal_previous() failed without this change, and
'journalctl --boot -NUM' for boot X failed.
Fixes#29275.
Lennart Poettering
Yu Watanabe
Frantisek Sumsal
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
felixdoerreandFelix Dörre
Luca Boccassi