[Bug ports/16418] New: ppc's get_clockfreq is racy and cancel-unsafe

[Bug ports/16418] New: ppc's get_clockfreq is racy and cancel-unsafe

[aoliva at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16418

            Bug ID: 16418
           Summary: ppc's get_clockfreq is racy and cancel-unsafe
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ports
          Assignee: unassigned at sourceware dot org
          Reporter: aoliva at sourceware dot org
                CC: carlos at redhat dot com, roland at gnu dot org

The initialization of timebase_freq enables other threads to use incorrect
values, even permanently.  One problem is that timebase_freq is wider than a
word, so writes to it may be non-atomic, and concurrent threads may see a
nonzero partially-stored value and use it.  Another is that an error value
returned by the vsyscall will be stored in it, and that value may be used by
other threads as well until the thread completes the initialization from /proc,
at which point a concurrent thread may get a value that is half the error code
and half the final value.  There should be a single atomic write to
timebase_freq, or a separate atomic flag that indicates whether the value in it
is final.

Another problem is that the open, read and close syscalls are cancellation
points.  Most /proc-reading code uses the nocancel variants of these syscall
wrappers.  This is more important than just the file descriptor leaking
problem, that is frequent for async cancellation but that should never happen
for sync cancellation: if any of these calls gets a sync cancellation,
timebase_freq will keep the error value returned by the vsyscall forever.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16418

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drepper.fsp at gmail dot com
          Component|ports                       |libc
               Host|                            |powerpc*-*-*
            Summary|ppc's get_clockfreq is racy |[powerpc] ppc's
                   |and cancel-unsafe           |get_clockfreq is racy and
                   |                            |cancel-unsafe

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16418

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[azanella at linux dot vnet.ibm.com]

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.

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

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16418

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  6b2ba95b6baab6b1789e8823c8a808e09bc98794 (commit)
      from  191220b3065c659065f8c1e5282ea6410aa47a93 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6b2ba95b6baab6b1789e8823c8a808e09bc98794

commit 6b2ba95b6baab6b1789e8823c8a808e09bc98794
Author: Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Date:   Mon Nov 24 16:18:26 2014 -0500

    BZ #16418: Fix powerpc get_clockfreq raciness

    This patch fix powerpc __get_clockfreq racy and cancel-safe issues by
    dropping internal static cache and by using nocancel file operations.
    The vDSO failure check is also removed, since kernel code does not
    return an error (it cleans cr0.so bit on function return) and the static
    code (to read value /proc) now uses non-cancellable calls.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                       |    6 +
 NEWS                                            |   18 ++--
 sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c |  128 +++++++++++------------
 3 files changed, 74 insertions(+), 78 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[azanella at linux dot vnet.ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16418

Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> ---
Fixed upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.