This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16418] [powerpc] ppc's get_clockfreq is racy and cancel-unsafe
- From: "azanella at linux dot vnet.ibm.com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 24 Nov 2014 20:43:52 +0000
- Subject: [Bug libc/16418] [powerpc] ppc's get_clockfreq is racy and cancel-unsafe
- Auto-submitted: auto-generated
- References: <bug-16418-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16418
Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |azanella at linux dot vnet.ibm.com
--- Comment #1 from Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> ---
Checking on kernel side, both versions (powerpc32 and powerpc64) does not
return an error (both clear cr0.so bit upon return). Also, vDSO is provided
even for static-linked binaries and it is supported on minimal kernel version
current GLIBC required (2.6.32).
So I see some options:
1. Move the internal 'timebase_freq' initialization from the function itself,
initialize once and read from it).
2. Remove the internal 'timebase_freq' static car and rely on either call vDSO
or read it from /proc. I don't see this function to be a performance critical
one, so we can live it this.
2.1. The problem I see is for static build, the '__vdso_get_tbfreq' won't be
defined (since it is not initialized on 'VDSO_SETUP'. However I don't see a
problem on enabling vDSO support for static builds.
2.2. Instead of just relying of vDSO for static, provide a static fallback
using the _nocancel variations.
I intend to fix it by implementing 2.2.
--
You are receiving this mail because:
You are on the CC list for the bug.