On Thu, Dec 3, 2020 at 1:55 PM Dmitry Vyukov <dvyu...@google.com> wrote: > > 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.
Oh, sorry, there are already enough prefixes (BFS-fs: bfs_fill_super():).