linux-kernel - Re: [PATCH] [1/3] Provide rdtscll() asm/msr.h for user space

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: <48EBD555.9060104@kernel.org>
Date:	Tue, 07 Oct 2008 14:32:05 -0700
From:	"H. Peter Anvin" <hpa@...nel.org>
To:	Andi Kleen <andi@...stfloor.org>
CC:	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [1/3] Provide rdtscll() asm/msr.h for user space

Andi Kleen wrote:
> For simple user space timing it's very useful to be able to do
> #include <asm/msr.h> instead of having to cut'n'paste the necessarily
> macros into all programs. This used to work with older kernels,
> but broke with the paravirt support (I ended up with a bunch of
> test programs that broke because of that). But it's very useful
> to have rdtscll() available somewhere in user space and asm/msr.h
> is a good place to have them.
> 
> Provide simple rdtsc/rdtscl() macros for user space too in asm/msr.h. 
> Since they are very simple I don't think they are a burden to maintain.
> 
> The diff looks bigger than it is because I moved a code block
> and diff doesn't handle it very well.

I really don't think this belongs in the kernel.  It's not even a case 
of "usable by accident" anymore, and hasn't worked for a while, so it's 
not a matter of legacy, either.

Mixing fundamentally unrelated kernel and userspace variants of the same 
function just makes the aggregation uglier than both.

(Also, most userspace variants I have seen have what the kernel calls 
"rdtscll" and calls it "rdtsc".)

I would suggest writing a <sys/tsc.h> header file and submitting to the 
glibc people, instead, or perhaps even better, start a libarch/libx86 tree.

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