2021-04-22 11:10:00

by Zhe Li

[permalink] [raw]
Subject: [PATCH] cramfs: fix potential "unable to mount root fs" problem

We may encounter panic problem without "rootfstype=" options in
bootargs. The logs are listed below.

[0.551962] RAMDISK: squashfs filesystem found at block 0
[0.551977] RAMDISK: Loading 18117KiB [1 disk] into ram disk...
[0.719465] done.
[0.748379] VFS: Cannot open root device "ram0" or unknown-block(1,0): error -92
[0.748390] Please append a correct "root=" boot option; here are the available partitions:
[0.748408] 0100 65536 ram0
[0.748413] (driver?)
[0.748430] 0101 65536 ram1
[0.748434] (driver?)
[0.748450] 0102
[0.748454] (driver?)
[0.748470] 0103 65536 ram3
[0.748475] (driver?)
[0.748498] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
[0.847579] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0 #68
[0.847598] Call trace:
[0.847616] dump_backtrace+0x0/0x1f8
[0.847627] show_stack+0x30/0x40
[0.847638] dump_stack+0xdc/0x13c
[0.847650] panic+0x144/0x35c
[0.847665] mount_block_root+0x2c0/0x36c
[0.847676] mount_root+0x7c/0x90
[0.847686] prepare_namespace+0x178/0x188
[0.847697] kernel_init_freeable+0x220/0x28c
[0.847708] kernel_init+0x1c/0xf8
[0.847719] ret_from_fork+0x10/0x30

If we set CONFIG_CRAMFS_MTD and CONFIG_CRAMFS_BLOCKDEV to n,
CONFIG_CRAMFS to y, function cramfs_get_tree return -ENOPROTOOPT,
which breaks loops in function mount_block_root and we have no
chance to try other filesystem type. In my opinion, ENOPROTOOPT
is not an appropriate return value for cramfs mount function, so
change it to EINVAL.

