Use dm_get_active_iname that should be used on all places.
This function return integrioty device name if it shoudl be
maintained by LUKS2 context directly.
Code must not touch other devices that it does not own.
Block devices must support direct-io. This check causes more problems
than it solves - for Opal locked device it disables direct-io
and we can later possible read wrong data (if kernel does not flush
cache).
Currently, direct-io is disabled if underlying device is suspended.
This was an unfortunate change, as it is part of data corruption
problem in online reenryption.
Let's relax the test to assume that suspended device
(suspended => must be a device-mapper device) supports direct-io.
The read test is still needed as some network based devices
misbehaves if opened with direct-io flag.
Consider device is suspended only if dm_status_suspended return code
is true.
This function returned -EEXIST for dm devices with target types unknown
to libcryptsetup (for example dm-cache) and turned off O_DIRECT flag
for devices unexpectedly.
Turned out ignoring direct-io was a problem after all :).
Fixes: 0f51b5bacb (Do not run sector read check on suspended device.)
This patch switches code to SPDX one-line license identifiers according to
https://spdx.dev/learn/handling-license-info/
and replacing long license text headers.
I used C++ format on the first line in style
// SPDX-License-Identifier: <id>
except exported libcryptsetup.h, when only C comments are used.
The only additional changes are:
- switch backend utf8.c from LGPL2+ to LGPL2.1+ (as in systemd)
- add some additional formatting lines.
Zoned device cannot be written with direct-io
and cannot be used for LUKS header logic without
significant changes. Do not allow to use them for LUKS header
but allow it for data device, as dm-crypt supports it.
Fixes: #877
This can affect status command, but later also device
stack with authenticated encryption (*_dif device).
Ignoring direct-io should not be problem here.
The logic shoudl be simplified in future anyway...
Most of these functions already works even with device=NULL.
There can be some rare situations when this call could happen,
so be safe always.
(Like initialization for a device that disappears during init.)
Also see
https://bugzilla.redhat.com/show_bug.cgi?id=1932946
crypt_header_is_detached checks if initialized LUKS context uses detached header
(LUKS header located on a different device than data.)
This is a runtime attribute, it does not say if a LUKS device requires detached header.
We can't avoid this race due to undefined behaviour if called with
O_EXCL flag on regular file.
Let's double-check fd with O_EXCL flag is actually open block device.
Atomic operation requires to hold a lock for longer period than
single metadata I/O. Update locks so that we can:
- lock a device more than once (lock ref counting)
- reaquire read lock on already held write lock (write lock
is stronger than read lock)
If any argument is null return false (with higher
priority than trivial identity check).
Also device_path can't return null if device struct gets
allocated succesfully.
