| Message ID | 20220825084138.1881954-3-cuigaosheng1@huawei.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | A few fixup patches for crypto | expand |
On Thu, Aug 25, 2022 at 04:41:38PM +0800, Gaosheng Cui wrote: > The CRYPTO_CRC32C is using functions provided by CRYPTO_MANAGER, > otherwise the following error will occur: > > EXT4-fs (mmcblk0): Cannot load crc32c driver. > > So select CRYPTO_MANAGER when enable CRYPTO_CRC32C. > > Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> > --- > crypto/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index b1ccf873779d..7f124604323b 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -641,6 +641,7 @@ config CRYPTO_CRC32C > tristate "CRC32c CRC algorithm" > select CRYPTO_HASH > select CRC32 > + select CRYPTO_MANAGER > help > Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used > by iSCSI for header and data digests and by others. Why exactly does it need CRYPTO_MANAGER? Cheers,
Thanks for your reply.
While I was debugging the kernel code of linux-next, I start the kernel
with qemu-system-arm with following commands:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- vexpress_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j32
qemu-system-arm -M vexpress-a9 -m 1024M -s -nographic -kernel arch/arm/boot/zImage \
-dtb arch/arm/boot/dts/vexpress-v2p-ca9.dtb -sd /home/rootfs.sd \
-append "root=/dev/mmcblk0 rw console=ttyAMA0"
But it failed, so I tried to locate the cause of the failure and finally found that
it failed from this patch(cad439fc040e crypto: api - Do not create test larvals if manager is disabled)，
logs as follows:
> EXT4-fs (mmcblk0): Cannot load crc32c driver. VFS: Cannot open root
> device "mmcblk0" or unknown-block(179,0): error -80 Please append a
> correct "root=" boot option; here are the available partitions: 1f00
> 131072 mtdblock0 (driver?) 1f01 32768 mtdblock1 (driver?) b300 32768
> mmcblk0 driver: mmcblk Kernel panic - not syncing: VFS: Unable to
> mount root fs on unknown-block(179,0) CPU: 0 PID: 1 Comm: swapper/0
> Not tainted 5.15.0-rc1+ #1 Hardware name: ARM-Versatile Express
> [<8010f334>] (unwind_backtrace) from [<8010b08c>]
> (show_stack+0x10/0x14) [<8010b08c>] (show_stack) from [<8083f2a4>]
> (dump_stack_lvl+0x40/0x4c) [<8083f2a4>] (dump_stack_lvl) from
> [<8083b210>] (panic+0xf8/0x2f4) [<8083b210>] (panic) from [<80b0175c>]
> (mount_block_root+0x178/0x200) [<80b0175c>] (mount_block_root) from
> [<80b01bac>] (prepare_namespace+0x150/0x18c) [<80b01bac>]
> (prepare_namespace) from [<8084384c>] (kernel_init+0x10/0x124)
> [<8084384c>] (kernel_init) from [<80100130>] (ret_from_fork+0x14/0x24)
> Exception stack(0x8108bfb0 to 0x8108bff8) bfa0: ???????? ????????
> ???????? ???????? bfc0: ???????? ???????? ???????? ???????? ????????
> ???????? ???????? ???????? bfe0: ???????? ???????? ???????? ????????
> ???????? ???????? ---[ end Kernel panic - not syncing: VFS: Unable to
> mount root fs on unknown-block(179,0) ]---
In the patch, crypto_alloc_test_larval will return NULL if CONFIG_CRYPTO_MANAGER disabled, so
I checked to see if this change was the cause "EXT4-fs (mmcblk0): Cannot load crc32c driver
", the success logs does not have this error.
When I enabled CONFIG_CRYPTO_MANAGER, kernel can be boot successfully.
Could that be the reason? I would be very grateful if you could give me some advice.
Thanks very much!
在 2022/8/25 16:50, Herbert Xu 写道:
> On Thu, Aug 25, 2022 at 04:41:38PM +0800, Gaosheng Cui wrote:
>> The CRYPTO_CRC32C is using functions provided by CRYPTO_MANAGER,
>> otherwise the following error will occur:
>>
>> EXT4-fs (mmcblk0): Cannot load crc32c driver.
>>
>> So select CRYPTO_MANAGER when enable CRYPTO_CRC32C.
>>
>> Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
>> ---
>> crypto/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index b1ccf873779d..7f124604323b 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -641,6 +641,7 @@ config CRYPTO_CRC32C
>> tristate "CRC32c CRC algorithm"
>> select CRYPTO_HASH
>> select CRC32
>> + select CRYPTO_MANAGER
>> help
>> Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used
>> by iSCSI for header and data digests and by others.
> Why exactly does it need CRYPTO_MANAGER?
>
> Cheers,
On Thu, Aug 25, 2022 at 08:55:12PM +0800, cuigaosheng wrote: > Thanks for your reply. > > While I was debugging the kernel code of linux-next, I start the kernel > with qemu-system-arm with following commands: > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- vexpress_defconfig > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j32 > qemu-system-arm -M vexpress-a9 -m 1024M -s -nographic -kernel arch/arm/boot/zImage \ > -dtb arch/arm/boot/dts/vexpress-v2p-ca9.dtb -sd /home/rootfs.sd \ > -append "root=/dev/mmcblk0 rw console=ttyAMA0" > > But it failed, so I tried to locate the cause of the failure and finally found that > it failed from this patch(cad439fc040e crypto: api - Do not create test larvals if manager is disabled)， > logs as follows: > > EXT4-fs (mmcblk0): Cannot load crc32c driver. VFS: Cannot open root > > device "mmcblk0" or unknown-block(179,0): error -80 Please append a > > correct "root=" boot option; here are the available partitions: 1f00 > > 131072 mtdblock0 (driver?) 1f01 32768 mtdblock1 (driver?) b300 32768 > > mmcblk0 driver: mmcblk Kernel panic - not syncing: VFS: Unable to mount > > root fs on unknown-block(179,0) CPU: 0 PID: 1 Comm: swapper/0 Not > > tainted 5.15.0-rc1+ #1 Hardware name: ARM-Versatile Express [<8010f334>] > > (unwind_backtrace) from [<8010b08c>] (show_stack+0x10/0x14) [<8010b08c>] > > (show_stack) from [<8083f2a4>] (dump_stack_lvl+0x40/0x4c) [<8083f2a4>] > > (dump_stack_lvl) from [<8083b210>] (panic+0xf8/0x2f4) [<8083b210>] > > (panic) from [<80b0175c>] (mount_block_root+0x178/0x200) [<80b0175c>] > > (mount_block_root) from [<80b01bac>] (prepare_namespace+0x150/0x18c) > > [<80b01bac>] (prepare_namespace) from [<8084384c>] > > (kernel_init+0x10/0x124) [<8084384c>] (kernel_init) from [<80100130>] > > (ret_from_fork+0x14/0x24) Exception stack(0x8108bfb0 to 0x8108bff8) > > bfa0: ???????? ???????? ???????? ???????? bfc0: ???????? ???????? > > ???????? ???????? ???????? ???????? ???????? ???????? bfe0: ???????? > > ???????? ???????? ???????? ???????? ???????? ---[ end Kernel panic - not > > syncing: VFS: Unable to mount root fs on unknown-block(179,0) ]--- > > In the patch, crypto_alloc_test_larval will return NULL if CONFIG_CRYPTO_MANAGER disabled, so > I checked to see if this change was the cause "EXT4-fs (mmcblk0): Cannot load crc32c driver > ", the success logs does not have this error. > > When I enabled CONFIG_CRYPTO_MANAGER, kernel can be boot successfully. > > Could that be the reason? I would be very grateful if you could give me some advice. Can you please provide the whole .config file? Thanks,
diff --git a/crypto/Kconfig b/crypto/Kconfig index b1ccf873779d..7f124604323b 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -641,6 +641,7 @@ config CRYPTO_CRC32C tristate "CRC32c CRC algorithm" select CRYPTO_HASH select CRC32 + select CRYPTO_MANAGER help Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used by iSCSI for header and data digests and by others.
The CRYPTO_CRC32C is using functions provided by CRYPTO_MANAGER, otherwise the following error will occur: EXT4-fs (mmcblk0): Cannot load crc32c driver. So select CRYPTO_MANAGER when enable CRYPTO_CRC32C. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> --- crypto/Kconfig | 1 + 1 file changed, 1 insertion(+)