Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
On Tue, 21 Oct 2014, Aurelien Jarno wrote:
> On Thu, Oct 16, 2014 at 07:49:29PM -0400, Carlos O'Donell wrote:
> > I disagree. IMO the most flexible approach is for glibc to stop using cpuid
> > for RTM detection and rely on the kernel to tell it if RTM is usable. Then
> > we have a single hardware blacklist in the kernel. We need to talk to
> > kernel people about this. Not to mention we might extend a getauxval-type
> > API to prevent applications from using cpuid directly e.g. create a
> > platform header for this with an x86 specific feature interface.
>
> That looks like a good plan in the long term, that said if we involve
> the kernel in this it might takes months or even more until every is
> ready and in sync.
Depending on what you need, I can do the kernel side, but that's two weeks
to one month to write and test the patch, plus the time required to get it
reviewed in LKML, accepted, and merged in mainline on the *next* merge
window after it was accepted (which can be three months away worst-case).
Six months is a realistic, if a bit optimistic, target for this. If we add
the patch to the Debian kernel after it is accepted, but before it is
merged, three months.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: