* [PATCH] cramfs: fix potential "unable to mount root fs" problem
@ 2021-04-22 11:06 lizhe
2021-04-22 13:23 ` Nicolas Pitre
0 siblings, 1 reply; 3+ messages in thread
From: lizhe @ 2021-04-22 11:06 UTC (permalink / raw)
To: nico, linux-kernel; +Cc: wangfangpeng1, zhongjubin, lizhe67
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 <lizhe67@huawei.com>
---
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] cramfs: fix potential "unable to mount root fs" problem
2021-04-22 11:06 [PATCH] cramfs: fix potential "unable to mount root fs" problem lizhe
@ 2021-04-22 13:23 ` Nicolas Pitre
2021-04-23 1:45 ` Zhe Li
0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Pitre @ 2021-04-22 13:23 UTC (permalink / raw)
To: lizhe; +Cc: linux-kernel, wangfangpeng1, zhongjubin
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 <lizhe67@huawei.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
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
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re:[PATCH] cramfs: fix potential "unable to mount root fs" problem
2021-04-22 13:23 ` Nicolas Pitre
@ 2021-04-23 1:45 ` Zhe Li
0 siblings, 0 replies; 3+ messages in thread
From: Zhe Li @ 2021-04-23 1:45 UTC (permalink / raw)
To: nico, viro; +Cc: linux-kernel, lizhe67, wangfangpeng1, zhongjubin
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 <lizhe67@huawei.com>
>
>Acked-by: Nicolas Pitre <nico@fluxnic.net>
>
>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
>>
>>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-04-23 1:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-22 11:06 [PATCH] cramfs: fix potential "unable to mount root fs" problem lizhe
2021-04-22 13:23 ` Nicolas Pitre
2021-04-23 1:45 ` Zhe Li
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.