Re: Differences between man-pages and libc manual safety markings

[Alexandre Oliva <aoliva-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Oct 23, 2014, Torvald Riegel <triegel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html