Skip to contentSkip to conversation

lockdep info message

DISCUSSION Arend van Spriel 2 participants 3 messages Oct 26, 2012

lore
Share & tools
lore
#0 lore raw

Hi Peter and/or Ingo,

I am working on a driver (brcmfmac) and when unloading it or unplugging the device I get this info message (see below) upon calling cancel_work_sync(). Just wondering if there is something I need to do in the driver or should it be done in workqueue code.

Regards,
Arend

[  268.167897] INFO: trying to register non-static key.
[  268.173279] the code is fine but needs lockdep annotation.
[  268.179188] turning off the locking correctness validator.
[  268.185093] Pid: 31, comm: khubd Tainted: G           O 3.7.0-rc2-testing-lockdep #1
[  268.193254] Call Trace:
[  268.196150]  [<c10929c6>] __lock_acquire+0xb36/0x1780
[  268.201641]  [<c10229fb>] ? lapic_next_event+0x1b/0x20
[  268.207216]  [<c108c0e2>] ? clockevents_program_event+0xb2/0x170
[  268.213654]  [<c108d4e9>] ? tick_program_event+0x29/0x30
[  268.219404]  [<c105f17d>] ? hrtimer_interrupt+0x17d/0x2b0
[  268.225239]  [<c133b170>] ? vt_console_print+0x280/0x350
[  268.231000]  [<c1093b14>] lock_acquire+0x84/0x120
[  268.236152]  [<c1053200>] ? delayed_work_timer_fn+0x30/0x30
[  268.242172]  [<c10943b4>] ? trace_hardirqs_on_caller+0xf4/0x180
[  268.248541]  [<c1053248>] flush_work+0x48/0x250
[  268.253532]  [<c1053200>] ? delayed_work_timer_fn+0x30/0x30
[  268.259562]  [<c109007b>] ? perf_trace_lock+0xb/0x120
[  268.265075]  [<c103af9a>] ? vprintk_emit+0x19a/0x500
[  268.270503]  [<c1054eea>] ? __cancel_work_timer+0x5a/0xb0
[  268.276365]  [<c10943b4>] ? trace_hardirqs_on_caller+0xf4/0x180
[  268.282751]  [<c1054efa>] __cancel_work_timer+0x6a/0xb0
[  268.288426]  [<c1054f6f>] cancel_work_sync+0xf/0x20
[  268.293743]  [<f843d71b>] brcmf_detach+0x7b/0xe0 [brcmfmac]
#1 lore raw
Quoted 6 lines · Arend van Spriel

Hi Peter and/or Ingo,

I am working on a driver (brcmfmac) and when unloading it or unplugging the device I get this info message (see below) upon calling cancel_work_sync(). Just wondering if there is something I need to do in the driver or should it be done in workqueue code.

Your driver, as that's the one allocating the struct work_struct thingy.

You've either failed to use INIT_WORK() or need to use INIT_WORK_ONSTACK() if that's appropriate. It looks like you could have used DECLARE*_WORK inside a function or something similar.

Anyway, without the driver code present I can't really say much more.

#2 lore raw
Quoted 8 lines · Peter Zijlstra
Quoted 6 lines · Arend van Spriel

Hi Peter and/or Ingo,

I am working on a driver (brcmfmac) and when unloading it or unplugging the device I get this info message (see below) upon calling cancel_work_sync(). Just wondering if there is something I need to do in the driver or should it be done in workqueue code.

Quoted 8 lines

Your driver, as that's the one allocating the struct work_struct thingy.

You've either failed to use INIT_WORK() or need to use INIT_WORK_ONSTACK() if that's appropriate. It looks like you could have used DECLARE*_WORK inside a function or something similar.

Anyway, without the driver code present I can't really say much more.

I assume INIT_WORK_ONSTACK() can only be used when scheduling process waits for the work to complete. The work_struct is located inside a driver structure that is allocated upon device probe.

struct brcmf_fweh_info {
	struct work_struct event_work;
};

and it is initialized in that context using:

	INIT_WORK(&fweh->event_work, brcmf_fweh_event_worker);

and used in another context:

	schedule_work(&fweh->event_work);

When cleaning up I do:

	cancel_work_sync(&fweh->event_work);

I can also submit the patch with the entire code as RFC if you do not object digging through a couple of hundred lines.

Gr. AvS