On Wed, 2014-10-29 at 06:55 -0200, Alexandre Oliva wrote: > On Oct 27, 2014, Mark Thompson <mrt@xxxxxxxxx> wrote: > > > Now suppose we have such an implementation. Consider two distinct > > threads copying the same thing which is longer than a cache line > > "/dev/tty" (the constant string copied in the case at hand) is not > longer than a cache line (right? :-), so while your case is compelling, > it doesn't apply. That depends on the alignment of the strings. It's 9 bytes including trailing zero... > > Since strcpy will always write at least one byte, can you really argue > > that adding "*dest = 0;" to the beginning of a strcpy function is > > always a bad thing? > > Now, this one is compelling *and* fitting IMHO. > > Of course we could rule this out in glibc, but should we? Maybe not. > > So I guess we're better off fixing the implementation of ctermid(NULL) > to return a pointer to a constant string that (per POSIX) must not be > modified by the caller, rather than needlessly copying it to another > buffer. Then, if/when such a strcpy implementation comes up, we'll be > ready for it ;-) Yes, we either need to change the implementation, or make it MT-Unsafe for now. We should also review all other cases of "benign" race conditions. As this example shows, they can be not "benign" without this being easy to spot. So, IMO, we should really avoid them unless we have a strong reason not to. This will also give less false positives when using race detectors. Alex, when you did the MT Safety review, which other cases of "benign" race conditions did you see? It would be useful to revisit those, I think. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
