| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The function to replacement paths into the configuration file list was borked.
Apart from the crash with empty root prefix, it would incorrectly handle the
case where root *was* set, and the replacement file was supposed to override
an existing file.
prefix_root is used instead of path_join because prefix_root removes duplicate
slashes (when --root=dir/ is used).
A test is added.
Fixes #11124.
|
|\ \ \
| | | |
| | | | |
make sure to propagate GPT root partition r/w flag into mount r/w flag
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This ensures that the read/write state of the root mount matches the
read/write flag in the GPT partition table entry.
This is only used as fallback in case no ro/rw flag is specified on the
kernel cmdline, and there's no entry for the root partition in
/etc/fstab.
This is missing functionality of the GPT auto logic, as without this the
root partition was always mounted read-only — when booting with zero
configuration in /etc/fstab and /proc/cmdline —, as we defaulted to
read-only behaviour for all mounts. Moreover we honoured the r/o flag in
the partition table for all other partition types, except for the root
partition.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
No change in behaviour, but let's track whether ro or rw are specified
on the kernel cmdline at all.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Just some refactoring, no change in behaviour.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | | |
gpt-auto-generator: don't wait for udev
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Generators run in a context where waiting for udev is not an option,
simply because it's not running there yet. Hence, let's not wait for it
in this case.
This is generally OK to do as we are operating on the root disk only
here, which should have been probed already by the time we come this
far.
An alternative fix might be to remove the udev dependency from image
dissection again in the long run (and thus replace reliance on
/dev/block/x:y somehow with something else).
Fixes: #11205
|
|\ \ \
| |_|/
|/| | |
Revert the patches for mount-storm prevention for now
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 89f9752ea08f516b5d77f8e577bb772073c70c01.
This patch causes various problems during boot, where a "mount storm" occurs
naturally. Current approach is flakey, and it seems very risky to push a
feature like this which impacts boot right before a release. So let's revert
for now, and consider a more robust solution after later.
Fixes #11209.
> https://github.com/systemd/systemd/pull/11196#issuecomment-448523186:
"Reverting 89f9752ea08f516b5d77f8e577bb772073c70c01 and fcfb1f775ed0e9d282607bb118ba788b98952855 fixes this test."
|
|/ /
| |
| |
| | |
This reverts commit fcfb1f775ed0e9d282607bb118ba788b98952855.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The starting of mount units requires that changes to
/proc/self/mountinfo be processed before the SIGCHILD from the
completion of /sbin/mount is processed, as described by the comment
/* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded
* before we process the SIGCHLD for the mount command. */
The recently-added mount-storm protection can defeat this as it
will sometimes deliberately delay processing of /proc/self/mountinfo.
So we need to disable mount-storm protection when a mount unit is starting.
We do this by keeping a counter of the number of pending
mounts, and disabling the protection when this is non-zero.
Thanks to @asavah for finding and reporting this problem.
|
|\ \
| | |
| | | |
Some git history rewriting and more news
|
| | |
| | |
| | |
| | |
| | |
| | | |
This ain't so easy to express without using too much technical language...
https://github.com/systemd/systemd/pull/10094#issuecomment-427407570
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, setting this option by default was problematic due to
SELinux (as this would also prohibit the transition from PID1's label to
the service's label). However, this restriction has since been lifted,
hence let's start making use of this universally in our services.
On SELinux system this change should be synchronized with a policy
update that ensures that NNP-ful transitions from init_t to service
labels is permitted.
Fixes: #1219
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 3ca9940cb95cb263c6bfe5cfee72df232fe46a94.
Let's split the commit in two: the sorting and the changes.
Because there's a requirement to update selinux policy, this change is
incompatible, strictly speaking. I expect that distributions might want to
revert this particular change. Let's make it easy.
|
|\ \ \
| | | |
| | | | |
More safety checks for fileio.c
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Non-ascii chars are used so that we get both "positive" and "negative"
characters (on the arches where char is signed).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
instead of increasing it and immediately after decreasing it again,
let's just increase it a bit later.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
read_line() is a lot more careful and optimized than read_nul_string()
but does mostly the same thing. let's replace the latter by the former,
just with a special flag that toggles between the slightly different EOL
rules if both.
|
| | | |
| | | |
| | | |
| | | | |
Let's add a size limit, and let's use safe_fgetc().
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
We have very similar code whenever we call fgetc() in place, let's
replae it by a common implementation.
|
|\ \ \ \
| |/ / /
|/| | | |
json: do not unescape slashes
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Apparently this originated in PHP, so the json output could be directly
embedded in HTML script tags.
See https://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped.
Since the output of our tools is not intended directly for web page generation,
let's not do this unescaping. If needed, the consumer can always do escaping as
appropriate for the target format.
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
Merged locally to resolve a conflict. The redirection of error is required to
suppress "# Not showing unlisted system calls, ...".
|
| | | |
|
|\ \ \
| | | |
| | | | |
Various fixups
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
In 595343fb4c99c2679d347ef7c19debfbfed6342e it was converted to an array.
This doesn't look good in the output. Let's convert it back to a string.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
_c is misleading because .h files should be included in those lists too
(this tells meson that the build outputs should be rebuilt if the header
files change).
Follow-up for 1437822638ff9468fa78c7cfe56f8f55f955a61d.
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | | |
rework hashmap_clear()
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The point here is to compare speed of hashmap_destroy with free and a different
freeing function, to the implementation details of hashmap_clear can be
evaluated.
Results:
current code:
/* test_hashmap_free (slow, 1048576 entries) */
string_hash_ops test took 2.494499s
custom_free_hash_ops test took 2.640449s
string_hash_ops test took 2.287734s
custom_free_hash_ops test took 2.557632s
string_hash_ops test took 2.299791s
custom_free_hash_ops test took 2.586975s
string_hash_ops test took 2.314099s
custom_free_hash_ops test took 2.589327s
string_hash_ops test took 2.319137s
custom_free_hash_ops test took 2.584038s
code with a patch which restores the "fast path" using:
for (idx = skip_free_buckets(h, 0); idx != IDX_NIL; idx = skip_free_buckets(h, idx + 1))
in the case where both free_key and free_value are either free or NULL:
/* test_hashmap_free (slow, 1048576 entries) */
string_hash_ops test took 2.347013s
custom_free_hash_ops test took 2.585104s
string_hash_ops test took 2.311583s
custom_free_hash_ops test took 2.578388s
string_hash_ops test took 2.283658s
custom_free_hash_ops test took 2.621675s
string_hash_ops test took 2.334675s
custom_free_hash_ops test took 2.601568s
So the test is noisy, but there clearly is no significant difference with the
"fast path" restored. I'm surprised by this, but it shows that the current
"safe" implementation does not cause a performance loss.
When the code is compiled with optimization, those times are significantly
lower (e.g. 1.1s and 1.4s), but again, there is no difference with the "fast
path" restored.
The difference between string_hash_ops and custom_free_hash_ops is the
additional cost of global modification and the extra function call.
|
| | | |
| | | |
| | | |
| | | | |
This makes it slightly easier to watch for performance changes.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In particular, check that the order of the results is consistent.
This test coverage will be useful in order to refactor the compare_func
used while sorting the results.
When introduced, this test also uncovered a memory leak in sd_lldp_stop(),
which was then fixed by a separate commit using a specialized function
as destructor of the LLDP Hashmap.
Tested:
$ ninja -C build/ test
$ valgrind --leak-check=full build/test-lldp
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Let's first remove an item from the hashmap and only then destroy it.
This makes sure that destructor functions can mdoify the hashtables in
their own codee and we won't be confused by that.
|
|\ \ \ \
| | | | |
| | | | | |
updates for .mailmap and NEWS
|
| | | | | |
|