From: Don Zickus <dzickus@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Eric Paris <eparis@redhat.com>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>, Ben Zhang <benzh@chromium.org>
Subject: Re: [PATCH] watchdog: print all locks on a softlock
Date: Thu, 1 May 2014 17:11:28 -0400 [thread overview]
Message-ID: <20140501211128.GC198341@redhat.com> (raw)
In-Reply-To: <20140501200858.GA27787@localhost.localdomain>
On Thu, May 01, 2014 at 10:09:01PM +0200, Frederic Weisbecker wrote:
> On Thu, May 01, 2014 at 03:17:20PM -0400, Don Zickus wrote:
> > On Thu, May 01, 2014 at 02:55:35PM -0400, Eric Paris wrote:
> > > If the CPU hits a softlockup this patch will also have it print the
> > > information about all locks being held on the system. This might help
> > > determine if a lock is being held too long leading to this problem.
> >
> > I am not sure this helps you. A softlockup is the result of pre-emption
> > disabled, ie the scheduler not being called after 60 seconds. Holding a
> > lock does not disable pre-emption usually. So I don't think this is going
> > to add anything.
> >
> > Are you trying to debug a hung task? The the hung_task thread checks to
> > see if a task hasn't scheduled in 2 minutes or so. That could be the
> > result of long lock (but that output already dumps the lockdep stuff).
>
> There may be some deadlocks that lockdep doesn't detect yet. 2 example:
>
> 1) spinlock <-> IPI dependency
>
>
> CPU 0 CPU 1
> --------------------------------------------------------
> spin_lock_irq(A)
> smp_send_function_single_async(CPU 1, func)
> //IPI
> func {
> spin_lock(1)
> }
>
> But this should be resolved with a virtual lock on the IPI functions.
> I should try that.
>
> 2) rwlock <-> IPI
>
> CPU 0 CPU 1
> --------------------------------------------------------
> read_lock(A)
> write_lock_irq(A)
> smp_send_function_single(CPU 1, func)
> //IPI never happens
The hardlockup detector would go off here. And dumping all the cpus in
the system (something we don't do today), would show this scenario. I see
this scenario a lot during page flushes on RHEL (a lot being once every
other month or so).
Cheers,
Don
>
> This one is much trickier.
>
> Anyway those are the only scenario I know of but there may be more. When possible
> we want to extend lockdep to detect new scenarios of deadlock but we don't have the
> guarantee that it can detect everything.
>
> So, could be useful...
prev parent reply other threads:[~2014-05-01 21:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-01 18:55 [PATCH] watchdog: print all locks on a softlock Eric Paris
2014-05-01 19:17 ` Don Zickus
2014-05-01 20:09 ` Frederic Weisbecker
2014-05-01 20:43 ` Frederic Weisbecker
2014-05-01 21:11 ` Don Zickus [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=20140501211128.GC198341@redhat.com \
--to=dzickus@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=benzh@chromium.org \
--cc=eparis@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
/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.