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
| ||
|
Date: Sun, 16 May 2010 11:20:33 +0200 (CEST) From: Thomas Gleixner <tglx@...utronix.de> To: Arjan van de Ven <arjan@...radead.org> cc: Dan Magenheimer <dan.magenheimer@...cle.com>, Andi Kleen <andi@...stfloor.org>, Venkatesh Pallipadi <venki@...gle.com>, Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>, chris.mason@...cle.com, linux-kernel@...r.kernel.org Subject: Re: [PATCH] x86: Export tsc related information in sysfs On Sat, 15 May 2010, Arjan van de Ven wrote: > On Sat, 15 May 2010 15:32:51 -0700 (PDT) > Dan Magenheimer <dan.magenheimer@...cle.com> wrote: > > > > From: Arjan van de Ven [mailto:arjan@...radead.org] > > (Arjan comments reordered somewhat) > > > > > But friends don't let friends use rdtsc in application code. > > > > Um, I realize that many people have been burned by this > > many times over the years so it is a "hot stove". I also > > realize that there are many environments where using > > rdtsc is risking stepping on landmines. > > > But I (we?) also > > know there are many environments now where using rdtsc is > > NOT risky at all... > > I see a lot of Intel hardware.. (stuff that you likely don't see yet ;-) > and I have not yet seen a system where the kernel would be able to give > the guarantee as you describe it in your email. > > If you want a sysfs variable that is always 0... go wild. Nah, there are systems which will have it set to 1: Dig out your good old Pentium-I box and enjoy. > > > oh and.. what notification mechanism do you have to notify the > > > application that the tsc now is no longer reliable? Such conditions > > > can exist... for example due to a CPU being hotplugged, or some SMM > > > screwing around and the kernel detecting that or .. or ... > > > > The proposal doesn't provide a notification mechanism (though I'm > > not against it)... if the tsc can EVER become unreliable, > > tsc_reliable should be 0. > > then it should be 0 always on all of todays hardware. > SMM, thermal overload, etc etc ... you name it. > Things the kernel will get notified about... What we could expose is an estimate about the performance of gettimeofday/clock_gettime. The kernel has all the information to do that, but this still does not solve the notification problem when we need to switch to a different clock source. Thanks, tglx -- 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