[Bug debuginfod/28339] New: groom/scan race condition

fche at redhat dot com sourceware-bugzilla@sourceware.org
Tue Sep 14 12:15:16 GMT 2021


            Bug ID: 28339
           Summary: groom/scan race condition
           Product: elfutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: debuginfod
          Assignee: fche at redhat dot com
          Reporter: fche at redhat dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

debuginfod's scan and groom operations (thread_main_scanner, 
thread_main_fts_source_paths) are intended to be mutually exclusive,
as a substitute for more complicated sql transaction batching.  (This
is because scanning / grooming involves inserting or deleting data
from multiple related tables.)

The workq class that governs this in debuginfod.cxx has a problem: if
the workq just becomes empty, its sole entry pulled by a scanner thread
in response to a wait_front(), an 'idler' groomer thread is ALSO permitted
to run, because there is no indication as to when the scanner thread
operation finishes, only when it starts.

Extending the workq with a counter ("fronters") to track any active
scanning activity (even if the workq is empty) lets us block idlers
groomers a little longer.

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

More information about the Elfutils-devel mailing list