Decrease devlink priority for encrypted partitions, and make the priority for
decrypted DM devices relatively higher. This is for the case that an encrypted
partition and its decrypted DM device have the same label.
Fixes
| ../git/src/basic/user-util.c:708:30: error: use of undeclared identifier 'LOCK_EX'; did you mean 'LOCK_BSD'?
| 708 | r = unposix_lock(fd, LOCK_EX);
| | ^~~~~~~
| | LOCK_BSD
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This is clearly a change that can break existing units, and broke my
system in at least two different ways. For this reason this should have
been added to NEWS in #26458, specifically c2da3bf, but wasn't.
Otherwise, it also matches later created virtual devices, and that
breaks networks generated and managed by container management services,
like docker.
Closes#28626.
We were running systemd-measure before adding the sbat section,
let's fix that.
Also make sure we only pass --linux to systemd-measure once instead
of twice.
Previously, we first generate names based on the PCI slot and ACPI
onboard index, and then append an identifier based on USB or BCMA bus
if it exists in between the PCI bus and the interface.
However, if there exists USB or BCMA bus, the name based on the
ACPI onboard index is not used.
So, let's invert the order; first generate USB or BCMA identifier if the
bus exists, then prepend the name with the PCI slot identifier.
With this change, we can drop Names struct, and each naming logic
becomes self-consistent.
Then call it only when it is necessary. The label is used only when the
interface is directly connected to the PCI bus, and it does not have the
SR-IOV feature (or the naming based on SR-IOV is disabled).
This contains redundant copy of BCMA identifier, but that will be
dropped in the next commit.
No functional change, just refactoring and preparation for later
commits.
This contains redundant copy of USB identifier, but that will be
dropped in the next commit.
No functional change, just refactoring and preparation for later
commits.
manager_{get|set|override}_watchdog check the validity of the new
timeout or the overridden timeout values using timestamp_is_set which
does not recognize "0" as a valid value. However since f16890f, "0"
indicates a disabled watchdog and so is a value we should be able to
configure in order to disable the watchdog. A value of USEC_INFINITY is
considered a no-op. The behavior should be the same for all watchdog
timeout configurations (runtime, pretimeout, and shutdown).
Private mappings are required when F_SEAL_WRITE is set on a memfd,
because otherwise you could end up with writable mappings through
mprotect() and other calls. This is a limitation of the kernel
implementation, and might be lifted by future extensions.
Regardless, the current code tests for the full `is_sealed()` before
using MAP_PRIVATE. This might end up using MAP_SHARED for write-sealed
memfds, which will be refused by the kernel.
Fix this and make memfd_map() check for exactly `F_SEAL_WRITE`.
Rather than always setting all seals, make `memfd_set_seals()` employ
the original set of seals, that is: SEAL+GROW+SHRINK+WRITE
Historically, the memfd code was used with the out-of-tree memfd
patches, which merely supported a single seal ("SEALED", which
effectively was GROW+SHRINK+WRITE). When the code was adapted to the
upstream memfd seals, it was extended to the full seal set. With more
and more seals being added upstream, this because more problematic. In
particular, it is unclear what the function really is meant to achieve.
Instead of just adding all seals, the function is returned to its
original purpose: seal the memfd so futher modifications to its content
are prevented.
With `F_SEAL_SEAL` a memfd can disable further sealing operations,
effectively sealing the set of seals. Testing for it ensures that no
further seals can be added, it never prevents seals from being dropped,
since seals cannot be dropped, ever.
Now testing for `F_SEAL_SEAL` makes sense if you want to ensure that
some seals are *not* set. That is, you either test for the entire set of
seals to match a local set, or you verify that a specific seal is not
set. Neither is what we are doing, so it feels wrong requiring it to be
set.
By dropping the requirement for `F_SEAL_SEAL`, the same FD can be shared
with other entities while retaining the ability to further restrict the
set of seals later on (e.g., being able to mark a region as executable
later on, and then adding `F_SEAL_EXEC`).
