Re: WARNING: ODEBUG bug in vudc_probe

From: Dmitry Vyukov
Date: Fri Sep 07 2018 - 12:15:04 EST


On Fri, Sep 7, 2018 at 6:03 PM, Shuah Khan <shuah@xxxxxxxxxx> wrote:
> Hi Dmitry,
>
> On 09/07/2018 04:54 AM, Dmitry Vyukov wrote:
>> Hi,
>>
>> I am getting the following error while booting kernel on upstream
>> commit a49a9dcce802b3651013f659813df1361d306172, config is attached.
>> Seems there is some kind of resource leak.
>>
>> Thanks
>
> Odd. This commit has nothing to do with vudc.

This is not the guilty commit, I just described state of my tree.

> I am adding developers
> that are associated with this commit to the thread.
>
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 58c6efa9f9a9..9fe5952d117d 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -275,9 +275,9 @@ static void bfqg_and_blkg_get(struct bfq_group *bfqg)
>
> void bfqg_and_blkg_put(struct bfq_group *bfqg)
> {
> - bfqg_put(bfqg);
> -
> blkg_put(bfqg_to_blkg(bfqg));
> +
> + bfqg_put(bfqg);
> }
>
> /* @stats = 0 */
> --
>
>>
>> ------------[ cut here ]------------
>> ODEBUG: free active (active state 0) object type: timer_list hint:
>> delayed_work_timer_fn+0x0/0x6e kernel/workqueue.c:4923
>> WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:329
>> debug_print_object+0x164/0x17c lib/debugobjects.c:326
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc2-00205-ga49a9dcce802 #6
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
>> Call Trace:
>> __dump_stack lib/dump_stack.c:77 [inline]
>> dump_stack+0x1a5/0x28b lib/dump_stack.c:113
>> panic+0x239/0x4e8 kernel/panic.c:184
>> __warn+0x16f/0x1c5 kernel/panic.c:536
>> report_bug+0x163/0x1c9 lib/bug.c:186
>> fixup_bug+0x43/0x7c arch/x86/kernel/traps.c:178
>> do_error_trap+0xee/0x2ac arch/x86/kernel/traps.c:296
>> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
>> RIP: 0010:debug_print_object+0x164/0x17c lib/debugobjects.c:326
>> Code: 3c 02 00 74 05 e8 06 12 cc fe 48 8b 14 dd 60 9c c8 86 4d 89 e9
>> 49 89 e8 44 89 f1 4c 89 e6 48 c7 c7 a0 90 c8 86 e8 5e a7 7a fe <0f> 0b
>> 5b ff 05 b1 92 45 06 5d 41 5c 41 5d 41 5e c3 ff 05 a3 92 45
>> RSP: 0000:ffff88006bbaf510 EFLAGS: 00010086
>> RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffff88006bba2900
>> RDX: 000000616bba2900 RSI: ffffffff8148ef03 RDI: ffffed000d775e76
>> RBP: ffffffff868e66a0 R08: fffffbfff0ff8ff1 R09: 0000000000000001
>> R10: ffff88006bba2900 R11: fffffbfff0ff8ff0 R12: ffffffff86c89580
>> R13: ffffffff813c4247 R14: 0000000000000000 R15: ffff88006a131208
>> __debug_check_no_obj_freed lib/debugobjects.c:786 [inline]
>> debug_check_no_obj_freed+0x176/0x2a1 lib/debugobjects.c:818
>> slab_free_hook mm/slub.c:1368 [inline]
>> slab_free_freelist_hook+0x8a/0xed mm/slub.c:1398
>> slab_free mm/slub.c:2953 [inline]
>> kfree+0x187/0x222 mm/slub.c:3906
>
> I am a bit stumped. The memory vudc is trying to free is valid. I am
> looking into this more. Please send me the full dmesg.
>
>> vudc_probe+0x9d9/0xa24 drivers/usb/usbip/vudc_dev.c:633
>> platform_drv_probe+0xdd/0x181 drivers/base/platform.c:579
>> really_probe+0x590/0xb2a drivers/base/dd.c:500
>> driver_probe_device+0x2a8/0x313 drivers/base/dd.c:662
>> __device_attach_driver+0x220/0x27b drivers/base/dd.c:758
>> bus_for_each_drv+0x177/0x1b8 drivers/base/bus.c:461
>> __device_attach+0x203/0x36d drivers/base/dd.c:815
>> bus_probe_device+0xc8/0x22d drivers/base/bus.c:521
>> device_add+0x5b6/0x1273 drivers/base/core.c:1927
>> platform_device_add+0x53a/0x68d drivers/base/platform.c:417
>> init+0x13e/0x3c4 arch/x86/crypto/blowfish_glue.c:444
>> do_one_initcall+0x2d8/0x63f init/main.c:885
>> do_initcall_level init/main.c:953 [inline]
>> do_initcalls init/main.c:961 [inline]
>> do_basic_setup init/main.c:979 [inline]
>> kernel_init_freeable+0x4bb/0x5ac init/main.c:1144
>> kernel_init+0x11/0x1b6 init/main.c:1063
>> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
>>
>
> thanks,
> -- Shuah