[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.56.0804131126080.28138@keg.few.vu.nl>
Date: Sun, 13 Apr 2008 11:44:46 +0200 (CEST)
From: Erik Bosman <ejbosman@...vu.nl>
To: Andi Kleen <andi@...stfloor.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Arjan van de Ven <arjan@...radead.org>,
Andrea Arcangeli <andrea@...share.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] Add prctl commands PR_GET_TSC and PR_SET_TSC
On Sun, 13 Apr 2008, Andi Kleen wrote:
> Erik Bosman <ebn310@....vu.nl> writes:
>
> > This patch adds prctl commands that make it possible
> > to deny the execution of timestamp counters in userspace.
> > If this is not implemented on a specific architecture,
> > prctl will return -EINVAL.
>
> You forgot to state why you need that?
>
> -Andi
>
I'm using it for deterministic replay. With this trap it is
possible to emulate the instruction using ptrace and knowing
the outcome. Deterministic replay can be useful, amongst other
things, for debugging and security (instructing your debugger
to undo instructions for example, to see what happened before
a fault.)
Not having this trap means emulation should be used to catch
the instruction, leading to bad performance.
Without the timestamp counter, the only instruction leading
to non-determinism (that I'm aware of) is the CPUID instruction
that returns on which core it runs, but that doesn't seem to
be used that much.
Erik Bosman
--
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/
Powered by blists - more mailing lists