[PATCH] D101701: [nofree] Refine concurrency requirements

[Nicolai Hähnle via Phabricator via llvm-commits]

nhaehnle added a comment.

In D101701#2902713 <https://reviews.llvm.org/D101701#2902713>, @jdoerfert wrote:

>> Second, perhaps `malloc` can be `nosync`. I see the quote from the C standard, but it's unclear to me whether that language is good for anything other than ensuring no data races in a formal model, and surely there are other means to achieve the same goal, e.g. saying that a re-allocated portion of memory is a different memory location as far as the memory model is concerned. The only way I can see to perform meaningful synchronization through `free` and `malloc` would be to compare the result of malloc with some pointer that was allocated earlier (if they're equal, this implies that the earlier allocation was freed, and we have a synchronization edge that can be relied upon). It may be possible to make this undefined somehow, perhaps involving the non-determinism trick that is proposed for pointer provenance can be applied here as well.
>
> You basically described the side-channel that makes malloc/free not nosync, didn't you?
>
>   T0: foo() /* nosync */; while(1) { p = malloc(); atomic_relaxed_record(p); free(p); }
>   T1: do { p = malloc(); found = atomic_relaxed_lookup(p); free(p); } while (!found); print("foo is done!");

I'm not sure what atomic_relaxed_record/lookup are supposed to be. If they work by dereferencing `p`, then no, that's not what I had in mind. I was thinking along the lines of:

  Common setup: p = malloc(); x = 0
  T0: { x = 1; free(p); }
  T1: { while ((q = malloc()) != p) free(q); assert(x == 1) }

But maybe that's just a variation on what you had in mind. In any case, this kind of side channel is clearly ridiculous and should just be closed. I doubt many people would oppose that :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101701/new/

https://reviews.llvm.org/D101701