We obviously have lots of those, so even small savings add up.
Bitfields are dropped because they don't give any memory savings due to
alignment requirements (but would still require more complex to access).
/* size: 184, cachelines: 3, members: 28 */
/* sum members: 172, holes: 1, sum holes: 4 */
/* sum bitfield members: 4 bits (0 bytes) */
/* padding: 7 */
/* bit_padding: 4 bits */
↓
/* size: 176, cachelines: 3, members: 28 */
The structure is rearranged to have less holes. Also fields in the union
are rearranged not to have holes (though most variants of the union still
have some padding at the end).
The full size does not decrease a lot, but the compiler should be able to
copy less bytes when it knows the specific type of the union.
Bitfields are dropped because they don't give any memory savings due to
alignment requirements (but would still require more complex to access).
The change from the this and previous commit:
/* size: 128, cachelines: 2, members: 13 */
/* sum members: 112, holes: 3, sum holes: 15 */
/* sum bitfield members: 2 bits, bit holes: 1, sum bit holes: 6 bits */
↓
/* size: 112, cachelines: 2, members: 13 */
/* sum members: 108, holes: 1, sum holes: 4 */
Change from the last three commits:
/* size: 312, cachelines: 5, members: 46 */
/* sum members: 296, holes: 5, sum holes: 16 */
↓
/* size: 288, cachelines: 5, members: 46 */
/* sum members: 286, holes: 1, sum holes: 1 */
It's not a big difference, but we might have quite a few queries in flight,
so let' make this a bit more efficient.
Meson 0.58 has gotten quite bad with emitting a message every time
a quoted command is used:
Program /home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh found: YES (/home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program xsltproc found: YES (/usr/bin/xsltproc)
Configuring custom-entities.ent using configuration
Message: Skipping bootctl.1 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping journal-remote.conf.5 because HAVE_MICROHTTPD is false
Message: Skipping journal-upload.conf.5 because HAVE_MICROHTTPD is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping loader.conf.5 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
...
Let's suffer one message only for each command. Hopefully we can silence
even this when https://github.com/mesonbuild/meson/issues/8642 is
resolved.
Currently the label database is not reloaded with libselinux 3.2 on a
policy reload.
Since libselinux 3.2 avc_open(3) uses the SELinux status page instead of
a netlink socket to check for policy reloads.
The status page is also queried in mac_selinux_maybe_reload().
Thus calls to selinux_check_access(3) might consume an update, queried
by selinux_status_updated(3), leaving mac_selinux_maybe_reload() unable
to detect a policy reload.
Do not use selinux_status_updated(3), use selinux_status_policyload(3)
unconditionally.
Relevant libselinux commit: https://github.com/SELinuxProject/selinux/commit/05bdc03130d741e53e1fb45a958d0a2c184be503
Debian Bullseye is going to ship libselinux 3.1, so stay compatible for
backports.
The settings were listen in a completely random order, also different
between the v4 and v6 sections. Order by "options sent", "options received",
"communication settings" in both sections.
Also minor formatting changes are done, e.g. "=" is added in various places.
When `--json` option is specified, "status" and "list" commands gives
the same information, as originally "list" just gives partial
information of "status" in different format.
systemd-run is documented to as being able to connect and run on a
specific user bus with "--user --machine=lennart@.host" arguments.
This PR updates some logic that prevented this from working.
I occasionally do 'build/man/man systemd.directives' when working on man pages,
and it's annoying slow. By paralellizing the parsing of xml, we can make it a
bit faster.
This is still rather innefficient. Only the parsing part is serialized, xml is
still produced serially at the end, which is hard to avoid.
$ ninja -C build man/systemd.directives.xml
before:
8.20s user 0.21s system 99% cpu 8.460 total
8.33s user 0.18s system 98% cpu 8.619 total
8.72s user 0.19s system 98% cpu 9.019 total
after:
13.99s user 0.73s system 345% cpu 4.262 total
14.15s user 0.35s system 348% cpu 4.161 total
14.33s user 0.35s system 339% cpu 4.321 total
I.e. it uses almost twice as much cpu, but cuts the wallclock time down (on a
2-core/4-thread cpu) to about half too, which is an overall win if you're just
trying to render the man page.
The change from list and .append() to set and .add() is something that could
have been done before too, but it's noticable now. It cuts down on the
serialization/deserialization time (about .2s).
- Internet specifications give 1600 DPI @ 1000Hz for this sensor
- Confirmed experimentally via `mouse-dpi-tool`
- vid, pid, and name match string from `mouse-dpi-tool`
The code in service_spawn() was written as if exec_fd_event_source
was always unset. (We would either fail the assertion that is moved in the
patch, or leak the event source object if it was set.)
To make this work, let's always assert that exec_fd_event_source is unset,
and actually unset it service_sigchld_event(). I think this is the most
elegant approach. The problem is that we don't have the same information
about execution flags as in service_spawn(), so we need to conditionalize
on pid==main_pid to know if we should disable exec_fd_event_source.
I think this matches all cases where we may set exec_fd_event_source:
service_enter_start() and service_run_next_main().
service_enter_stop_post() calls service_set_state(), which will also destroy
the source. But that happens too late, because from service_enter_stop_post()
we call service_spawn() first, and then service_set_state() second.
(An alternative approach would be to deallocate the existing
exec_fd_event_source in service_spawn(). But this would mean that we would
temporarily have an event source attached to a process that we already know is
dead, which seems less than ideal.)
Original report from Dimitri John Ledkov <dimitri.ledkov@canonical.com>:
> Ubuntu private bug reference for this issue at the moment is
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1921145
> Michael's and Ian's team run into an issue when using systemd in the
> initrd, without dbus daemon running, and launching a unit in a
> particular way that appears to lock up systemd (pid 1) it self.
> michael vogt: "The attached script works for me to reproduce this on
> classic. I tested 20.04 (245) and 21.04 (247) in a qemu VM. Sometimes
> I need to run it multiple times but usually it crashes after at most 2
> runs. Use "journalctl | tail" to see the messages, it's the same that
> Ian reported. There is also a /var/crash/_usr_lib_systemd_systemd
> crash file created."
> I understand that the particular way to run a unit is very odd,
> however, it is currently possible to invoke, and it would be expected
> for pid1 to not lock up and crash.
> The Assertion that systemd hits is along the lines of:
> [ 10.182627] systemd[1]: Assertion 's' failed at
> src/core/service.c:3204, function service_dispatch_exec_io().
> Aborting.
> [ 10.195458] systemd[1]: Caught <ABRT>, dumped core as pid 449.
> [ 10.204446] systemd[1]: Freezing execution.
Apparently CAN links will show up in rtnetlink with very low MTUs. We
shouldn't consider them relevant if no IP is spoken over them, since
these MTUs are irrelevant for us then.
Hence, let's check if there's an address assigned to the link before
considering its MTU.
As additional safety net filter out MTUs smaller than the minimum DNS
packet size, too.
Finally, in case we don't find any suitable interface MTU, let's default
to 1500 as the generic Ethernet MTU.
Fixes: #19396
This was a copy/paste mistae apparently, there's not "try_authtok" and
this was supposed to copy what Fedora uses, which uses "use_authtok"
correctly. Hence adjust this.
Fixes: #19369
This mirrors the change done for systemd-resolved in
9793530228. Quoting that patch:
> We generally operate on the assumption that a source is "gone" as soon as we
> unref it. This is generally true because we have the only reference. But if
> something else holds the reference, our unref doesn't really stop the source
> and it could fire again.
In particular, we take temporary references from sd-event code, and when called
from an sd-event callback, we could temporarily see this elevated reference
count. This patch doesn't seem to change anything, but I think it's nicer to do
the same change as in other places and not rely on _unref() immediately
disabling the source.
This drops the "const" specifier from the opaque object parameters to
various functions in our API.
This effectively reverts #19292 and more.
Why drop this? Our public APIs should not leak too much information
about how stuff is implemented internally. In our public APIs we
shouldn't give too many guarantees we don#t want to necessarily keep.
Specifically: in many cases it makes sense that getters actually
generate/parse/allocate data on the fly, storing/caching the result
internally, to speed things up, do things lazily or to track memory
allocations so that they can be freed later. Doing this means we need to
change the objects, even though the getters are semantically a read
operation.
We want to retain the freedom that we can change things around
internally. By exposing the objects as "const" we remove a good chunk of
that, for little gain.
See sd_bus_creds_get_description() for a real example of a getter that
implicitly caches and thus modifies the relevant object.
This removes the "const" decorators from sd-dhcp and sd-netlink, two
APIs that we intend to make public eventually even though they still are
not, leaving us the chance to still fix this before it becomes set in
stone.
