EXT4 and CONFIG_CRYPTO_DEV_STM32_CRC incompatible ?

[anthony.harivel.emtrion.GmbH]

Hi all,

I would like to know if someone is experiencing the same issue as me.

I've got a custom STM32MP157CAC dev board and everything is working fine until I enable the HW crypto in the Linux Kernel and I want to mount a EXT4 FS. (EXT2 is ok but as no CRC/HASH checksum...)

My Linux Kernel is based on v4.19-stm32mp branch from ST. The crypto HW accelration is working because I can run some OpenSSL test with cryptodev and AF_ALG.

But I've got this issue when I try to mount a perfectly working EXT4 formatted USB Mass Storage:

# mount /dev/sda1 /media/

[ 391.163006] ------------[ cut here ]------------

[ 391.166155] kernel BUG at fs/ext4/ext4.h:2038!

[ 391.170589] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM

[ 391.176413] Modules linked in:

[ 391.179463] CPU: 0 PID: 153 Comm: mount Not tainted 4.19.94 #1

[ 391.185281] Hardware name: STM32 (Device Tree Support)

[ 391.190428] PC is at ext4_superblock_csum+0x84/0x90

[ 391.195289] LR is at ext4_fill_super+0x9fc/0x369c

[ 391.199978] pc : [<c02a3afc>]  lr : [<c02a8574>]  psr: 200f0013

[ 391.206238] sp : d2329c50 ip : d3733900 fp : d2058400

[ 391.211454] r10: d29e0080 r9 : d2135c00 r8 : c0a04c2c

[ 391.216671] r7 : c0856260 r6 : d2135c00 r5 : d2135800 r4 : 1d2721e2

[ 391.223192] r3 : d3733840 r2 : 00000008 r1 : d2058400 r0 : d2135800

[ 391.229714] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none

[ 391.236843] Control: 10c5387d Table: d223806a DAC: 00000051

[ 391.242587] Process mount (pid: 153, stack limit = 0x84e3eeab)

[ 391.248407] Stack: (0xd2329c50 to 0xd232a000)

[ 391.252759] 9c40:                   d36d1a40 00000000 d2329c84 c06f6144

[ 391.260934] 9c60: 00000000 c0a04c08 d2328000 c0a03148 d2329ce0 c06f6eb8 00000002 00000000

[ 391.269109] 9c80: d2329c94 c06f64a4 c0a25680 c02fddd0 c0a25680 c02fe064 00000001 c0718cdc

[ 391.277283] 9ca0: 0000000e 0000200f c07f8b1c 0000200f 00000000 d29e0080 d2329cc0 c01e21f0

[ 391.285457] 9cc0: 00000040 c0718cdc c0a25680 c07f8b1c d2328000 c0a25680 d29e0080 c02fdf00

[ 391.293630] 9ce0: c0718cdc 00000000 00000000 c07f8b1c d2328000 c02fe704 00000000 d2135800

[ 391.301804] 9d00: d2135c00 c0856260 c0a04c2c c0a04c08 1d2721e2 c02a8574 00000400 00000000

[ 391.309977] 9d20: d2329d7c 00000bb8 00000000 d29e3cc0 00000001 00000000 00000000 00000000

[ 391.318150] 9d40: 00000001 00000000 00000001 d2329dc0 d20c4210 d20c4200 d20c4200 c0a1bd00

[ 391.326324] 9d60: d372d800 c04575a0 00000000 d372d800 d2329dc8 c04578f8 00000083 00000000

[ 391.334497] 9d80: 00000000 c0a04c08 d2329de0 d20aff00 d20aff00 c0328af0 00000001 00000000

[ 391.342670] 9da0: 00000001 00000000 ffffffff 00000000 00000000 00000000 00000000 00004003

[ 391.350843] 9dc0: 0000016e 0000016f 00000001 00000031 00000000 00000068 00000004 c01bbf7c

[ 391.359016] 9de0: d2135a58 c0a04c08 d2135a78 d2135a5b d2812200 d2135a78 d2135003 00000001

[ 391.367189] 9e00: d213500c d2329e7c c0773724 c06f46e4 ffffff05 ffff0a00 00000003 d2135a58

