Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-142547

glibc: Fix race condition in tst-bz21269

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • rhel-8.10.z, rhel-9.8
    • glibc
    • None
    • Low
    • Hide
      088136aa02de6fa13061ef6f754071a5652fdabd
      e0b712dd9183d527aae4506cd39564c14af3bb28
      652b9fdb77d9fd056d4dd26dad2c14142768ab49
      369f373057073c307938da91af16922bda3dff6a
      Show
      088136aa02de6fa13061ef6f754071a5652fdabd e0b712dd9183d527aae4506cd39564c14af3bb28 652b9fdb77d9fd056d4dd26dad2c14142768ab49 369f373057073c307938da91af16922bda3dff6a
    • 1
    • rhel-pt-c-libs
    • None
    • False
    • False
    • Hide

      None

      Show
      None
    • No
    • PT C Libraries Refinement
    • None
    • None
    • Unspecified Release Note Type - Unknown
    • Unspecified
    • Unspecified
    • Unspecified
    • i686
    • None

      The misc/tst-bz21269 upstream test hangs sporadically. This has been fixed upstream:

      commit 088136aa02de6fa13061ef6f754071a5652fdabd
      Author: DJ Delorie <dj@redhat.com>
      Date:   Mon May 15 22:50:35 2023 -0400
      
          i386: Use pthread_barrier for synchronization on tst-bz21269
          
          So I was able to reproduce the hangs in the original source, and debug
          it, and fix it.  In doing so, I realized that we can't use anything
          complex to trigger the thread because that "anything" might also cause
          the expected segfault and force everything out of sync again.
          
          Here's what I ended up with, and it doesn't seem to hang where the
          original one hung quite often (in a tight while..end loop).  The key
          changes are:
          
          1. Calls to futex are error checked, with retries, to ensure that the
             futexes are actually doing what they're supposed to be doing.  In the
             original code, nearly every futex call returned an error.
          
          2. The main loop has checks for whether the thread ran or not, and
             "unlocks" the thread if it didn't (this is how the original source
             hangs).
          
          Note: the usleep() is not for timing purposes, but just to give the
          kernel an excuse to run the other thread at that time.  The test will
          not hang without it, but is more likely to test the right bugfix
          if the usleep() is present.
      

              glibc-bugzilla Platform Tools - Libraries Bot
              fweimer@redhat.com Florian Weimer
              Platform Tools - Libraries Bot Platform Tools - Libraries Bot
              Sergey Kolosov Sergey Kolosov
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: