linux-kernel - RE: [PATCH] x86: Export tsc related information in sysfs

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: <cab5e5a7-e204-42c1-a70b-1e2960f999f3@default>
Date:	Wed, 26 May 2010 07:26:35 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Brian Bloniarz <bmb@...enacr.com>
Cc:	john stultz <johnstul@...ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venki@...gle.com>, chris.mason@...cle.com,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH] x86: Export tsc related information in sysfs

> From: Thomas Gleixner [mailto:tglx@...utronix.de]
> 
> On Tue, 25 May 2010, Brian Bloniarz wrote:
> 
> > john stultz wrote:
> > > On Tue, 2010-05-25 at 20:16 -0400, Brian Bloniarz wrote:
> > >> On 05/24/2010 09:33 PM, Brian Bloniarz wrote:
> > >>> So what's wrong with just adding a
> > >>> /sys/devices/system/clocksource/clocksource0/tsc_khz?
> > >> As an RFC:
> > >>
> > >> Add clocksource.sys_register & sys_unregister so the
> > >> current clocksource can add supplemental information to
> > >> /sys/devices/system/clocksource/clocksource0/
> > >>
> > >> Export tsc_khz when current_clocksource==tsc so that
> > >> daemons like NTP can account for the variability of
> > >> calibration results.
> > >
> > > I think this is a bad idea, as it creates an ABI that is arch AND
> > > machine specific, which will cause portability problems in
> applications
> > > that expect the interface to be there.
> >
> > It's an arch-independent ABI that returns ENOENT on
> > unsupported platforms ;)
> >
> > Could you please explain what you envision as an
> > arch-independent solution to this problem?
> > I guess the tsc_long_calibration=1 alternative is
> > one.
> 
> Arch independent solution is to provide information about the current
> clock source in general. This is _NOT_ a TSC specific problem, you
> have the same trouble with any other clocksource which gets calibrated
> and does not take it's frequency as a constant value from boot loader,
> configuration or some CPU/chipset register. The only missing piece is
> a frequency member in struct clocksource which needs to be filled in
> by the arch/machine specific code.

Actually there is already a frequency in struct clocksource except
it's represented by the two components: mult and shift.  Maybe
it would be best to expose these instead of khz (for all clocksources)
so as to limit abuse by naive users.

So, Thomas and John, if Brian's patch is modified to provide:

/sys/devices/system/clocksource/clocksource0/current_mult
/sys/devices/system/clocksource/clocksource0/current_shift
and/or
/sys/devices/system/clocksource/clocksource0/current_khz

is that an acceptable arch-independent patch? (And which do
you prefer?)

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