[ 391.375362] 9e20: d2135a78 c07f0b5e d2329ec8 00000002 d2135a78 c06f49c0 d2329e40 ffffff05

[ 391.383535] 9e40: ffff0a00 c0a53f5c c0a0fc40 d2135a58 c0a0e820 c0a04c08 d2135800 d2135a58

[ 391.391707] 9e60: c07f0b5c c06f4edc ffffff05 ffff0a00 d2135a58 00000020 3b9aca00 ffffff05

[ 391.399879] 9e80: ffff0a00 c0a04c08 c0a0fc40 d2812200 d2135800 d2812270 00008000 c0a04c08

[ 391.408051] 9ea0: 00000000 d2812200 d2135800 d2812270 00008000 00000083 00000000 00000020

[ 391.416223] 9ec0: 00008000 c01efd60 d2812200 006000c0 d2332480 c02a35d0 d2332480 c0a0fc40

[ 391.424396] 9ee0: 00000000 c0a0fc40 d2332440 c02a35e8 c02a7b78 c0a0fc40 d2332440 c01f05f8

[ 391.432569] 9f00: 00008000 c020c678 d324dd00 d2332480 00008000 c020d438 c0a0fc40 00000020

[ 391.440740] 9f20: d2332480 00000000 00000000 c020f998 00000000 c0a04c08 d216bb48 000d5b10

[ 391.448912] 9f40: 0000000a d324d810 d29f1ee0 d2332480 0000000a 00000000 0000000a c0a04c08

[ 391.457084] 9f60: 0000000a d2332440 00000000 00008000 d2332480 be80af63 d2328000 00000015

[ 391.465257] 9f80: 000be6a0 c021075c 00000000 000d51a0 00000000 be80ac90 00000000 00000015

[ 391.473430] 9fa0: c0101204 c0101000 00000000 be80ac90 be80af59 be80af63 000d5b10 00008000

[ 391.481602] 9fc0: 00000000 be80ac90 00000000 00000015 00000000 000be56c b6f50070 000be6a0

[ 391.489773] 9fe0: b6ead771 be80ab80 0006235c b6ead77a 800e0030 be80af59 00000000 00000000

[ 391.497961] [<c02a3afc>] (ext4_superblock_csum) from [<c02a8574>] (ext4_fill_super+0x9fc/0x369c)

[ 391.506735] [<c02a8574>] (ext4_fill_super) from [<c01efd60>] (mount_bdev+0x164/0x190)

[ 391.514557] [<c01efd60>] (mount_bdev) from [<c02a35e8>] (ext4_mount+0x18/0x20)

[ 391.521773] [<c02a35e8>] (ext4_mount) from [<c01f05f8>] (mount_fs+0x14/0xa8)

[ 391.528819] [<c01f05f8>] (mount_fs) from [<c020d438>] (vfs_kern_mount.part.0+0x48/0xe8)

[ 391.536815] [<c020d438>] (vfs_kern_mount.part.0) from [<c020f998>] (do_mount+0x194/0xc04)

[ 391.544983] [<c020f998>] (do_mount) from [<c021075c>] (ksys_mount+0x88/0xb4)

[ 391.552026] [<c021075c>] (ksys_mount) from [<c0101000>] (ret_fast_syscall+0x0/0x54)

[ 391.559667] Exception stack(0xd2329fa8 to 0xd2329ff0)

[ 391.564716] 9fa0:          00000000 be80ac90 be80af59 be80af63 000d5b10 00008000

[ 391.572891] 9fc0: 00000000 be80ac90 00000000 00000015 00000000 000be56c b6f50070 000be6a0

[ 391.581059] 9fe0: b6ead771 be80ab80 0006235c b6ead77a

[ 391.586107] Code: e5940040 1a000003 e28dd0c0 e8bd8010 (e7f001f2) 

[ 391.592187] ---[ end trace 573193403597d000 ]---

Segmentation fault

# 

Any help would be appreciated.

EDIT:

the error is localised here :

/fs/etx4.h : in the ext4_chksum() function, this:

BUG_ON(crypto_shash_descsize(sbi->s_chksum_driver)!=sizeof(desc.ctx));

creates the Kernel oops.

My test shows:

[  21.863259] ext4_chksum... desc: 8, size: 4

EDIT2:

By doing so: cat /proc/crypto

I've got twice CRC32C :

 name     : crc32c

driver    : stm32-crc32

module    : kernel

priority   : 200

refcnt    : 2

selftest   : passed

internal   : no

type     : shash

blocksize  : 1

digestsize  : 4

name     : crc32c

driver    : crc32c-generic

module    : kernel

priority   : 100

refcnt    : 1

selftest   : passed

internal   : no

type     : shash

blocksize  : 1

digestsize  : 4

Knowing that in /fs/super.c :

/* Load the checksum driver */

sbi->s_chksum_driver = crypto_alloc_shash("crc32c", 0, 0);

Would that not be my problem ?

EDIT3:

# mount /dev/sda1 /media/

[ 163.212987] check for algo...

[ 163.214486] Load the checksum driver

[ 163.218059] ALG: cra_driver_name: stm32-crc32

[ 163.218066] Check superblock checksum

[ 163.226082] ext4_superblock_csum_verify...

[ 163.230126] ext4_superblock_csum...

[ 163.233659] ext4_chksum... desc: 8, size: 4 

[ 163.237883] ------------[ cut here ]------------

[ 163.242468] kernel BUG at fs/ext4/ext4.h:2040!

No I'm using the right one. No I need to understand what's wrong.

EDIT4:

Basically the stm32-crc32 driver is not compatible with EXT4 filesystem.

-> [  24.188222] ext4_chksum: stm32-crc32 desc, 8 should be equal to size, 4

in driver/crypto/stm32-crc32.c the struct of the context is not compatible with pretty much all CRC32 driver.

While all other crc32 drivers have :

.descsize = sizeof(u32)

stm32-crc32.c have :

.descsize = sizeof(struct stm32_crc_desc_ctx)

and the struct is :

struct stm32_crc_desc_ctx {

u32  partial; /* crc32c: partial in first 4 bytes of that struct */

struct stm32_crc *crc;

};

Thanks

Best Regards,

Anthony

[anthony.harivel.emtrion.GmbH]

Hi ST team,

Can anyone please tell me if you are looking at the bug, if I'm totally wrong,etc... Just for me to know what should I do next.

Thanks and take care,

Anthony

[Bernard PUEL]

Hello Anthony,

You are completely right and ST CRC driver needs to be reworked.

By the way, i understand SW CRC is working well so you should have a workaround for short term. Is it also your view (to make sure we are processing it with the right priority) ?

[anthony.harivel.emtrion.GmbH]

Hello Bernard,

Thanks for your answer! Yes, we can work with SW CRC, it's working completly fine. But the requirements of the project I'm going to work on specified HW CRC.

I just need an official answer from ST that tells the ST team is going to work on this bug and if it will be available in short or long term ?

Best regards,

Anthony

[Bernard PUEL]

It will be short term for sure, depending on upstream priority this can change so i will confirm with dev team first and let you know.

[anthony.harivel.emtrion.GmbH]

Thank you Bernard !

Stay safe, you and the whole ST team !

Anthony

[Bernard PUEL]

Thanks Anthony !! you too ...

Internal implementation has been privileged so correction will be part of V2.0.0 and also on V1.2.x github.

So very soon indeed ....

[Bernard PUEL]

Hello Anthony, correction was done and validated on the V2.0.0 release candidate internal release. We would like to upstream first before backporting on V1 public branch (to get something validated by the community).

Validation was longer than expected ....

[anthony.harivel.emtrion.GmbH]

Hello Bernard, no problem that sounds good to me. if you want me to perform some test in order to validate as well the patch, I'll be gald to do it. You can send me a patch or indicate me where I can find it.

[anthony.harivel.emtrion.GmbH]

Hello @Bernard PUEL​  any news on the above Patch or Release ? I monitor the github but see no Patch about this...

Thanks !

Anthony

[Bernard PUEL]

Hello Anthony, situation did not changed. The discussion with the community is still on going and we could not have it for the latest 4.19 release. As this 4.19 release is in maintenance, we would like to push the correction after it is validated by the community (to get a stable and agreed implementation).

5.4 Release with the correction will be delivered in a couple of weeks, packaging and final validations done internally.

How could I help you ? Do you want a temporary patch or the patch from 5.4 ? or wait a bit ....