On 24 August 2018 at 17:29, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > Ard, > >> Would it be possible to allocate the crypto transform upon first use >> instead of from an initcall? If crc_t10dif() is mostly called from >> non-process context, that would not really work, but otherwise, we >> could simply defer it (and occasional calls from non-process context >> that do occur would use the generic code until the point where another >> call from process context allocates the transform) > > The function is always called from user context. However, postponing the > crypto transform registration doesn't solve the common scenario of the > user booting off of a Fibre Channel/SAS/NVMe device with the desired > crct10dif-pclmul.ko module located on the boot drive. > > If there is no good way to teach crypto to update existing registrations > when a higher priority transformation becomes available, then we > probably need to explore tweaking dracut to unconditionally load > crct10dif-pclmul (and your ARM equivalent). Looks like there are already > hacks in place in dracut to preload crc32c for btrfs and XFS. > I'd prefer to handle this without help from userland. It shouldn't be too difficult to register a module notifier that only sets a flag (or the static key, even?), and to free and re-allocate the crc_t10dif transform if the flag is set. > Anyway. Just seems like the kernel is violating the principle of least > surprise here. The kernel should always pick the best available tool for > the job... > > -- > Martin K. Petersen Oracle Linux Engineering
