Fix for specific case #30393 where 4k sector luks container is created
on a 512b device. In this case the partition table needs to be 512b,
else the kernel will not be able to find the partition, and we will
have to create a loop device to translate the partition table to 4k.
Ensure we don't create a loop device on top of a physical block device.
This leads to huge performance degradation of discard operations if the
physical device does not support discard_on_zeroes.
- loop device historical semantics dictates that when the device is
discarded, it needs to return zero data on read. This can be
implemented easily on a filesystem. since fallocate zero-range
would return immediately & the holes are handled at the filesystem
level to return zero data on read.
- For a raw block device, the feature (discard_zeroes_data) depends on
the capabilities of the physical device that is exposed to the
block layer by the driver. This means that to guarantee that the loop
device stacked on a block device returns zero on discarded data,
it needs to convert discarded range into write_zero op on the block device.
https://github.com/torvalds/linux/blob/63676eefb7a026d04b51dcb7aaf54f358517a2ec/drivers/block/loop.c#L773
For example on one of my local nvme I can see the following:
cat /sys/class/block/nvme1n1/queue/write_zeroes_max_bytes
131072
cat /sys/class/block/nvme0n1/queue/discard_max_hw_bytes
2199023255040
This means maximum size of a write_zero operation can be 128KiB &
maximum size of discard operation can be 2TiB on the block device.
So discarding for example 1TB of data, which would be a single block
device operation, gets split into 8.3 million block device operations
when issued on top of stacked loop device.
If there is an explicit sector size specified in the user record,
use the same when probing the file using libblkid. The default
is 512 bytes, which will not be able to find the signatures, if the
partition table on regular file was created assuming 4k sectors
The two options are were not documented or ever used in the codebase.
Additionally, the parser expected an argumentless option, while the option
table declared a required argument. So I think this was added for debugging
and never excercised properly. Since there was no public documentation for
those, it's as if they never existed, so it should be fine to drop them.
When plymouth is enabled, the screen gets all garbled when firstboot
runs and asks questions. Disable the splash screen, but only when
actually asking questions.
The prompts asking the user to physically authenticate
or confirm presence on a security token are informational
requests for action, not error conditions.
This commit changes the message type to PAM_TEXT_INFO,
which is more appropriate for guiding the user through
the authentication process.
This is in preparation for later changes. The 1500+ line switch statement was very
hard to work with and had quite a bit of duplicated code. This is a rework that
splits outs parts into functions. I split this up into a bunch of commits so that it
can be reasonably reviewed. When viewed as one giant commit, diff just shows
a giant block of removed code and a giant block of added code.
In some cases I wasn't sure why one or the other of the identity arrays is used…
I preserved existing behaviour in all cases.
We parse RLIMIT_FOO, FOO, and LimitFOO all the same. But the keys in the
JSON dict are supposed to be "RLIMIT_FOO". We were creating such keys,
but then filtering them using "FOO", i.e. the filtering was not effective.
Using strjoina since both strings are under our control.
The idea is to split out helpers to make parse_argv() itself more
manageable. If possible, the helpers will be reused in many places. But
even if not, as in this case, it seems good to split out the code for a
specific option. Always, the sd_json_variant** pointer or pointers that
are operated on are selected in the caller. This way it is easier to see
which of the identity variables is used and if two different ones are
used.
libpam uses pamh in its function declarations for
the plugin API so let's use the same name in our
tree as well.
Making sure the plugin function definitions match
the plugin function declarations is required to
enable clang-tidy's
readability-inconsistent-declaration-parameter-name
check, but to keep things consistent everywhere we
opt to use pamh tree-wide.
Note, this drops logging only test case for crypt_preferred_method(),
as that requires explicitly dlopen() the library. But, we should test
that make_salt() and friends automatically dlopen() it.
Let's introduce these for the following two reasons:
- Using them makes sure the parameter names match between declaration
and definition (if both use the corresponding macros).
- They make sure developers can't forget the _const_ and _pure_
attributes for the declarations.
This commit also includes some include sorting fixes
We drop the optimization for verify_sigchld as the
check differs based on the options passed and the
extra syscalls are certainly not going to matter
compared to the cost of forking a child process.
Fixes#40166
Now that sd-event doesn't insist on blocking
SIGCHLD anymore when watching for process exit,
let's stop blocking SIGCHLD tree-wide where not
required anymore.
