| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Note that numbers 0 and -1 are both replaced with OBJECT_UNUSED,
because they are treated the same everywhere (e.g. type_to_context()
translates them both to 0).
|
|
If type==0 and a non-NULL object were given as arguments to
journal_file_hmac_put_object(), its object type check would fail and it
would return -EBADMSG.
All existing callers use either a positive type or -1. Still, for
behavior consistency with journal_file_move_to_object() let's allow
type 0 to pass.
|
|
It has no other callers. It does not need to be in the header file.
|
|
The only user is sd_journal_enumerate_unique() and, as explained in
the previous commit (fed67c38e3 "journal: map objects to context set by
caller, not by actual object type"), the use of them there is now
superfluous. Let's remove them.
This reverts major parts of commits:
ae97089d49 journal: fix access to munmapped memory in
sd_journal_enumerate_unique
06cc69d44c sd-journal: fix sd_journal_enumerate_unique skipping values
Tested with an "--enable-debug" build and "journalctl --list-boots".
It gives the expected number of results. Additionally, if I then revert
the previous commit ("journal: map objects to context set by caller, not
to actual object type"), it crashes with SIGSEGV, as expected.
|
|
When the caller of journal_file_move_to_object() specifies type==0,
the object header is at first mapped in context 0. Then after the header
is checked, the whole object is mapped in a context determined by
the actual object type (which is not even range-checked using
type_to_context()). This looks wrong. It should map in the
caller-specified context.
An old comment in sd_journal_enumerate_unique() supports this view:
/* We do not use the type context here, but 0 instead,
* so that we can look at this data object at the same
* time as one on another file */
Clearly the expectation was that the data object will remain mapped
in context 0 without being pushed away by mapping other objects in
context OBJECT_DATA.
I suspect that this was the real bug that got fixed by ae97089d49
"journal: fix access to munmapped memory in sd_journal_enumerate_unique".
In other words, journal_file_object_keep/release are superfluous after
applying this patch.
|
|
This is useful for exposing unsafe access to mmapped objects after
the context that they were mapped in was already moved.
For example:
journal_file_move_to_object(f1, OBJECT_DATA, p1, &o1);
journal_file_move_to_object(f2, OBJECT_DATA, p2, &o2);
t = o1->object.type; /* this usually works, but is unsafe */
|
|
There will be more debugging options later.
--enable-debug will enable them all.
--enable-debug=hashmap will enable only hashmap debugging.
Also rename the C #define to ENABLE_DEBUG_* pattern.
|
|
An early version used underscore prefixes for internal functions, but
the current version uses the prefix "internal_".
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=87271
|
|
This way entries from the same brand with the same dpi and frequency
can be coalesced. It is also visually easier to find the right DPI
than order hexadecimal identifiers.
|
|
|
|
cppcheck would give up with "syntax error" without them. This led
to reports of syntax errors in unrelated locations and potentially
hid other errors
|
|
|
|
|
|
without parameters
|
|
from all interfaces
|
|
further arguments is passed
|
|
|
|
names it knows
|
|
cap_to_name(), for compat reasons
|
|
|
|
command line
|
|
Also, when booting up an ephemeral container of / use the system
hostname as default machine name.
This way specifiyng -M is unnecessary when booting up an ephemeral
container, while allowing any number of ephemeral containers to run from
the same tree.
|
|
system of the OS
This works now:
# systemd-nspawn -xb -D / -M foobar
Which boots up an ephemeral container, based on the host's root file
system. Or in other words: you can now run the very same host OS you
booted your system with also in a container, on top of it, without
having it interfere. Great for testing whether the init system you are
hacking on still boots without reboot the system!
|
|
|
|
|
|
|
|
Make sure to set send-attach-flags on BUS_MAKE. These control which
information is revealed about the bus-owner.
|
|
Make sure we don't call into any bus_kernel_*() functions before
b->is_kernel is set to true. Hard-code the CMD_FREE just like the other
helpers do.
|
|
This adds --template= to duplicate an OS tree as btrfs snpashot and run
it
This also adds --ephemeral or -x to create a snapshot of an OS tree and
boot that, removing it after exit.
|
|
|
|
|
|
|
|
definitions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
resulting name is actually valid
Also, rename filename_is_safe() to filename_is_valid(), since it
actually does a full validation for what the kernel will accept as file
name, it's not just a heuristic.
|
|
Rework the sd-journal iterators to avoid dangling 'else' ambiguity. For a
detailed explanation, see:
commit bff686e2a981ccd0888cdf1981977d24320f1770
Author: David Herrmann <dh.herrmann@gmail.com>
Date: Fri Dec 12 09:43:54 2014 +0100
hwdb: fix dangling 'else' ambuguity
|
|
Imagine the following use of hwdb:
if (condition_A)
SD_HWDB_FOREACH_PROPERTY(hwdb, modalias, key, value)
operation_A(key, value);
else
log_error("...");
This should work just fine, but but definitely does not what you would
expect. Due to how SD_HWDB_FOREACH_PROPERTY is defined, the dangling
'else' is linked to the hidden 'if' statement in the macro instead of the
outer 'if (condition_A)'. This is unexpected and really annoying to debug.
Fix this by never leaving un-finished if-statements in
SD_HWDB_FOREACH_PROPERTY(). We simply inverse the if() statement and
explicitly add an 'else'-branch. This way, the statement is closed and all
ambuguities are resolved.
|
|
Lets not pollute the global namespace. Prefix all our exported names and
macros with SD_HWDB_*.
|
|
|
|
|
|
|
|
|
|
|
