Re: linux-next boot error (2)
On Tue, Nov 27, 2018 at 11:25 AM, David Howells wrote: > Dmitry Vyukov wrote: > >> Please either use the Reported-by tag (for amended linux-next fixes >> Tested-by can make more sense and is recognized too), or tell syzbot >> separately: > > It got folded in as that's better than carrying a separate patch. > > I'll ask Al how he wants to deal with this since he's carrying the patches > now. A similar case in linux-next was discussed recently: https://groups.google.com/d/msg/syzkaller-bugs/xiSF9GdiikU/uBoyYyf3AQAJ For such cases it can make more sense to use Tested-by tag instead of Reported-by to not confuse people that the resulting amended patch fixes some bug (e.g. stable will try to pick it up). Tested-by is also recognized by syzbot.
Re: linux-next boot error (2)
On Tue, Nov 27, 2018 at 11:25 AM, David Howells wrote: > Dmitry Vyukov wrote: > >> Please either use the Reported-by tag (for amended linux-next fixes >> Tested-by can make more sense and is recognized too), or tell syzbot >> separately: > > It got folded in as that's better than carrying a separate patch. > > I'll ask Al how he wants to deal with this since he's carrying the patches > now. A similar case in linux-next was discussed recently: https://groups.google.com/d/msg/syzkaller-bugs/xiSF9GdiikU/uBoyYyf3AQAJ For such cases it can make more sense to use Tested-by tag instead of Reported-by to not confuse people that the resulting amended patch fixes some bug (e.g. stable will try to pick it up). Tested-by is also recognized by syzbot.
Re: linux-next boot error (2)
Dmitry Vyukov wrote: > Please either use the Reported-by tag (for amended linux-next fixes > Tested-by can make more sense and is recognized too), or tell syzbot > separately: It got folded in as that's better than carrying a separate patch. I'll ask Al how he wants to deal with this since he's carrying the patches now. David
Re: linux-next boot error (2)
Dmitry Vyukov wrote: > Please either use the Reported-by tag (for amended linux-next fixes > Tested-by can make more sense and is recognized too), or tell syzbot > separately: It got folded in as that's better than carrying a separate patch. I'll ask Al how he wants to deal with this since he's carrying the patches now. David
Re: linux-next boot error (2)
On Tue, Sep 11, 2018 at 11:24 PM, David Howells wrote: > Stephen Rothwell wrote: > >> I will apply this fix until the proper fix arrives in the vfs tree: > > Thanks. > > David This was fixed in September, but the Reported-by tag wasn't added and nobody told syzbot that this is fixed. So the bug is still considered open: https://syzkaller.appspot.com/bug?extid=762a577f56cfb1574647 10 days ago linux-next become broken for another reason, but syzbot did not report a new bug because the previous one is still open (new reports are merged into the existing open bug). Please either use the Reported-by tag (for amended linux-next fixes Tested-by can make more sense and is recognized too), or tell syzbot separately: #syz fix: apparmor: Implement security hooks for the new mount API Also helps to keep dashboard relevant: https://syzkaller.appspot.com/#upstream-open a pile of hundreds of stale bugs is not too useful, and losing half of bug reports in LKML archives is not good too. Thanks in advance
Re: linux-next boot error (2)
On Tue, Sep 11, 2018 at 11:24 PM, David Howells wrote: > Stephen Rothwell wrote: > >> I will apply this fix until the proper fix arrives in the vfs tree: > > Thanks. > > David This was fixed in September, but the Reported-by tag wasn't added and nobody told syzbot that this is fixed. So the bug is still considered open: https://syzkaller.appspot.com/bug?extid=762a577f56cfb1574647 10 days ago linux-next become broken for another reason, but syzbot did not report a new bug because the previous one is still open (new reports are merged into the existing open bug). Please either use the Reported-by tag (for amended linux-next fixes Tested-by can make more sense and is recognized too), or tell syzbot separately: #syz fix: apparmor: Implement security hooks for the new mount API Also helps to keep dashboard relevant: https://syzkaller.appspot.com/#upstream-open a pile of hundreds of stale bugs is not too useful, and losing half of bug reports in LKML archives is not good too. Thanks in advance
Re: linux-next boot error (2)
Stephen Rothwell wrote: > I will apply this fix until the proper fix arrives in the vfs tree: Thanks. David
Re: linux-next boot error (2)
Stephen Rothwell wrote: > I will apply this fix until the proper fix arrives in the vfs tree: Thanks. David
Re: linux-next boot error (2)
Hi David, On Tue, 11 Sep 2018 21:16:27 +0100 David Howells wrote: > > Andrei Vagin spotted a missing change to apparmor: > apparmor_fs_context_parse_param() needs to return -ENOPARAM, not 0. I will apply this fix until the proper fix arrives in the vfs tree: From: Stephen Rothwell Date: Wed, 12 Sep 2018 06:27:43 +1000 Subject: [PATCH] apparmor: fix a return value Signed-off-by: Stephen Rothwell --- security/apparmor/lsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c index c316d4237d94..416204ea713d 100644 --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -602,7 +602,7 @@ static int apparmor_fs_context_parse_param(struct fs_context *fc, afc->saved_options = p; afc->saved_size += 1 + len; - return 0; + return -ENOPARAM; } static int apparmor_sb_mountpoint(struct fs_context *fc, struct path *mountpoint, -- 2.19.0.rc2 -- Cheers, Stephen Rothwell pgpsj4wQyWCuL.pgp Description: OpenPGP digital signature
Re: linux-next boot error (2)
Hi David, On Tue, 11 Sep 2018 21:16:27 +0100 David Howells wrote: > > Andrei Vagin spotted a missing change to apparmor: > apparmor_fs_context_parse_param() needs to return -ENOPARAM, not 0. I will apply this fix until the proper fix arrives in the vfs tree: From: Stephen Rothwell Date: Wed, 12 Sep 2018 06:27:43 +1000 Subject: [PATCH] apparmor: fix a return value Signed-off-by: Stephen Rothwell --- security/apparmor/lsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c index c316d4237d94..416204ea713d 100644 --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -602,7 +602,7 @@ static int apparmor_fs_context_parse_param(struct fs_context *fc, afc->saved_options = p; afc->saved_size += 1 + len; - return 0; + return -ENOPARAM; } static int apparmor_sb_mountpoint(struct fs_context *fc, struct path *mountpoint, -- 2.19.0.rc2 -- Cheers, Stephen Rothwell pgpsj4wQyWCuL.pgp Description: OpenPGP digital signature
Re: linux-next boot error (2)
Andrei Vagin spotted a missing change to apparmor: apparmor_fs_context_parse_param() needs to return -ENOPARAM, not 0. David
Re: linux-next boot error (2)
Andrei Vagin spotted a missing change to apparmor: apparmor_fs_context_parse_param() needs to return -ENOPARAM, not 0. David
Re: linux-next boot error (2)
On Thu, Sep 6, 2018 at 10:41 AM, David Howells wrote: > Do we know what type of filesystem is on the root device? ext4 The image is built with this script (you can find mkfs.ext4 there): https://github.com/google/syzkaller/blob/master/tools/create-gce-image.sh > Also, is there a way to tell if AppArmor denied something? That I don't know. I guess it would have printed something. This configuration worked before. And we don't see any errors on other trees. A relatively recent addition was ext4 options "-O ^resize_inode,has_journal,ext_attr,extents,huge_file,flex_bg,dir_nlink,sparse_super". But I think we already tested with them and that all worked.
Re: linux-next boot error (2)
On Thu, Sep 6, 2018 at 10:41 AM, David Howells wrote: > Do we know what type of filesystem is on the root device? ext4 The image is built with this script (you can find mkfs.ext4 there): https://github.com/google/syzkaller/blob/master/tools/create-gce-image.sh > Also, is there a way to tell if AppArmor denied something? That I don't know. I guess it would have printed something. This configuration worked before. And we don't see any errors on other trees. A relatively recent addition was ext4 options "-O ^resize_inode,has_journal,ext_attr,extents,huge_file,flex_bg,dir_nlink,sparse_super". But I think we already tested with them and that all worked.
Re: linux-next boot error (2)
Do we know what type of filesystem is on the root device? Also, is there a way to tell if AppArmor denied something? David
Re: linux-next boot error (2)
Do we know what type of filesystem is on the root device? Also, is there a way to tell if AppArmor denied something? David
linux-next boot error (2)
Hello, syzbot found the following crash on: HEAD commit:509d1f0c294a Add linux-next specific files for 20180906 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=157b857a40 kernel config: https://syzkaller.appspot.com/x/.config?x=d1a648893bbc933 dashboard link: https://syzkaller.appspot.com/bug?extid=762a577f56cfb1574647 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+762a577f56cfb1574...@syzkaller.appspotmail.com kernel panic: VFS: Unable to mount root fs on unknown-block(8,1) driver: sd 0801 2096128 sda1 24d8ab2f-01 1f00 128 mtdblock0 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1) CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc2-next-20180906+ #60 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 mount_block_root+0x61f/0x71f init/do_mounts.c:442 mount_root+0x2d0/0x317 init/do_mounts.c:562 prepare_namespace+0x26c/0x2ab init/do_mounts.c:621 kernel_init_freeable+0x590/0x5ae init/main.c:1163 kernel_init+0x11/0x1b3 init/main.c:1063 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug 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 bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
linux-next boot error (2)
Hello, syzbot found the following crash on: HEAD commit:509d1f0c294a Add linux-next specific files for 20180906 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=157b857a40 kernel config: https://syzkaller.appspot.com/x/.config?x=d1a648893bbc933 dashboard link: https://syzkaller.appspot.com/bug?extid=762a577f56cfb1574647 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+762a577f56cfb1574...@syzkaller.appspotmail.com kernel panic: VFS: Unable to mount root fs on unknown-block(8,1) driver: sd 0801 2096128 sda1 24d8ab2f-01 1f00 128 mtdblock0 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1) CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc2-next-20180906+ #60 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 mount_block_root+0x61f/0x71f init/do_mounts.c:442 mount_root+0x2d0/0x317 init/do_mounts.c:562 prepare_namespace+0x26c/0x2ab init/do_mounts.c:621 kernel_init_freeable+0x590/0x5ae init/main.c:1163 kernel_init+0x11/0x1b3 init/main.c:1063 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug 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 bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
