This is the mail archive of the libc-alpha@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]

Re: Consensus: data-race freedom as default for glibc code


On 11/20/2014 07:30 PM, Torvald Riegel wrote:
"C11 (internally, not exposed via headers):

       * Data-race freedom, as defined by C11 and it's memory model, is
         the default. A data race is if a possible execution contains two
         memory accesses, at least one of them is a write, at least one
         is not an atomic operation, and both are not ordered by
         happens-before. The transition to data-race freedom will be
         incremental for existing code, but new code should be
         data-race-free. If we decide to allow a data race in a certain
         situation because we reason that it is benign, this must get
         documented and needs closer inspection, repeatedly (e.g., to
         check that the generated code is okay). To avoid data races, use
         locks or atomic operations."

If you disagree with this wording, please let me know.

I agree with the idea, but I don't particularly like the term âdata race freedomâ. I think what we actually want is that glibc does not rely on (technically) undefined data races for correct operation when used correctly. It will still be very easy for programmers to use glibc functions in such a way that they suffer from data races, and the description above could be interpreted as saying that we want to change this.

To absolutely clear, what I mean is that applicable standards typically do not require any synchronization at all, and we should not start to add synchronization and defensive copies to hide data races (or at least some of their consequences). This not completely unheard of, actuallyâJava code does this a lot, but for slightly different reasons.

Anyway, we should probably avoid code like

  size_t len = strlen(input);
  char *output = malloc(len + 1); // (overflow, error checking omitted)
  strcpy(output, input);

(i.e., pre-computing a size and not checking if it has changed afterwards), but copying, say, format strings in formatted output because they could change while the formatting function is running, is over the top.

--
Florian Weimer / Red Hat Product Security


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