From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
bhelgaas@google.com, Yinghai Lu <yinghai@kernel.org>,
Alex Duyck <alexander.h.duyck@intel.com>
Subject: Re: [PATCH] workqueue: allow work_on_cpu() to be called recursively
Date: Sat, 27 Jul 2013 22:41:44 +0530 [thread overview]
Message-ID: <51F3FF50.4070701@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130724162542.GE20377@mtj.dyndns.org>
On 07/24/2013 09:55 PM, Tejun Heo wrote:
> Applied to wq/for-3.11-fixes with comment and subject tweaks.
>
> Thanks!
>
> ---------- 8< ------------
>
> From c2fda509667b0fda4372a237f5a59ea4570b1627 Mon Sep 17 00:00:00 2001
> From: Lai Jiangshan <laijs@cn.fujitsu.com>
> Date: Wed, 24 Jul 2013 18:31:42 +0800
>
> If the @fn call work_on_cpu() again, the lockdep will complain:
>
>> [ INFO: possible recursive locking detected ]
>> 3.11.0-rc1-lockdep-fix-a #6 Not tainted
>> ---------------------------------------------
>> kworker/0:1/142 is trying to acquire lock:
>> ((&wfc.work)){+.+.+.}, at: [<ffffffff81077100>] flush_work+0x0/0xb0
>>
>> but task is already holding lock:
>> ((&wfc.work)){+.+.+.}, at: [<ffffffff81075dd9>] process_one_work+0x169/0x610
>>
>> other info that might help us debug this:
>> Possible unsafe locking scenario:
>>
>> CPU0
>> ----
>> lock((&wfc.work));
>> lock((&wfc.work));
>>
>> *** DEADLOCK ***
>
> It is false-positive lockdep report. In this sutiation,
> the two "wfc"s of the two work_on_cpu() are different,
> they are both on stack. flush_work() can't be deadlock.
>
> To fix this, we need to avoid the lockdep checking in this case,
> thus we instroduce a internal __flush_work() which skip the lockdep.
>
> tj: Minor comment adjustment.
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> Reported-by: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> Reported-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
This version works as well, it fixes the issue I was facing.
Thank you!
FWIW:
Tested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Regards,
Srivatsa S. Bhat
> kernel/workqueue.c | 32 ++++++++++++++++++++++----------
> 1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index f02c4a4..55f5f0a 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -2817,6 +2817,19 @@ already_gone:
> return false;
> }
>
> +static bool __flush_work(struct work_struct *work)
> +{
> + struct wq_barrier barr;
> +
> + if (start_flush_work(work, &barr)) {
> + wait_for_completion(&barr.done);
> + destroy_work_on_stack(&barr.work);
> + return true;
> + } else {
> + return false;
> + }
> +}
> +
> /**
> * flush_work - wait for a work to finish executing the last queueing instance
> * @work: the work to flush
> @@ -2830,18 +2843,10 @@ already_gone:
> */
> bool flush_work(struct work_struct *work)
> {
> - struct wq_barrier barr;
> -
> lock_map_acquire(&work->lockdep_map);
> lock_map_release(&work->lockdep_map);
>
> - if (start_flush_work(work, &barr)) {
> - wait_for_completion(&barr.done);
> - destroy_work_on_stack(&barr.work);
> - return true;
> - } else {
> - return false;
> - }
> + return __flush_work(work);
> }
> EXPORT_SYMBOL_GPL(flush_work);
>
> @@ -4756,7 +4761,14 @@ long work_on_cpu(int cpu, long (*fn)(void *), void *arg)
>
> INIT_WORK_ONSTACK(&wfc.work, work_for_cpu_fn);
> schedule_work_on(cpu, &wfc.work);
> - flush_work(&wfc.work);
> +
> + /*
> + * The work item is on-stack and can't lead to deadlock through
> + * flushing. Use __flush_work() to avoid spurious lockdep warnings
> + * when work_on_cpu()s are nested.
> + */
> + __flush_work(&wfc.work);
> +
> return wfc.ret;
> }
> EXPORT_SYMBOL_GPL(work_on_cpu);
>
prev parent reply other threads:[~2013-07-27 17:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 14:41 workqueue, pci: INFO: possible recursive locking detected Srivatsa S. Bhat
2013-07-17 10:07 ` Lai Jiangshan
2013-07-18 20:23 ` Srivatsa S. Bhat
2013-07-19 1:47 ` Lai Jiangshan
2013-07-19 8:57 ` Srivatsa S. Bhat
2013-07-22 11:52 ` Lai Jiangshan
2013-07-22 15:37 ` Srivatsa S. Bhat
2013-07-22 21:38 ` Bjorn Helgaas
2013-07-22 22:06 ` Yinghai Lu
2013-07-22 22:33 ` Alexander Duyck
2013-07-22 21:32 ` Tejun Heo
2013-07-23 1:23 ` Lai Jiangshan
2013-07-23 14:38 ` Tejun Heo
2013-07-24 10:31 ` Lai Jiangshan
2013-07-24 16:25 ` [PATCH] workqueue: allow work_on_cpu() to be called recursively Tejun Heo
2013-07-27 17:11 ` Srivatsa S. Bhat [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F3FF50.4070701@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=tj@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.