Fixes: 99c18ce58 (cramfs: direct memory access support)
Signed-off-by: lizhe <[email protected]>
---
fs/cramfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 2be6526..9942955 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -951,7 +951,7 @@ static const struct super_operations cramfs_ops = {

static int cramfs_get_tree(struct fs_context *fc)
{
- int ret = -ENOPROTOOPT;
+ int ret = -EINVAL;

if (IS_ENABLED(CONFIG_CRAMFS_MTD)) {
ret = get_tree_mtd(fc, cramfs_mtd_fill_super);
--
2.7.4


2021-04-22 13:25:02

by Nicolas Pitre

[permalink] [raw]
Subject: Re: [PATCH] cramfs: fix potential "unable to mount root fs" problem

On Thu, 22 Apr 2021, lizhe wrote:

> We may encounter panic problem without "rootfstype=" options in
> bootargs. The logs are listed below.
>
> [0.551962] RAMDISK: squashfs filesystem found at block 0
> [0.551977] RAMDISK: Loading 18117KiB [1 disk] into ram disk...
> [0.719465] done.
> [0.748379] VFS: Cannot open root device "ram0" or unknown-block(1,0): error -92
> [0.748390] Please append a correct "root=" boot option; here are the available partitions:
> [0.748408] 0100 65536 ram0
> [0.748413] (driver?)
> [0.748430] 0101 65536 ram1
> [0.748434] (driver?)
> [0.748450] 0102
> [0.748454] (driver?)
> [0.748470] 0103 65536 ram3
> [0.748475] (driver?)
> [0.748498] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> [0.847579] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0 #68
> [0.847598] Call trace:
> [0.847616] dump_backtrace+0x0/0x1f8
> [0.847627] show_stack+0x30/0x40
> [0.847638] dump_stack+0xdc/0x13c
> [0.847650] panic+0x144/0x35c
> [0.847665] mount_block_root+0x2c0/0x36c
> [0.847676] mount_root+0x7c/0x90
> [0.847686] prepare_namespace+0x178/0x188
> [0.847697] kernel_init_freeable+0x220/0x28c
> [0.847708] kernel_init+0x1c/0xf8
> [0.847719] ret_from_fork+0x10/0x30
>
> If we set CONFIG_CRAMFS_MTD and CONFIG_CRAMFS_BLOCKDEV to n,
> CONFIG_CRAMFS to y, function cramfs_get_tree return -ENOPROTOOPT,
> which breaks loops in function mount_block_root and we have no
> chance to try other filesystem type. In my opinion, ENOPROTOOPT
> is not an appropriate return value for cramfs mount function, so
> change it to EINVAL.
>
> Fixes: 99c18ce58 (cramfs: direct memory access support)
> Signed-off-by: lizhe <[email protected]>

Acked-by: Nicolas Pitre <[email protected]>

Please send this to Al Viro for merging.


> ---
> fs/cramfs/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 2be6526..9942955 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -951,7 +951,7 @@ static const struct super_operations cramfs_ops = {
>
> static int cramfs_get_tree(struct fs_context *fc)
> {
> - int ret = -ENOPROTOOPT;
> + int ret = -EINVAL;
>
> if (IS_ENABLED(CONFIG_CRAMFS_MTD)) {
> ret = get_tree_mtd(fc, cramfs_mtd_fill_super);
> --
> 2.7.4
>
>

2021-04-23 01:46:18

by Zhe Li

[permalink] [raw]
Subject: Re:[PATCH] cramfs: fix potential "unable to mount root fs" problem

On Thu, 22 Apr 2021, Pitre wrote:
>On Thu, 22 Apr 2021, lizhe wrote:
>
>> We may encounter panic problem without "rootfstype=" options in
>> bootargs. The logs are listed below.
>>
>> [0.551962] RAMDISK: squashfs filesystem found at block 0
>> [0.551977] RAMDISK: Loading 18117KiB [1 disk] into ram disk...
>> [0.719465] done.
>> [0.748379] VFS: Cannot open root device "ram0" or unknown-block(1,0): error -92
>> [0.748390] Please append a correct "root=" boot option; here are the available partitions:
>> [0.748408] 0100 65536 ram0
>> [0.748413] (driver?)
>> [0.748430] 0101 65536 ram1
>> [0.748434] (driver?)
>> [0.748450] 0102
>> [0.748454] (driver?)
>> [0.748470] 0103 65536 ram3
>> [0.748475] (driver?)
>> [0.748498] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
>> [0.847579] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0 #68
>> [0.847598] Call trace:
>> [0.847616] dump_backtrace+0x0/0x1f8
>> [0.847627] show_stack+0x30/0x40
>> [0.847638] dump_stack+0xdc/0x13c
>> [0.847650] panic+0x144/0x35c
>> [0.847665] mount_block_root+0x2c0/0x36c
>> [0.847676] mount_root+0x7c/0x90
>> [0.847686] prepare_namespace+0x178/0x188
>> [0.847697] kernel_init_freeable+0x220/0x28c
>> [0.847708] kernel_init+0x1c/0xf8
>> [0.847719] ret_from_fork+0x10/0x30
>>
>> If we set CONFIG_CRAMFS_MTD and CONFIG_CRAMFS_BLOCKDEV to n,
>> CONFIG_CRAMFS to y, function cramfs_get_tree return -ENOPROTOOPT,
>> which breaks loops in function mount_block_root and we have no
>> chance to try other filesystem type. In my opinion, ENOPROTOOPT
>> is not an appropriate return value for cramfs mount function, so
>> change it to EINVAL.
>>
>> Fixes: 99c18ce58 (cramfs: direct memory access support)
>> Signed-off-by: lizhe <[email protected]>
>
>Acked-by: Nicolas Pitre <[email protected]>
>
>Please send this to Al Viro for merging.

Hi Viro, please review my patch. Thank you.

>
>> ---
>> fs/cramfs/inode.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
>> index 2be6526..9942955 100644
>> --- a/fs/cramfs/inode.c
>> +++ b/fs/cramfs/inode.c
>> @@ -951,7 +951,7 @@ static const struct super_operations cramfs_ops = {
>>
>> static int cramfs_get_tree(struct fs_context *fc)
>> {
>> - int ret = -ENOPROTOOPT;
>> + int ret = -EINVAL;
>>
>> if (IS_ENABLED(CONFIG_CRAMFS_MTD)) {
>> ret = get_tree_mtd(fc, cramfs_mtd_fill_super);
>> --
>> 2.7.4
>>
>>