linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* lockdep info message
@ 2012-10-26 10:15 Arend van Spriel
  2012-10-26 11:25 ` Peter Zijlstra
  0 siblings, 1 reply; 3+ messages in thread
From: Arend van Spriel @ 2012-10-26 10:15 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar; +Cc: Tejun Heo, LKML

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]


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: lockdep info message
  2012-10-26 10:15 lockdep info message Arend van Spriel
@ 2012-10-26 11:25 ` Peter Zijlstra
  2012-10-26 13:19   ` Arend van Spriel
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Zijlstra @ 2012-10-26 11:25 UTC (permalink / raw)
  To: Arend van Spriel; +Cc: Ingo Molnar, Tejun Heo, LKML

On Fri, 2012-10-26 at 12:15 +0200, Arend van Spriel wrote:
> 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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: lockdep info message
  2012-10-26 11:25 ` Peter Zijlstra
@ 2012-10-26 13:19   ` Arend van Spriel
  0 siblings, 0 replies; 3+ messages in thread
From: Arend van Spriel @ 2012-10-26 13:19 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Ingo Molnar, Tejun Heo, LKML

On 10/26/2012 01:25 PM, Peter Zijlstra wrote:
> On Fri, 2012-10-26 at 12:15 +0200, Arend van Spriel wrote:
>> 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.
>

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-10-26 13:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-26 10:15 lockdep info message Arend van Spriel
2012-10-26 11:25 ` Peter Zijlstra
2012-10-26 13:19   ` Arend van Spriel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).