From: Jarek Poplawski <jarkao2@o2.pl>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] workqueue: debug possible lockups in flush_workqueue
Date: Thu, 19 Apr 2007 09:02:28 +0200 [thread overview]
Message-ID: <20070419070228.GC1782@ff.dom.local> (raw)
In-Reply-To: <20070419061416.GB18894@elte.hu>
On Thu, Apr 19, 2007 at 08:14:16AM +0200, Ingo Molnar wrote:
>
> * Jarek Poplawski <jarkao2@o2.pl> wrote:
>
> > Here is my patch proposal for detecting possible lockups, when
> > flush_workqueue caller holds a lock (e.g. rtnl_lock) also used in work
> > functions.
>
> looks good in principle - did you test it and it caught a bug that wasnt
> caught before?
Yes, but it was only my own testing bug... (I'm not a good tester, sorry).
>
> > +#ifdef CONFIG_PROVE_LOCKING
> > +/* Detect possible flush_workqueue() lockup with circular dependency check. */
> > +static struct lockdep_map flush_dep_map = { .name = "flush_dep_map" };
> > +#endif
>
> > +#ifdef CONFIG_PROVE_LOCKING
> > + /* lockdep dependency: flush_dep_map (read) before any lock: */
> > + lock_acquire(&flush_dep_map, 0, 0, 1, 2, _THIS_IP_);
> > +#endif
>
> i think the #ifdef should only be needed for the .name initialization -
> both lock_acquire() and lock_release() maps to NOP if PROVE_LOCKING is
> off.
There is also DEBUG_LOCK_ALLOC without PROVE_LOCKING possibility,
which isn't usable here.
Jarek P.
prev parent reply other threads:[~2007-04-19 6:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-19 5:52 [PATCH -mm] workqueue: debug possible lockups in flush_workqueue Jarek Poplawski
2007-04-19 6:14 ` Ingo Molnar
2007-04-19 7:02 ` Jarek Poplawski [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=20070419070228.GC1782@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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