Re: [PATCH] leds: make sure we unregister a trigger only once

[Sasha Levin]

On 04/07/2014 06:08 PM, Bryan Wu wrote:
> On Fri, Apr 4, 2014 at 10:01 AM, Sasha Levin <sasha.levin@xxxxxxxxxx> wrote:
>> Currently, we may attempt to unregister a trigger more than once, for
>> example when we receive two consecutive reboot notifications, or when
>> we do a regular unregistration plus reboot notification.
>>
>> This leads to the following error since we try to delete the list node
>> twice:
>>
>> [ 2780.254922] WARNING: CPU: 0 PID: 13764 at lib/list_debug.c:53 __list_del_entry+0x3e/0xe0()
>> [ 2780.265559] list_del corruption, ffffffffa5eb6470->next is LIST_POISON1 (dead000000100100)
>> [ 2780.271710] Modules linked in:
>> [ 2780.274156] CPU: 0 PID: 13764 Comm: kworker/0:2 Tainted: G        W     3.14.0-next-20140403-sasha-00012-gef5fa7d-dirty #373
>> [ 2780.283063] Workqueue: events do_poweroff
>> [ 2780.285644]  0000000000000009 ffff8800330dbb38 ffffffffa34bfa33 0000000000002fe0
>> [ 2780.291571]  ffff8800330dbb88 ffff8800330dbb78 ffffffffa015a37c ffff8800330dbb68
>> [ 2780.296670]  ffffffffa5eb6470 0000000000000000 ffffffffa5eb6400 ffffffffa5ad7430
>> [ 2780.299756] Call Trace:
>> [ 2780.301530] dump_stack (lib/dump_stack.c:52)
>> [ 2780.303802] warn_slowpath_common (kernel/panic.c:418)
>> [ 2780.306151] warn_slowpath_fmt (kernel/panic.c:433)
>> [ 2780.308156] __list_del_entry (lib/list_debug.c:51 (discriminator 1))
>> [ 2780.310800] list_del (lib/list_debug.c:78)
>> [ 2780.313175] led_trigger_unregister (drivers/leds/led-triggers.c:225)
>> [ 2780.315599] heartbeat_reboot_notifier (drivers/leds/trigger/ledtrig-heartbeat.c:119)
>> [ 2780.317247] notifier_call_chain (kernel/notifier.c:95)
>> [ 2780.320014] __blocking_notifier_call_chain (kernel/notifier.c:316)
>> [ 2780.323263] blocking_notifier_call_chain (kernel/notifier.c:326)
>> [ 2780.326096] kernel_power_off (include/linux/kmod.h:95 kernel/reboot.c:153 kernel/reboot.c:179)
>> [ 2780.327883] do_poweroff (kernel/power/poweroff.c:23)
>> [ 2780.330748] process_one_work (kernel/workqueue.c:2221 include/linux/jump_label.h:105 include/trace/events/workqueue.h:111 kernel/workqueue.c:2226)
>> [ 2780.333027] ? process_one_work (include/linux/workqueue.h:186 kernel/workqueue.c:611 kernel/workqueue.c:638 kernel/workqueue.c:2214)
>> [ 2780.335487] process_scheduled_works (include/linux/list.h:188 kernel/workqueue.c:2277)
>> [ 2780.337101] worker_thread (kernel/workqueue.c:2352)
>> [ 2780.338712] ? rescuer_thread (kernel/workqueue.c:2297)
>> [ 2780.341326] kthread (kernel/kthread.c:219)
>> [ 2780.343446] ? kthread_create_on_node (kernel/kthread.c:185)
>> [ 2780.345733] ret_from_fork (arch/x86/kernel/entry_64.S:555)
>> [ 2780.347168] ? kthread_create_on_node (kernel/kthread.c:185)
>>
>> Prevent it by making sure we don't attempt to unregister a trigger that
>> is not in the triggers list.
>>
> 
> Looks good to me literally, could you please provide some simple test
> case for me? I need verify it on my side.

First, make sure you test it on a kernel with list debugging enabled,
otherwise there won't be noticeable result unless you end up corrupting
something important in the memory.

Try calling reboot() and unregistering a device that has a led trigger
at the same time (from two different threads) and hope you hit that race.


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/