This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/16418] [powerpc] ppc's get_clockfreq is racy and cancel-unsafe


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]