On Oct 23, 2014, Torvald Riegel <triegel@xxxxxxxxxx> wrote: > I don't think it's easy to classify something as a harmless race. In general, I'd agree with you. But writing the same data onto the same memory range with code under our entire control that completes execution on any thread before returning control to any potental reader can access it is such a case IMHO. > In this case, you must make assumptions about strcpy's implementation I did, and I'm quite comfortable with them. Do you have any evidence that they don't hold, or that they might not hold, or are you just making wild speculations about compliant but entirely nonsensical implementations of strcpy that we'd likely never bring into glibc? > It could also use funny SIMD instructions or such that don't work like > normal memory accesses in a concurrent setting. As long as they don't write outside the memory area of the static char[] where we're to store the constant string forever, they should still be safe, because callers can only get to the data after their own thread finishes writing to the string. And if the caller wishes to pass the string on to another thread, then it must ensure the transfer is properly synchronized. So the only potentially dangerous case really is that of strcpy writing intermediate nonsense, or the case I discussed in my previous email, of larger-than-byte read-modify-write cycles that pick up uninitialized fragments and then, after another thread initializes those fragments, overwrite parts of the same word with the uninitialized fragments they read before. > I think there's also hardware being designed on which synchronizing > loads/stores differ from nonsynchronizing ones. It *still* wouldn't be a problem. A reader only gets a chance to read after its own writer completed (over?)writing the memory area with the bits that shall remain there forever. Given this more detailed explanation of the conditions that apply and that IMHO make it perfectly safe, do you still see any concrete error situation here? -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- 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