worker_maybe_bind_and_lock() actually grabs gcwq->lock but was missing proper
annotation. Add it. So this patch will remove following sparse warnings:
kernel/workqueue.c:1214:13: warning: context imbalance in 'worker_maybe_bind_and_lock' - wrong count at exit
arch/x86/include/asm/irqflags.h:44:9: warning: context imbalance in 'worker_rebind_fn' - unexpected unlock
kernel/workqueue.c:1991:17: warning: context imbalance in 'rescuer_thread' - unexpected unlock
Signed-off-by: Namhyung Kim <[email protected]>
---
kernel/workqueue.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index be0b71d..1145c50 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1212,6 +1212,7 @@ static void worker_leave_idle(struct worker *worker)
* bound), %false if offline.
*/
static bool worker_maybe_bind_and_lock(struct worker *worker)
+__acquires(&gcwq->lock)
{
struct global_cwq *gcwq = worker->gcwq;
struct task_struct *task = worker->task;
--
1.7.0.4
On 08/22/2010 04:19 PM, Namhyung Kim wrote:
> worker_maybe_bind_and_lock() actually grabs gcwq->lock but was missing proper
> annotation. Add it. So this patch will remove following sparse warnings:
>
> kernel/workqueue.c:1214:13: warning: context imbalance in 'worker_maybe_bind_and_lock' - wrong count at exit
> arch/x86/include/asm/irqflags.h:44:9: warning: context imbalance in 'worker_rebind_fn' - unexpected unlock
> kernel/workqueue.c:1991:17: warning: context imbalance in 'rescuer_thread' - unexpected unlock
>
> Signed-off-by: Namhyung Kim <[email protected]>
applied to wq#for-linus. Thanks.
Also, please considering putting related patches into a thread. For
short series, just chaining them is good enough (ie. patch n+1 is
reply to patch n). For longer series, writing up a head message with
overall description, diffstat and other general info about the patch
series and making all patches reaplies to the head message is a good
idea.
Thanks.
--
tejun
2010-08-23 (월), 11:41 +0200, Tejun Heo:
> Also, please considering putting related patches into a thread. For
> short series, just chaining them is good enough (ie. patch n+1 is
> reply to patch n). For longer series, writing up a head message with
> overall description, diffstat and other general info about the patch
> series and making all patches reaplies to the head message is a good
> idea.
>
> Thanks.
>
OK. I see. Thank you for the advice.
--
Regards,
Namhyung Kim