Since open-iscsi 2.1.2 [0] the initiator name should be generated via
a one-time service instead of distro package's post-install scripts.
However, some distros still use this approach even after this patch,
so prefer the already existing initiatorname.iscsi file if it exists.
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:
https://github.com/torvalds/linux/commit/146e5e733310379f51924111068f08a3af0db830,
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.
Jan Janssen [Fri, 23 Sep 2022 07:54:03 +0000 (09:54 +0200)]
fuzz: Introduce DO_NOT_OPTIMIZE
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).
dissect: Process verity sig partitions if a root hash is specified
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.
shared: Don't try to generate read-only filesystem that we don't support
We need explicit support to generate read-only filesystems, since we
always need to pass a source tree to the mkfs binary to populate the
filesystem. As such, let's add an explicit check to return a
recognizable error when users try to generate a read-only filesystem
that we don't support.
tmpfiles: whenever creating an inode, immediately O_PATH open it to pin it
let's make things a bit less racy: whenever we create an inode,
immediately open it via O_PATH, compare type and continue operations
with the acquired fd.
tmpfiles: allow prefixing uid/gid/mode with ":" to only apply on creation
In some cases it is useful to specify the access mode/uid/gid for inodes
we create without also enforcing them on existing inodes. Let's add a
new flag for that: if the uid/gid/mode specificaitons are prefixed with
":", then they only apply to creation, not otherwise.
This is specifically useful for provisioning SSH keys later. Those we'd
like to provision like this:
While /root/ + /root/.ssh/ being owned by root is pretty uncontroversial
the access mode of /root/ and /root/.ssh/ might not be. Hence we should
only have a default mode defined that is used when we create the dir,
but not otherwise.
tmpfiles: generalize CreationMode and pass it everywhere
For some purposes we had CreationMode which indicates whether an inode
was created by us, or is pre-existing. Let's generalize that for *all*
operations. This is later useful to conditionalize certain operations on
that (and makes the codebase more systematic)
udev: support by-path devlink for multipath nvme block devices
If multipath feature is enabled, nvme block devices may belong to the
"nvme-subsystem" subsystem, instead of "nvme" subsystem.
(What a confusing name...)
Then, the syspath is something like the following,
/sys/devices/virtual/nvme-subsystem/nvme-subsys0/nvme0n1
Hence, we need to find the 'real parent' device, such as
/sys/devices/pci0000:00/0000:00:1c.4/0000:3c:00.0/nvme/nvme0
Adam Williamson [Thu, 22 Sep 2022 22:08:43 +0000 (15:08 -0700)]
kbd-model-map: add a mapping for switched czech qwerty/us
See https://bugzilla.redhat.com/show_bug.cgi?id=2121106 for the
background on this. One of Fedora's QA folks ran an install
and chose two keyboard layouts: Czech (qwerty) and US. Due to
the sad details of how the whole logic flow for trying to decide
what kbd layout best matches a given xkb config works (see
details in the bug comments), we wound up deciding the best-
matching kbd layout for this situation was cz-us-qwertz, which
is a czech/us switched layout, but is qwertz, not qwerty. This
seems like a poor outcome. Adding this line should result in us
picking cz-qwerty in this case. Which may be the 'legacy'
cz-qwerty.map from upstream kbd project (which is switched
cz/us), or may be the auto-converted xkb layout (which obviously
isn't switched). But either way, at least its primary mode is
Czech qwerty, which seems like a *better* choice than a layout
whose primary mode is Czech qwertz.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
projects / thirdparty / systemd.git / log
