This shows a minor memleak:
==1883== 24 bytes in 1 blocks are definitely lost in loss record 1 of 1
==1883== at 0x4C2DBAB: malloc (vg_replace_malloc.c:299)
==1883== by 0x4E9D385: malloc_multiply (alloc-util.h:69)
==1883== by 0x4EA2959: bus_request_name_async_may_reload_dbus (bus-util.c:1841)
==1883== by ...
The exchange of messages is truncated at two different points: once right
after the first callback is requested, and the second time after the full
sequence has run (usually resulting in an error because of policy).
The function is similar to path_kill_slashes() but also removes
initial './', trailing '/.', and '/./' in the path.
When the second argument of path_simplify() is false, then it
behaves as the same as path_kill_slashes(). Hence, this also
replaces path_kill_slashes() with path_simplify().
First, ellipsize() and ellipsize_mem() should not read past the input
buffer. Those functions take an explicit length for the input data, so they
should not assume that the buffer is terminated by a nul.
Second, ellipsization was off in various cases where wide on multi-byte
characters were used.
We had some basic test for ellipsize(), but apparently it wasn't enough to
catch more serious cases.
Should fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8686.
sparc sets the carry bit when a syscall fails. Use this information to
set errno and return -1 as appropriate.
The added test case calls raw_clone() with flags known to be invalid
according to the clone(2) manpage.
We already do that in get_process_cmdline(), which is very similar in
behaviour otherwise. Hence, let's be safe and also filter them in
get_process_comm(). Let's try to retain as much information as we can
though and escape rather than suppress unprintable characters. Let's not
increase comm names beyond the kernel limit on such names however.
Also see discussion about this here:
https://marc.info/?l=linux-api&m=152649570404881&w=2
For short buffer sizes cellescape() was a bit wasteful, as it might
suffice to to drop a single character to find enough place for the full
four byte ellipsis, if that one character was a four character escape.
With this rework we'll guarantee to drop the minimum number of
characters from the end to fit in the ellipsis.
If the buffers we write to are large this doesn't matter much. However,
if they are short (as they are when talking about the process comm
field) then it starts to matter that we put as much information as we
can in the space we get.
If the timestamp is above 9999-12-30, (or 2038-something-something on 32 bit),
use XXXX-XX-XX XX:XX:XX as the replacement.
The problem with refusing to print timestamps is that our code accepts such
timestamps, so we can't really just refuse to process them afterwards. Also, it
makes journal files non-portable, because suddently we might completely refuse
to print entries which are totally OK on a different machine.
It's not supposed to be the most efficient, but instead fast and simple to use.
I kept the logic in ellipsize_mem() to use unicode ellipsis even in non-unicode
locales. I'm not quite convinced things should be this way, especially that with
this patch it'd actually be simpler to always use "…" in unicode locale and "..."
otherwise, but Lennart wanted it this way for some reason.
This adds fozr new flags:
- If CONF_FILES_DIRECTORY is specified conf_file_list() and friends
will look for directories only.
- Similar CONF_FILES_REGULAR means we'll look only for regular files.
- If CONF_FILES_BASENAME is specified the resulting list will contain
only the basenames of all discovered files or directories, not the
full paths.
- If CONF_FILES_FILTER_MASKED is specified the resulting list will have
masked entries removed (i.e. those symlinked to /dev/null and
suchlike)
These four flags are useful for discovering portable service profile
information.
While we are at it, also improve a couple of other things:
- More debug logging
- use path_hash_ops instead of string_hash_ops when putting together the
path lists
Most our other parsing functions do this, let's do this here too,
internally we accept that anyway. Also, the closely related
load_env_file() and load_env_file_pairs() also do this, so let's be
systematic.
This call creates an fd from another fd containing the same data.
Specifically, repeated read() on the returned fd should return the same
data as the original fd. This call is useful when we want to copy data
out of disk images and suchlike, and want to be pass fds with the data
around without having to keep the disk image continously mounted.
The implementation tries to be somewhat smart and tries to prefer
memfds/pipes over files in /tmp or /var/tmp based on the size of the
data, but has appropropriate fallbacks in place.
On both 32 and 64 bits, the result is:
enum Enum → 32 bits, unsigned
enum BigEnum → 32 bits, unsigned
enum BigEnum2 → 64 bits, unsigned
big_enum2_pos → 4
big_enum2_neg → 8
The last two lines show that even if the enum is 64 bit, and the field of an
enum is defined with UINT64_C(), the field can still be smaller.
This simplifies the use of tempfiles in tests and fixes "leaked"
temporary files in test-fileio, test-catalog, test-conf-parser.
Not the whole tree is converted.
That way we can use it in nspawn.
Also, while we are at it, let's rename the call config_parse_rlimit(),
i.e. insert the "r", to clarify what kind of limit this is about.
Initializing just some of the values doesn't make sense. We should handle them
all in the same way. In those tests there are no jumps, all steps are covered
with assert_se(), so we know everything will be set if we get to the end of the
function. And _not_ initializing those variables has the advantage that it
allows valgrind to catch potential initalization errors in the function being
tested.
We were inconsitently using them in some cases, but in majority not.
Using assignment in assert_se is very common, not an exception like in
'if', so let's drop the extra parens everywhere.
When I see "test", I have to think three times what the return value
means. With "below" this is immediately clear. ratelimit_below(&limit)
sounds almost like English and is imho immediately obvious.
(I also considered ratelimit_ok, but this strongly implies that being under the
limit is somehow better. Most of the times this is true, but then we use the
ratelimit to detect triple-c-a-d, and "ok" doesn't fit so well there.)
C.f. a1bcaa07.
