linux-kernel - Re: [RT] [RFC] simple SMI detector

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: <75b66ecd0901261823o72339347kfa70d6e54f61af00@mail.gmail.com>
Date:	Mon, 26 Jan 2009 21:23:45 -0500
From:	Lee Revell <rlrevell@...-job.com>
To:	Jon Masters <jcm@...hat.com>
Cc:	Mike Kravetz <kravetz@...ibm.com>, linux-rt-users@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	williams <williams@...hat.com>,
	"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
Subject: Re: [RT] [RFC] simple SMI detector

On Mon, Jan 26, 2009 at 12:51 PM, Jon Masters <jcm@...hat.com> wrote:
> On Sun, 2009-01-25 at 14:52 -0800, Mike Kravetz wrote:
>
>> Any reason why you could not do SMI detection in user level code running
>> at the highest RT priority?
>
> Yeah. I had some suggestions about that already...the problem with that
> is that you can't know whether measured latencies are due to SMIs /or/
> other kernel latencies - maybe there's a bug or other problem? I really
> want to be able to say to vendors "nope, it's definitely your problem".

Can't you do this with a known good version of the -rt kernel and the
latency tracer in full RT preempt mode?  SMI induced latency will show
up in the trace as long delays in random code paths where kernel
induced latency can be ruled out.

Lee
--
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/