Bug 1874808

Summary:	btrfs should use crc32c-intel instead of crc32c-generic on a SSE4.2 processor
Product:	[Fedora] Fedora	Reporter:	Uros Bizjak <ubizjak>
Component:	kernel	Assignee:	fedora-kernel-btrfs
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	32	CC:	acaringi, airlied, bskeggs, davide, ego.cordatus, elxreno, hdegoede, ichavero, itamar, jarodwilson, jeremy, jforbes, jglisse, john.j5live, jonathan, josef, kernel-maint, lgoncalv, linville, masami256, mcatanza, mchehab, mjg59, ngompa13, steved, zawertun
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-06 12:41:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Uros Bizjak 2020-09-02 09:55:40 UTC

1. Please describe the problem:

On a SSE4.2 capable system, btrfs should use crc32c-intel, not crc32c-generic.

2. What is the Version-Release number of the kernel:

Linux version 5.8.4-200.fc32.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1), GNU ld version 2.34-4.fc32) #1 SMP Wed Aug 26 22:28:08 UTC 2020

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

This is the first version I noticed btrfs is loaded.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

$ dmesg -t | grep crc32
Btrfs loaded, crc32c=crc32c-generic

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:


6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

-- No entries --

Comment 1 Uros Bizjak 2020-10-21 11:21:31 UTC

Probably

CONFIG_CRYPTO_CRC32C_INTEL=m

should be changed to =y

because:

CONFIG_BTRFS_FS=y

Comment 2 Artem 2020-11-04 04:55:32 UTC

I have the same issue on Ryzen 3300X and Fedora 33. But it works previously on old AMD CPU in Fedora 32 so not sure when this bug striked.

$ lscpu | grep sse4_2

  SSE 4.2 available.

$ dmesg | grep crc32c

  [    0.631456] Btrfs loaded, crc32c=crc32c-generic

Users also reporting the same issue on 'Intel(R) Core(TM) i7-1065G7'. Users nuking their fresh f33 installations because of this bug and complain. That's sort of urgent bug.

Comment 3 Neal Gompa 2020-11-04 05:47:55 UTC

Josef, Justin, would switching CONFIG_CRYPTO_CRC32C_INTEL to 'y' actually resolve this issue? I'm somewhat skeptical myself...

Comment 4 Josef Bacik 2020-11-04 15:25:44 UTC

cat /sys/fs/btrfs/$(blkid info -o value -s UUID $DEVICE)/checksum

will tell you which crc we're currently using.  We just spit out whatever crypto library is currently loaded at the time, and since it can change this can be completely different later on.  If the above command doesn't spit out crc32c-intel then it still doesn't really change, because again btrfs is just calling into the crypto library, so it can change arbitrarily while the file system is loaded.  If you want to change the printk then by all means switch it to =Y, but it makes no difference practically speaking.

Comment 5 Josef Bacik 2020-11-04 15:32:22 UTC

Also, why exactly are users nuking an entire install because of the wrong crc mechanism?  We didn't have built in crc32c for a while, and while it's certainly slower, it's not mind numbingly slow, this is how it worked before and thus we have a lot of async stuff built in to make it as fast as possible.  It seems like a bit of an overreaction without first getting some clarity.

Comment 6 Artem 2020-11-04 19:48:16 UTC

(In reply to Josef Bacik from comment #5)

Josef, i've answered here https://pagure.io/fedora-btrfs/project/issue/34#comment-699687 and i can't answer for those who nuked their fresh fedora 33. Thanks for explanation and sorry for noise.

Probably need to document somehow this since Arch Wiki [1] for example still contain outdated information and other people could misinformed.

[1]: https://wiki.archlinux.org/index.php/Btrfs#Checksum_hardware_acceleration

Comment 7 Neal Gompa 2020-11-06 12:41:55 UTC

I think at this point, we can safely judge this to not be a real bug.