IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Whereas RFC 1035 says the TTL field takes the "positive values of a
signed 32 bit number", and RFC 2181 says "Implementations should treat
TTL values received with the most significant bit set as if the entire
value received was zero,", the dns_packet_read_rr() function sets
rr->ttl to zero if the MSB is set.
However, EDNS(0) as specified in RFC 6891 repurposes the TTL field's 4
octets to store other information, c.f.:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The first octet extends the usual 4-bit RCODE from the packet header by
providing an additional 8 bits of space, extending the RCODE to 12 bits.
But, our handling of the TTL field means that the high bit in the first
octet is not actually usable, since setting it will mean these 4 octets
are replaced with 0. This may have the effect of making us believe a
server does not support DNSSEC when it actually set the DO bit in its
OPT record.
Here we change things so that the TTL is only set to zero for record
types other than OPT.
When running the test on aarch64 the symlinks look as follows:
"""
[root@H ~]# ls /dev/disk/by-path
platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0 platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part1 platform-4010000000.pcie-pci-0000:00:05.0-nvme-16
platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part platform-4010000000.pcie-pci-0000:00:04.0-scsi-0:0:0:0-part2 platform-4010000000.pcie-pci-0000:00:05.0-nvme-17
"""
So let's make the PCI patterns a little more generic so they match
both the x86 and the aarch64 paths.
We would say how *sources* are licensed, but actually most user care about the
resulting binaries. So say how the *binaries* are licensed. I used the word
"effectively" because the permissive licenses don't set any requirements on the
binaries, so the license of sources is a complex mix, but the resulting
binaries have a simple effective license.
Also, make it clear that the GPLv2 license applies to udev programs, but not
the shared library. Based on private correspondence, there's some confusion
about this.
Using double quotes in f-strings only works from python 3.12 onwards.
Use single quotes to make sure python 3.9 works as well.
Also clean up quotes a little in general.
Trying to use bus pci slot 0 fails on aarch64 so let's use 1 instead.
The error:
"""
qemu-system-aarch64: -device virtio-blk-pci,drive=drive0,scsi=off,bus=pci_bridge25: Unsupported PCI slot 0 for standard hotplug controller. Valid slots are between 1 and 31.
"""
It's the same old story: 'struct sd_bus' is generally instantiated once, so
bitfields, for which we pay with more complicated code in all users of this
struct, are counterproductive. In some progs the structure may be instantiated
a few times, but it's still not worth it because we save a few bytes of memory
in one place and pay for this with many more bytes in the code.
$ size build/libsystemd.so.0.39.0{.orig,}
text data bss dec hex filename
2452757 65376 3768 2521901 267b2d build/libsystemd.so.0.39.0.orig
2451669 65376 3768 2520813 2676ed build/libsystemd.so.0.39.0
$ diff -u <(pahole build/libsystemd.so.0.39.0.orig) <(pahole build/libsystemd.so.0.39.0)
...
- /* size: 1960, cachelines: 31, members: 105 */
- /* sum members: 1944, holes: 3, sum holes: 9 */
- /* sum bitfield members: 25 bits, bit holes: 2, sum bit holes: 31 bits */
+ /* size: 1984, cachelines: 31, members: 105 */
+ /* sum members: 1971, holes: 4, sum holes: 13 */
/* member types with holes: 1, total: 1 */
i.e. 2452757 - 2451669 = 1088 extra bytes of code and slower execution, to save
24 bytes of memory per instance of the struct. (But the number of cachelines
doesn't change, so the smaller struct most likely has no effect on memory
access, and the alignment of the struct most likely means that the memory
saving is illusory too, we just end up with a few bytes of padding after the
struct.)
In the other structs, the alignment prevent the bitfield for having any effect
on memory use, but the compiler would still generate more complicated code,
i.e. we pay something for nothing.
For example:
$ diff -u <(pahole build/libsystemd.so.0.39.0.orig) <(pahole build/libsystemd.so.0.39.0)
...
struct node_callback {
struct node * node; /* 0 8 */
- _Bool is_fallback:1; /* 8: 0 1 */
+ _Bool is_fallback; /* 8 1 */
- /* XXX 7 bits hole, try to pack */
/* XXX 3 bytes hole, try to pack */
unsigned int last_iteration; /* 12 4 */
@@ -455,15 +448,13 @@
struct node_callback * callbacks_prev; /* 32 8 */
/* size: 40, cachelines: 1, members: 6 */
- /* sum members: 36, holes: 1, sum holes: 3 */
- /* sum bitfield members: 1 bits, bit holes: 1, sum bit holes: 7 bits */
+ /* sum members: 37, holes: 1, sum holes: 3 */
/* last cacheline: 40 bytes */
};
I kept the bitfield in sd_bus_slot because it prevents the struct from growing
from 112 to 120 bytes by reducing the alignment requirement for subsequent
fields, and we potentially can have this instantiated many times.
The arg types==NULL has different meanings for different functions. Some
functions like sd_bus_message_appendv() require a non-null param and treat "" as
"no data". Other functions like sd_bus_skip() treat null as "process one item",
while the convenience functions treat NULL the same as "". So I think it's
reasonable to make the convenience functions handle NULL explicitly, separately
from "". That way the logical separation of concerns is clearer, and e.g.
sd_bus_message_appendv() handles all non-null strings, while e.g.
sd_bus_call_methodv() doesn't look into the string at all.
Behaviour is unchanged.
I expect the test output to be the second argument, so we're diffing "expected"
and "output", not the other way around.
I noticed this when working on https://github.com/systemd/systemd/pull/33081.
In mkosi.images/system/mkosi.conf, we configure the certificate as
an extra tree so it's available inside the image. However, we pick up
the certificate from the top level repository directory and not from the
build directory where it is generated by the genkey meson target.
We currently have no way to access the build directory that mkosi was
invoked from when parsing the configuration file. Thus we have no way to
specify the correct location to the certificate when it's located in the
build directory.
For now, let's look for the key and certificate in the top level repository
root directory and drop the genkey target.
We don't have to change the Github Actions CI because it already runs genkey
manually before the image build (which is something we forgot to remove when
introducing the genkey target and is the reason this didn't cause issues before).
There are two ways to get the command line: from the EFI shell,
preparsed, already split at whitespace. This we just combine with
spaces, since kernel wants it as one string.
And as one command line blob which is how we are invoked otherwise and
which comes with all kinds of whitespace quite likely.
Let's only strip leading and trailing whitespace in the latter case,
given it's likely the concatenation of whitespace separated strings
generated by shell scripts and such. But let's not strip it we already
received a preparsed array.
Update the man page of tmpfiles.d to remove outdated comments regarding the behavior of ownership with symlinks.
The behavior has been changed in this commit 51207ca134716a0dee5fd763a6c39204be849eb1
Now that we're running on Noble instead of Jammy btrfs has the temp_fsid
feature which means we can mount the same image multiple times so let's
switch back to btrfs instead of ext4 as the filesystem as btrfs properly
records timestamps when building filesystems from a root directory unlike
ext4.
The new "password-cache" option allows customizing behavior of the
ask-password module in regards to caching credentials in the kernel
keyring. There are 3 possible values for this option:
* read-only - look for credentials in kernel keyring before asking
* on - same as read-only, but also save credentials input by user
* off - disable keyring credential cache
Currently the cache is forced upon the user and this can cause issues.
For example, if user wants to attach two volumes with two different
FIDO2 tokens in a quick succession, the attachment operation for the
second volume will use the PIN cached from the first FIDO2 token, which
of course will fail and since tokens are only attempted once, this will
cause fallback to a password prompt.
Currently, if user doesn't specify a key file, /etc/cryptsetup-keys.d/
and /run/cryptsetup-keys.d/ will be searched for a key file with name
matching the volume name. But current implementation has an important
flaw. When the auto-discovered key is a socket file - it will read the
key only once, while the socket might provide different keys for
different types of tokens. The issue is fixed by trying to discover the
key on each unlock attempt, this way we can populate the socket bind
name with something the key provider might use to differentiate between
different keys it has to provide.
If people want they should be able to turn on this flag, to allow
interactive auth. Let's make sure this actually works. i.e. add it to
the introspection data and don't refuse the parameter in Describe().
(note the varlink handling already does parameter validation through
varlink_dispatch(), hence we can just drop any further validation)
The logic of the Describe() call was supposed to be: if we can acquire
the PK priv to get the product UUID then let's return the product UUID,
and if we cannot then return the data without it.
This didn't work however, since the polkit varlink glue would
immediately propagate the error it acquired from polkit its own client.
Let's turn this off, optionally, so that hostnamed can handle this
nicely.
This adds varlink_server_add_connection_stdio() as wrapper around
varlink_server_add_connection_pair(), that steals stdin/stdout fds and
turns them into a varlink connection. To be safe it replaces
stdin/stdout with /dev/null fds.
When invoking another process via a pair of pipes it makes sense to
allow reading from one fd, and writing from another. Teach our varlink
code to do so optionally.
(sd-bus supports something similar, fill the gap).
This is preparation for a later commit that uses this to talk to remote
SSH invocations via pipes.
The kernel's sched_setattr interface allows for more control over a processes
scheduling attributes as the previously used sched_setscheduler interface.
Using sched_setattr is also the prerequisite for support of utilization
clamping (UCLAMP [1], see #26705) and allows to set sched_runtime. The latter,
sched_runtime, will probably become a relevant scheduling parameter of the
EEVDF scheduler [2, 3], and therefore will not only apply to processes
scheduled via SCHED_DEADLINE, but also for processes scheduled via
SCHED_OTHER/SCHED_BATCH (i.e., most processes).
1: https://docs.kernel.org/next/scheduler/sched-util-clamp.html
2: https://lwn.net/Articles/969062/
3: https://lwn.net/ml/linux-kernel/20240405110010.934104715@infradead.org/
