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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
TL;DR
This effectively reverts 8327fd1b11,
eaba9bb3e6, and its follow-ups, as the
original issue was already fixed by the kernel side.
The original issue that the above commits tried to 'fix' is that reading
phys_port_name triggers a lock in the kernel, hence processing multiple
interfaces at the same time causes extreme slow down.
To workaround the issue, the above commits made several necessary
information retrieved through netlink instead of sysfs attributes.
A patch set for the kernel was proposed as a fix for the issue:
https://lore.kernel.org/all/20210928125500.167943-1-atenart@kernel.org/
and some of them were merged to v5.16:
146e5e7333,
It has been already backported to 5.4.160, 5.10.80, 5.14.19, and 5.15.3.
When these commits were proposed, it is already claimed that such issue
should be fixed by the kernel side, and udevd should not workaround it.
Neverthless the feature was introduced, as these have theoretical
performance improvement, even if phys_port_name sysattr does not have the
above issue, as in that way udevd can obtain multiple information about
the interface with a single netlink socket operation. See the discussion
in #20744.
However, in reality, only `iflink`, `type`, `address`, and `phys_port_name`
attributes from netlink are used in the udev net_id builtin command. Hence,
after the original issue being fixed in the kernel side, there should be
almost no performance improvement for udevd.
Furthermore, combining attributes from netlink and sysfs makes hard to
test net_id builtin. See #21725.
Let's drop mostly meaningless code, and make net_id builtin easily testable.
Closes#21725.
The compiler may decide computations like these are not doing anything
and decide to optimize them away. This would defeat the whole fuzzing
exercise. This macro will force the compiler to materialize the value
no matter what. It should be less prone to accidents compared to using
log functions, which would either slow things down or still optimize the
value away (or simply move it into the if branch the log macros create).
The benefit over assert_se would be that no requirement is made on the
value itself. If we are fine getting a string of any size (including
zero), an assert_se would either create a noisy compiler warning about
conditions that would alawys be met or yet again optimize the whole
thing away.
Fixes compile error with -Dopenssl=false.
```
In file included from ../../home/watanabe/git/systemd/src/shared/pkcs11-util.h:12,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll.c:24:
../../home/watanabe/git/systemd/src/shared/openssl-util.h:56:21: error: conflicting types for ‘X509’; have ‘struct X509’
56 | typedef struct X509 X509;
| ^~~~
In file included from /usr/include/openssl/crypto.h:25,
from /usr/include/openssl/bio.h:20,
from /usr/include/openssl/asn1.h:16,
from /usr/include/openssl/ec.h:17,
from /usr/include/fido.h:10,
from ../../home/watanabe/git/systemd/src/shared/libfido2-util.h:18,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll-fido2.h:7,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll.c:6:
/usr/include/openssl/ossl_typ.h:123:24: note: previous declaration of ‘X509’ with type ‘X509’ {aka ‘struct x509_st’}
123 | typedef struct x509_st X509;
| ^~~~
```
On socket creation respect the SELinuxContext= setting of the associated
service, such that the initial created socket has the same label as the
future process accepting the connection (since w.r.t SELinux sockets
normally have the same label as the owning process).
Triggered by #24702
In most cases we refernced the concept as "initrd". Let's convert most
remaining uses of "initramfs" to "initrd" too, to stay internally
consistent.
This leaves "initramfs" only where it's relevant to explain historical
concepts or where "initramfs" is part of the API (i.e. in
/run/initramfs).
Follow-up for: b66a6e1a58
If a root hash is specified, we should be checking that it matches
the root hash in the verity signature partition, so let's not skip
processing of the verity signature partitions if a root hash is
specified.
