Re: [PATCH] smp/call: Detect stuck CSD locks

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Chris J Arges <chris.j.arges@canonical.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Rafael David Tinoco <inaddy@ubuntu.com>,
	Peter Anvin <hpa@zytor.com>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Gema Gomez <gema.gomez-solano@canonical.com>,
	"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: [PATCH] smp/call: Detect stuck CSD locks
Date: Mon, 6 Apr 2015 10:32:14 -0700	[thread overview]
Message-ID: <CA+55aFyqbih4XLYtC0kAWFrEH+_uUMx_mbNsnKWKNuKQJRA3Dg@mail.gmail.com> (raw)
In-Reply-To: <5522BB49.5060704@canonical.com>

On Mon, Apr 6, 2015 at 9:58 AM, Chris J Arges
<chris.j.arges@canonical.com> wrote:
>
> I noticed that with this patch it never reached 'csd: Detected
> non-responsive CSD lock...' because it seems that ts_delta never reached
> CSD_LOCK_TIMEOUT. I tried adjusting the TIMEOUT value and still got a
> hang without reaching this statement. I made the ts0,ts1 values global
> and put a counter into the while loop and found that the loop iterated
> about 670 million times before the softlockup was detected. In addition
> ts0 and ts1 both had the same values upon soft lockup, and thus would
> never trip the CSD_LOCK_TIMEOUT check.

Sounds like jiffies stops updating. Which doesn't sound unreasonable
for when there is some IPI problem.

How about just changing the debug patch to count iterations, and print
out a warning when it reaches ten million or so.

No, that's not the right thing to do in general, but for debugging
this particular issue it's a quick hack that might just work. It's not
like re-sending the IPI is "wrong" anyway.

                         Linus