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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyqbih4XLYtC0kAWFrEH+_uUMx_mbNsnKWKNuKQJRA3Dg@mail.gmail.com>
Date:	Mon, 6 Apr 2015 10:32:14 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris J Arges <chris.j.arges@...onical.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Rafael David Tinoco <inaddy@...ntu.com>,
	Peter Anvin <hpa@...or.com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Gema Gomez <gema.gomez-solano@...onical.com>,
	"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH] smp/call: Detect stuck CSD locks

On Mon, Apr 6, 2015 at 9:58 AM, Chris J Arges
<chris.j.arges@...onical.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/