This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: data-race freedom as default for glibc code
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>, "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 10:34:43 +0100
- Subject: Re: Consensus: data-race freedom as default for glibc code
- Authentication-results: sourceware.org; auth=none
- References: <1414797659 dot 10085 dot 406 dot camel at triegel dot csb> <1416508239 dot 1771 dot 61 dot camel at triegel dot csb>
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