linux-next boot error (2)

linux-next boot error (2)

[syzbot]

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=157b857a400000
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+762a577f56cfb1574647@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 syzkaller@googlegroups.com.

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

Re: linux-next boot error (2)

[David Howells]

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)

[Dmitry Vyukov]

On Thu, Sep 6, 2018 at 10:41 AM, David Howells <dhowells@redhat.com> 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)

[David Howells]

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)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Hi David,

On Tue, 11 Sep 2018 21:16:27 +0100 David Howells <dhowells@redhat.com> 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 <sfr@canb.auug.org.au>
Date: Wed, 12 Sep 2018 06:27:43 +1000
Subject: [PATCH] apparmor: fix a return value

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next boot error (2)

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> I will apply this fix until the proper fix arrives in the vfs tree:

Thanks.

David

Re: linux-next boot error (2)

[Dmitry Vyukov]

On Tue, Sep 11, 2018 at 11:24 PM, David Howells <dhowells@redhat.com> wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> 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)

[David Howells]

Dmitry Vyukov <dvyukov@google.com> 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]

On Tue, Nov 27, 2018 at 11:25 AM, David Howells <dhowells@redhat.com> wrote:
> Dmitry Vyukov <dvyukov@google.com> 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.