From: Tejun Heo <tj@kernel.org>
To: Byungchul Park <byungchul.park@lge.com>
Cc: johannes.berg@intel.com, peterz@infradead.org, mingo@kernel.org,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
kernel-team@lge.com
Subject: Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks
Date: Fri, 25 Aug 2017 06:34:43 -0700 [thread overview]
Message-ID: <20170825133442.GU491396@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <1503650463-14582-1-git-send-email-byungchul.park@lge.com>
On Fri, Aug 25, 2017 at 05:41:03PM +0900, Byungchul Park wrote:
> Hello all,
>
> This is _RFC_.
>
> I want to request for comments about if it's reasonable conceptually. If
> yes, I want to resend after working it more carefully.
>
> Could you let me know your opinions about this?
>
> ----->8-----
> From 448360c343477fff63df766544eec4620657a59e Mon Sep 17 00:00:00 2001
> From: Byungchul Park <byungchul.park@lge.com>
> Date: Fri, 25 Aug 2017 17:35:07 +0900
> Subject: [RFC] workqueue: remove manual lockdep uses to detect deadlocks
>
> We introduced the following commit to detect deadlocks caused by
> wait_for_completion() in flush_{workqueue, work}() and other locks. But
> now LOCKDEP_COMPLETIONS is introduced, such works are automatically done
> by LOCKDEP_COMPLETIONS. So it doesn't have to be done manually anymore.
> Removed it.
I'm not following lockdep development, so can't really comment but if
you're saying that wq can retain the same level of protection while
not having explicit annotations, conceptually, it's of course great.
However, how would it distinguish things like flushing another work
item on a workqueue w/ max_active of 1?
Thanks.
--
tejun
next prev parent reply other threads:[~2017-08-25 13:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 8:41 [RFC] workqueue: remove manual lockdep uses to detect deadlocks Byungchul Park
2017-08-25 8:52 ` Byungchul Park
2017-08-25 13:34 ` Tejun Heo [this message]
2017-08-25 15:49 ` Byungchul Park
2017-08-29 18:57 ` Peter Zijlstra
2017-08-30 1:53 ` Byungchul Park
2017-08-30 6:23 ` Peter Zijlstra
2017-08-29 0:23 ` Byungchul Park
2017-08-28 6:55 ` Peter Zijlstra
2017-08-28 10:53 ` Byungchul Park
2017-08-29 0:55 ` Byungchul Park
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=20170825133442.GU491396@devbig577.frc2.facebook.com \
--to=tj@kernel.org \
--cc=byungchul.park@lge.com \
--cc=johannes.berg@intel.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox