resolved: when adding RR to an answer, avoid comparing keys twice
We'd call dns_resource_record_equal(), which calls dns_resource_key_equal()
internally, and then dns_resource_key_equal() a second time. Let's be
a bit smarter, and call dns_resource_key_equal() only once.
(before)
dns_resource_key_hash_func_count=514
dns_resource_key_compare_func_count=275
dns_resource_key_equal_count=62371
4.13s user 0.01s system 99% cpu 4.153 total
(after)
dns_resource_key_hash_func_count=514
dns_resource_key_compare_func_count=276
dns_resource_key_equal_count=31337
2.13s user 0.01s system 99% cpu 2.139 total
resolved: use a temporary Set to speed up dns question parsing
This doesn't necessarily make things faster, because we still spend more time
in dns_answer_add(), but it improves the compuational complexity of this part.
If we even make dns_resource_key_equal_faster, this will become worthwhile.
Same as with the other users, any non-trivial use of the objects requires
use from a single thread only or external locking. Using atomic operations
just for reference counts is not useful.
The sd-hwdb objects cannot be used concurrently from two threads in any
meaningful way, because query and iteration operations modify the object.
Thus atomic reference counts are pointless.
We had atomic counters, but all other operations were non-serialized. This
means that concurrent access to the bus object was only safe if _all_ threads
were doing read-only access. Even sending of messages from threads would not be
possible, because after sending of the message we usually want to remove it
from the send queue in the bus object, which would race. Let's just kill this.
btrfs: when falling back to plain copy when snapshoting exclude submounts
The subvol snapshot logic doesn't cover sub-mounts either, and it really
shouldn't in the general case, hence let's simply stop at submounts in
all cases, both in the main and in the fall-back codepath.
bus-message: introduce two kinds of references to bus messages
Before this commit bus messages had a single reference count: when it
reached zero the message would be freed. This simple approach meant a
cyclic dependency was typically seen: a message that was enqueued in a
bus connection object would reference the bus connection object but also
itself be referenced by the bus connection object. So far out strategy
to avoid cases like this was: make sure to process the bus connection
regularly so that messages don#t stay queued, and at exit flush/close
the connection so that the message queued would be emptied, and thus the
cyclic dependencies resolved. Im many cases this isn't done properly
however.
With this change, let's address the issue more systematically: let's
break the reference cycle. Specifically, there are now two types of
references to a bus message:
1. A regular one, which keeps both the message and the bus object it is
associated with pinned.
2. A "queue" reference, which is weaker: it pins the message, but not
the bus object it is associated with.
The idea is then that regular user handling uses regular references, but
when a message is enqueued on its connection, then this takes a "queue"
reference instead. This then means that a queued message doesn't imply
the connection itself remains pinned, only regular references to the
connection or a message associated with it do. Thus, if we end up in the
situation where a user allocates a bus and a message and enqueues the
latter in the former and drops all refs to both, then this will detect
this case and free both.
Note that this scheme isn't perfect, it only covers references between
messages and the busses they are associated with. If OTOH a bus message
is enqueued on a different bus than it is associated with cyclic deps
cannot be recognized with this simple algorithm, and thus if you enqueue
a message associated with a bus A on a bus B, and another message
associated with bus B on a bus A, a cyclic ref will be in effect and not
be discovered. However, given that this is an exotic case (though one
that happens, consider systemd-bus-stdio-bridge), it should be OK not to
cover with this, and people have to explicit flush all queues on exit in
that case.
Note that this commit only establishes the separate reference counters
per message. A follow-up commit will start making use of this from the
bus connection object.
sd-bus: make sure dispatch_rqueue() initializes return parameter on all types of success
Let's make sure our own code follows coding style and initializes all
return values on all types of success (and leaves it uninitialized in
all types of failure).
Let's do this like we usually do and size arrays with size_t.
We already do this for the "allocated" counter correctly, and externally
we expose the queue sizes as uint64_t anyway, hence there's really no
point in usigned "unsigned" internally.
copy: don't synthesize a 'user.crtime_usec' xattr on copy unless explicitly requested
Previously, when we'd copy an individual file we'd synthesize a
user.crtime_usec xattr with the source's creation time if we can
determine it. As the creation/birth time was until recently not
queriable form userspace this effectively just propagated the same xattr
on the source to the same xattr on the destination. However, current
kernels now allow to query the birthtime using statx() and we do make
use of that now. Which means that suddenly we started synthesizing these
xattrs much more regularly.
Doing this actually does make sense, but only in very few cases:
not for the typical regular files we copy, but certainly when dealing
with disk images. Hence, let's keep this kind of propagation, but let's
make it a flag and default to off. Then turn it on whenever we deal with
disk images, and leave it off otherwise.
This is particularly relevant as overlayfs combining a real fs, and a
tmpfs on top will result in EOPNOTSUPP when it is attempted to open a
file with xattrs for writing, as tmpfs does not support xattrs, and
hence the copy-up cannot work. Hence, let's avoid synthesizing this
needlessly, to increase compat with overlayfs.
nspawn: rework how arg_read_only is initialized in --volatile= mode
Previously, we'd refuse the combination, and claimed we'd imply it, but
actually didn't. Let's allow the combination and imply read-only from
--volatile=, because that's what's documented, what we claim we do, and
what makes sense.
We document and all our code assumes that LoaderDevicePartUUID is
initialized to the ESP's UUID. Let's hence not override the variable if
it is already set, in order to not confuse userspace if the kernel's EFI
image is run from a different partition than the ESP.
This matches behaviour for all other variables set by the EFI stub, in
particular the closely related LoaderImageIdentifier variable.
Our own variables are in the the "loader" GUID namespace, but our code
so far checked the "global" GUID namespace (i.e. EFI's own), before
setting the variables. Correct that, so that we always check the right
namespace for existing variables before we write them.
sd-boot: don't dereference NULL ptr if loaded_image_path is NULL
In a follow-up commit we'd like to invoke config_entry_add_from_file()
on partitions that are not the ESP, let's prepare fpr that and allow
loaded_image_path to be passed as NULL.
sd-boot: pass device handle to config_entry_add_linux()
This makes the code a bit simpler (after all the call is not interested
in the loaded image, just where it is found), and more like
config_load_entries() which takes the same arguments.
This also makes things easier for us later on, when we add support for
discovering images in $XBOOTLDR partitions.
bootspec: split out code that validates whether directory is top-level dir of fs
Let's add a new function that checks whether some directory is the
top-level directory inside an fs, splitting out the code for this from
verify_esp().
While we are at it, let's slightly improve the code, so that we can
correctly work if we have no priviliges but the ESP is mounted
unaccessible: if we can't stat() the path "$ESP/.." then manually remove
the last component of $ESP and check that instead. Which is very similar
in behaviour, and hopefully good enough in the unprivileged case.
bootspec: if unprivileged validate partition data with udev rather than blkid directly
udev metadata access works unprivileged, which the blkid stuff doesn't
(as that needs raw device node access). Hence let's use udev if we lack
privs, and raw device access only if root.
projects / thirdparty / systemd.git / log
