Bug 1171065 - Dracut complains about missing crc32c module with kernel-default-base
Dracut complains about missing crc32c module with kernel-default-base
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-05-04 12:05 UTC by Fabian Vogt
Modified: 2022-07-25 12:43 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2020-05-04 12:05:53 UTC
When running mkinitrd with kernel-default-base installed, this happens:

dracut: *** Including module: suse-initrd ***
dracut-install: Failed to find module 'crc32c'
dracut: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.axJFbC/initramfs -H -N i2o_scsi --kerneldir /lib/modules/5.6.6-1-default/ -m crc32c

It's because of /etc/modprobe.d/00-system.conf:

# libcrc32c calls crypto_alloc_shash("crc32c", 0, 0), which results in a
# request_module("crc32c"), but that dependency is not seen by modpost/depmod
# https://bugzilla.novell.com/552443
# SUSE INITRD: libcrc32c REQUIRES crc32c

It's not fully clear what crc32c is and what it's used for, but I assume it's an alias provided by hardware-specific optimized implementations of crc32c. If this is the case, it would definitely fit into the set of modules provided by kernel-default-base.

Question is how this would have to be added, would mentioning crc32c work or do the actual module names need to be added in %ifarch sections?
Comment 1 Michal Suchanek 2020-05-04 12:31:53 UTC
Note that crc32c is an actual module name. But there is at least crc32c-vpmsum hardware-specific option.

It should be ok to just list all hardware-specific modules. The ones that are missing should just log a warning at package build time.

The module is used for some filesystem checksums.
Comment 2 Fabian Vogt 2020-05-04 13:00:34 UTC
(In reply to Michal Suchanek from comment #1)
> Note that crc32c is an actual module name.

At least here, "modinfo crc32c" shows crc32c-intel.ko.xz and I can't find anything with crc32c in its name. Do you mean "crc32c_generic" (which is built-in here)?

> But there is at least
> crc32c-vpmsum hardware-specific option.

I can find crc32-vx_s390 as well, so is the list of crc32c-intel, crc32c-vpmsum and crc32-vx_s390 complete?

arch/arm/crypto/crc32-ce-glue.c:MODULE_ALIAS_CRYPTO("crc32c");
arch/powerpc/crypto/crc32c-vpmsum_glue.c:MODULE_ALIAS_CRYPTO("crc32c");
arch/s390/crypto/crc32-vx.c:MODULE_ALIAS_CRYPTO("crc32c");
arch/sparc/crypto/crc32c_glue.c:MODULE_ALIAS_CRYPTO("crc32c");
arch/x86/crypto/crc32c-intel_glue.c:MODULE_ALIAS_CRYPTO("crc32c");
crypto/crc32c_generic.c:MODULE_ALIAS_CRYPTO("crc32c");

The arm one doesn't seem to be built as loadable module, so can be ignored and sparc is not supported.

Are there other modules with a similar mechanism which might be missing from kernel-default-base currently?

> It should be ok to just list all hardware-specific modules. The ones that
> are missing should just log a warning at package build time.

Ok, I'll try that.

> The module is used for some filesystem checksums.
Comment 3 Michal Suchanek 2020-05-04 14:18:21 UTC
Right, it returns the info for crc32c-intel, missed that.

We should probably include the _generic one as well. Does the -intel one wrok on AMD for one? All x64_64 CPU revisions?

It is good idea to build add the ARM module to the list in case it is modularized later.
Comment 4 Fabian Vogt 2020-05-04 14:28:07 UTC
(In reply to Michal Suchanek from comment #3)
> Right, it returns the info for crc32c-intel, missed that.
> 
> We should probably include the _generic one as well. Does the -intel one
> wrok on AMD for one? All x64_64 CPU revisions?

It uses sse4.2, so not all x86_64, but recent ones (also AMD Zen+)

> It is good idea to build add the ARM module to the list in case it is
> modularized later.

I'll do that, if you tell me how the module would be called.
Comment 5 Michal Suchanek 2020-05-04 19:16:39 UTC
Looks like it is called crc32-arm-ce
Should be in modules.builtin in the arm kernel.
Comment 6 Fabian Vogt 2020-05-05 10:31:14 UTC
(In reply to Michal Suchanek from comment #5)
> Looks like it is called crc32-arm-ce
> Should be in modules.builtin in the arm kernel.

Ok, thanks! Submitted as sr 800325.
Comment 8 Vincent Moutoussamy 2020-05-05 11:46:46 UTC
@Michal and @Qu, do you guys think that not having this module would have any impact on FS performance? We will try to check on our own build with and without it but it would be highly interesting to have your input.
Comment 9 Wenruo Qu 2020-05-05 11:53:58 UTC
(In reply to Vincent Moutoussamy from comment #8)
> @Michal and @Qu, do you guys think that not having this module would have
> any impact on FS performance? We will try to check on our own build with and
> without it but it would be highly interesting to have your input.

Never thought about the crc32c perf.

My less educated guess is, it won't bring too obvious impact for metadata operations.
But may have an observable impact on data.

For metadata, we have quite other slow routines, like tree-checker (both read and write time). So it may not be that obvious.

For data, since the amount of data is way larger than metadata, the change in csum calculation may be observable on faster storage.
Comment 10 Michal Suchanek 2020-05-05 12:23:25 UTC
crc32-arm-ce is modular on armv7 and non-existent on arm64 atm.

We had some complaints about storage performance when missing these modules but then you might want to get the t10dif crc as well.

Also it depends on the use in the filesystem/raid drivers. Some checksum *everything* and then the difference would be obvious. For others it's irrelevant.