[Devel] [PATCH RHEL9 COMMIT] fs/fuse: pcs: force use of crc32c-intel

[Konstantin Khorenko]

The commit is pushed to "branch-rh9-5.14.0-362.8.1.vz9.35.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh9-5.14.0-362.8.1.vz9.35.16
------>
commit 647f02059735d22f480b3abc569c136d76333a41
Author: Alexey Kuznetsov <kuznet at virtuozzo.com>
Date:   Wed Mar 27 23:02:42 2024 +0800

    fs/fuse: pcs: force use of crc32c-intel
    
    This is workaround, we try to load crc32c-intel tfm explicitly.
    And when it is present (and it is), it will be used. It is enough
    for now.
    
    Nevertheless, this small patch deserves some comments.
    I see this as a probem to be solved.
    
    The problem is that at time when fuse module is loaded module
    crc32c-intel is not, so fuse uses very slow default crc implementation.
    I do not know any good solution to this. We cannot add an explicit
    dependency, as the platform might not support this, or the module
    crc32c-intel could be disabled intentionally due to some bugs
    in software/hardware. From the other hand normally nobody wants
    to use compat crc when good one is available. And actually it is
    not our business what crypto module to use, it must be decided
    at other level, not us.
    BTW /proc/crypto shows there is some other victim, I see one more
    user of bad crc module.
    
    Also, investigation showed other pathologies in virtuozzo startup,
    which are to be solved this way of another.
    
    1. fuse is put to initrd. I have no idea why dracut does this,
    but this is entirely insane as user space required for fuse is still
    unavailable. Actually, this is kind of reason why the issue with crc
    is triggered, fuse is loaded essentially as the first priority module
    like disk driver or ext4 before everything else. Come on!
    
    2. kdump does not work while boot until it enters multiuser mode.
    IMHO, this is critical bug. This means that virtuozzo cannot catch,
    report or debug any kernel problem which happens before bootup
    is complete. I guess this insanity came from redhat which did this
    because kdump can be enabled to push dumps to network filesystems.
    Yet this does not mean this can be left in this state.
    
    https://pmc.acronis.work/browse/VSTOR-83607
    
    Signed-off-by: Alexey Kuznetsov <kuznet at acronis.com>
    
    Feature: vStorage
---
 fs/fuse/kio/pcs/pcs_fuse_kdirect.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/fuse/kio/pcs/pcs_fuse_kdirect.c b/fs/fuse/kio/pcs/pcs_fuse_kdirect.c
index 566dcb5f2f4c..0c6938dc14fd 100644
--- a/fs/fuse/kio/pcs/pcs_fuse_kdirect.c
+++ b/fs/fuse/kio/pcs/pcs_fuse_kdirect.c
@@ -1931,7 +1931,9 @@ static int __init kpcs_mod_init(void)
 
 	fuse_trace_root = debugfs_create_dir("fuse", NULL);
 
-	crc_tfm = crypto_alloc_shash("crc32c", 0, 0);
+	crc_tfm = crypto_alloc_shash("crc32c-intel", 0, 0);
+	if (!crc_tfm || IS_ERR(crc_tfm))
+		crc_tfm = crypto_alloc_shash("crc32c", 0, 0);
 	if (IS_ERR(crc_tfm))
 		crc_tfm = NULL;