On Thu, Dec 3, 2020 at 5:15 AM Randy Dunlap <rdun...@infradead.org> wrote: > > On 12/1/20 1:17 PM, Randy Dunlap wrote: > > On 11/30/20 11:47 PM, Dmitry Vyukov wrote: > >> On Tue, Dec 1, 2020 at 2:03 AM Randy Dunlap <rdun...@infradead.org> wrote: > >>> > >>> On 11/30/20 12:43 AM, Dmitry Vyukov wrote: > >>>> On Mon, Nov 30, 2020 at 5:29 AM Randy Dunlap <rdun...@infradead.org> > >>>> wrote: > >>>>> > >>>>> On 11/27/20 4:32 AM, syzbot wrote: > >>>>>> 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+3fd34060f26e76653...@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 syzkal...@googlegroups.com. > >>>>>> > >>>>>> syzbot will keep track of this issue. See: > >>>>>> https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > ... > > >>>> 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?
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.
