WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 418baf2c Linux 5.10-rc5
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=171555b9500000
kernel config: https://syzkaller.appspot.com/x/.config?x=b81aff78c272da44
dashboard link: https://syzkaller.appspot.com/bug?extid=3fd34060f26e766536ff
compiler: gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3fd340...@syzkaller.appspotmail.com

BFS-fs: bfs_fill_super(): loop5 is unclean, continuing
BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway
BFS-fs: bfs_fill_super(): Last block not available on loop5: 120
BFS-fs: bfs_fill_super(): loop5 is unclean, continuing
BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway
BFS-fs: bfs_fill_super(): Last block not available on loop5: 120


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[Randy Dunlap]

Hi,
Can you provide the BFS image file that is being mounted?
(./file0 I think.)

--
~Randy

[Dmitry Vyukov]

Hi Randy,

I see this bug was reported with a reproducer:
https://syzkaller.appspot.com/bug?id=a32ebd5db2f7c957b82cf54b97bdecf367bf0421
I assume it's a dup of this one.

If you need the image itself, you can dump it to a file in the C
reproducer inside of syz_mount_image before mount call.

Thanks

[Randy Dunlap]

Sure, looks the same.

> If you need the image itself, you can dump it to a file in the C
> reproducer inside of syz_mount_image before mount call.

Yes, got that.

What outcome or result are you looking for here?
Or what do you see as the problem?


thanks.
--
~Randy

[Dmitry Vyukov]

Hi Randy,

"WARNING:" in kernel output is supposed to mean a kernel source bug.
Presence of that kernel bug is what syzbot has reported.

Note: the bug may be a misuse of the "WARNING:" for invalid user
inputs in output as well :)

[Randy Dunlap]

[adding Al Viro]

Hi Dmitry,

I expect that the "WARNING:" message is being interpreted incorrectly here,
but that's a minor issue IMO.

if (info->si_lasti == BFS_MAX_LASTI)
printf("WARNING: filesystem %s was created with 512 inodes, the real maximum is 511, mounting anyway\n", s->s_id);


If you/we look at fs/bfs/bfs.h, it says:

/* In theory BFS supports up to 512 inodes, numbered from 2 (for /) up to 513 inclusive.
In actual fact, attempting to create the 512th inode (i.e. inode No. 513 or file No. 511)
will fail with ENOSPC in bfs_add_entry(): the root directory cannot contain so many entries, counting '..'.
So, mkfs.bfs(8) should really limit its -N option to 511 and not 512. For now, we just print a warning
if a filesystem is mounted with such "impossible to fill up" number of inodes */

so one question is why does syzkaller try to do this at all?
Why not set number-of-inodes to 511 instead of 512 in the BFS image file?


However, in testing this, I see that the BFS image is not mounted
on /dev/loop# at all.

'mount' says:

# mount -t bfs -o loop bfsfilesyz000.img /mnt/stand
mount: /mnt/stand: mount(2) system call failed: Not a directory.

(but it is a directory)

and I have tracked that down to fs/namespace.c::graft_tree()
returning -ENOTDIR, but I don't know why that is happening.


Al, can you provide any insights on this?

thanks.
--
~Randy

[Dmitry Vyukov]

Solely for kernel testing purposes.

> Why not set number-of-inodes to 511 instead of 512 in the BFS image file?
>
> However, in testing this, I see that the BFS image is not mounted
> on /dev/loop# at all.
>
> 'mount' says:
>
> # mount -t bfs -o loop bfsfilesyz000.img /mnt/stand
> mount: /mnt/stand: mount(2) system call failed: Not a directory.
>
> (but it is a directory)
>
> and I have tracked that down to fs/namespace.c::graft_tree()
> returning -ENOTDIR, but I don't know why that is happening.
>
>
> Al, can you provide any insights on this?
>
> thanks.
> --
> ~Randy
>

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/dc76e615-a2fc-64e1-c979-4699d0d57309%40infradead.org.

[Randy Dunlap]

...

>>>> Hi Randy,
>>>>
>>>> I see this bug was reported with a reproducer:
>>>> https://syzkaller.appspot.com/bug?id=a32ebd5db2f7c957b82cf54b97bdecf367bf0421
>>>> I assume it's a dup of this one.
>>>
>>> Sure, looks the same.
>>>
>>>> If you need the image itself, you can dump it to a file in the C
>>>> reproducer inside of syz_mount_image before mount call.
>>>
>>> Yes, got that.
>>>
>>> What outcome or result are you looking for here?
>>> Or what do you see as the problem?
>>
>> Hi Randy,
>>
>> "WARNING:" in kernel output is supposed to mean a kernel source bug.
>> Presence of that kernel bug is what syzbot has reported.
>>
>> Note: the bug may be a misuse of the "WARNING:" for invalid user
>> inputs in output as well :)
>
>
> [adding Al Viro]
>
> Hi Dmitry,
>
> I expect that the "WARNING:" message is being interpreted incorrectly here,
> but that's a minor issue IMO.
>
> if (info->si_lasti == BFS_MAX_LASTI)
> printf("WARNING: filesystem %s was created with 512 inodes, the real maximum is 511, mounting anyway\n", s->s_id);
>

...

>
>
> However, in testing this, I see that the BFS image is not mounted
> on /dev/loop# at all.
>
> 'mount' says:
>
> # mount -t bfs -o loop bfsfilesyz000.img /mnt/stand
> mount: /mnt/stand: mount(2) system call failed: Not a directory.
>
> (but it is a directory)
>
> and I have tracked that down to fs/namespace.c::graft_tree()
> returning -ENOTDIR, but I don't know why that is happening.
>
>
> Al, can you provide any insights on this?

OK, with Al's help, here is the situation.

If I use a regular file instead of a directory, the mount
command succeeds.

The printk() from fs/bfs/inode.c that uses the WARNING: string
is not a WARN() or WARN_ON(). It's just a printk().

<linux/asm-generic/bug.h> says:

* Do not include "BUG"/"WARNING" in format strings manually to make these
* conditions distinguishable from kernel issues.

so if I change fs/bfs/inode.c to use "warning:" or "Warning," or "Note:",
this little problem should go away. Is that correct?


thanks.
--
~Randy

[Dmitry Vyukov]

Hi,

Yes, any of these prefixes will work (not be considered as a kernel
issue). syzkaller only matches "WARNING:" verbatim. I don't know about
all other kernel testing systems, but at least it's distinguishable.

Maybe also worth adding "bfs:" prefix for cases when people stare at
dmesg afterwards.

[Dmitry Vyukov]

Oh, sorry, there are already enough prefixes (BFS-fs: bfs_fill_super():).