Re: [lkp-robot] [mm, memcg] b4536f0c82: kobject(#):tried_to_init_an_initialized_object, something_is_seriously_wrong

[Ye Xiaolong <xiaolong.ye@intel.com>]

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

On 06/12, Michal Hocko wrote:
>On Mon 12-06-17 14:59:45, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> commit: b4536f0c829c8586544c94735c343f9b5070bd01 ("mm, memcg: fix the active list aging for lowmem requests when memcg is enabled")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>> 
>> in testcase: boot
>
>This is really strange. The commit is merged since 4.10-rc4 and this is
>the first time I can see a report like this. Is there anything new in
>your testing setup? The effect on the x86_64 without movable zones
>should be pretty much a noop.
>
>> [    4.442394] g_mass_storage usbip-vudc.0: failed to start g_mass_storage: -22
>> [    4.443795] usbip-vudc: probe of usbip-vudc.0 failed with error -22
>> [    4.445075] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
>> [    4.447707] serio: i8042 KBD port at 0x60,0x64 irq 1
>> [    4.448652] serio: i8042 KBD port at 0x60,0x64 irq 12
>> [    4.449626] kobject (ffff902eda7d6d58): tried to init an initialized object, something is seriously wrong.
>
>This sounds suspicious!
>
>> [    4.451431] CPU: 0 PID: 1 Comm: swapper Not tainted 4.10.0-rc3-00070-gb4536f0c8 #1
>> [    4.452774] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>> [    4.452784] IP: process_one_work+0x37/0x500
>> [    4.452786] PGD 0 
>> [    4.452787] 
>> [    4.452788] Oops: 0000 [#1]
>> [    4.452792] CPU: 0 PID: 21 Comm: kworker/0:1 Not tainted 4.10.0-rc3-00070-gb4536f0c8 #1
>> [    4.452793] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
>> [    4.452801] task: ffff902edf6f6e00 task.stack: ffff902edf7a0000
>> [    4.452804] RIP: 0010:process_one_work+0x37/0x500
>> [    4.452805] RSP: 0000:ffff902edf7a3e58 EFLAGS: 00010046
>> [    4.452807] RAX: ffff902edc3ae800 RBX: ffff902edf788930 RCX: ffff902edfb13960
>> [    4.452808] RDX: ffff902edc3ae800 RSI: ffff902edc3ad000 RDI: ffff902edf788900
>> [    4.452809] RBP: ffff902edf7a3e98 R08: ffff902edfb13040 R09: ffff902edf62c651
>> [    4.452811] R10: 0000000000000000 R11: 0000000000000800 R12: ffffffff9964bb80
>> [    4.452812] R13: ffff902edf788900 R14: 0000000000000000 R15: ffff902edc3ad000
>> [    4.452815] FS:  0000000000000000(0000) GS:ffffffff99631000(0000) knlGS:0000000000000000
>> [    4.452816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [    4.452817] CR2: 00000000000000a8 CR3: 000000001720e000 CR4: 00000000000006f0
>> [    4.452823] Call Trace:
>> [    4.452827]  worker_thread+0x2ae/0x680
>> [    4.452832]  kthread+0x10b/0x140
>> [    4.452834]  ? process_one_work+0x500/0x500
>> [    4.452836]  ? __kthread_create_on_node+0x190/0x190
>
>And this trace is nowhere close to the reclaim path. So is it possible
>that this is just a fallout of some other earlier errors? How
>reproducible is it?

Sorry it is a false positive, with or without the commit the kernel would crash
very early with wrong stuff like kobject is not initialized, it should be a
fallout of some earlier errors, the commit in question is innocent.


Thanks,
Xiaolong
>
>-- 
>Michal Hocko
>SUSE Labs