Re: [LKP] [binder] 3ad20fe393: BUG:unable_to_handle_kernel

From: Christian Brauner
Date: Wed Jan 09 2019 - 04:44:37 EST


On January 9, 2019 9:50:41 AM GMT+01:00, kernel test robot <rong.a.chen@xxxxxxxxx> wrote:
>FYI, we noticed the following commit (built with gcc-7):
>
>commit: 3ad20fe393b31025bebfc2d76964561f65df48aa ("binder: implement
>binderfs")
>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
>in testcase: trinity
>with following parameters:
>
> runtime: 300s
>
>test-description: Trinity is a linux system call fuzz tester.
>test-url: http://codemonkey.org.uk/projects/trinity/
>
>
>on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2
>-m 768M
>
>caused below changes (please refer to attached dmesg/kmsg for entire
>log/backtrace):
>
>
>+------------------------------------------+------------+------------+
>| | 80cd795630 | 3ad20fe393 |
>+------------------------------------------+------------+------------+
>| boot_successes | 17 | 1 |
>| boot_failures | 8 | 31 |
>| invoked_oom-killer:gfp_mask=0x | 6 | |
>| Mem-Info | 6 | |
>| BUG:kernel_in_stage | 2 | 4 |
>| RIP:__put_user_8 | 1 | |
>| BUG:unable_to_handle_kernel | 0 | 27 |
>| Oops:#[##] | 0 | 27 |
>| RIP:binderfs_mount | 0 | 27 |
>| Kernel_panic-not_syncing:Fatal_exception | 0 | 27 |
>+------------------------------------------+------------+------------+
>
>
>
>[ 8.360965] BUG: unable to handle kernel NULL pointer dereference at
>00000000000006a0
>[ 8.362067] PGD 0 P4D 0
>[ 8.362437] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
>[ 8.363131] CPU: 0 PID: 1 Comm: swapper Not tainted
>4.20.0-rc6-00107-g3ad20fe #2
>[ 8.364177] RIP: 0010:binderfs_mount+0x42/0x480
>[ 8.364820] Code: 89 fc 49 c7 c7 ff ff ff ff 48 83 ec 20 e8 86 5d 86
>ff 48 8b 04 25 40 10 e3 ab 48 8b 80 28 06 00 00 be 15 00 00 00 48 8b 58
>10 <48> 8b bb a0 06 00 00 e8 e2 3c 7d ff 84 c0 75 19 e8 59 5d 86 ff 48
>[ 8.367104] RSP: 0000:ffffb6a78000bd98 EFLAGS: 00010293
>[ 8.367104] RAX: ffffffffabe48e40 RBX: 0000000000000000 RCX:
>ffffffffab2bfd6a
>[ 8.367104] RDX: 0000000000000000 RSI: 0000000000000015 RDI:
>ffffffffabf38d60
>[ 8.367104] RBP: ffffb6a78000bde8 R08: 0000000000000000 R09:
>0000000000000000
>[ 8.367104] R10: 0000000000000000 R11: ffff90c7ec4f2980 R12:
>ffffffffabf38d60
>[ 8.367104] R13: 0000000000400000 R14: ffffffffabf38d60 R15:
>ffffffffffffffff
>[ 8.367104] FS: 0000000000000000(0000) GS:ffffffffabe2d000(0000)
>knlGS:0000000000000000
>[ 8.367104] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[ 8.367104] CR2: 00000000000006a0 CR3: 0000000027e19000 CR4:
>00000000000406b0
>[ 8.367104] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>0000000000000000
>[ 8.367104] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
>0000000000000400
>[ 8.367104] Call Trace:
>[ 8.367104] ? __lockdep_init_map+0x4d/0x1b0
>[ 8.367104] mount_fs+0x30/0xe0
>[ 8.367104] vfs_kern_mount+0x63/0x160

Thanks. A fix for this is already in Greg's char-misc tree queued up for -rc2.
The wrong kern_mount() call is gone then.

Christian