Messages in this thread | | | Date | Wed, 09 Jan 2019 10:44:27 +0100 | Subject | Re: [LKP] [binder] 3ad20fe393: BUG:unable_to_handle_kernel | From | Christian Brauner <> |
| |
On January 9, 2019 9:50:41 AM GMT+01:00, kernel test robot <rong.a.chen@intel.com> 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
| |