epoch: Move away from pointers as usize #490
Conversation
Pointers stored as `usize` tend to cause miri to lose pointer provenance tracking, which means we can't take advantage of its checking! See also the discussion at rust-lang/miri#940 (comment). This does not yet compile since `AtomicPtr` does not have `fetch_*` methods. They were added and then removed from the standard library back in the day (rust-lang/rust#10154), but I think the reason they were removed has now been remedied, so they will hopefully come back again!
jonhoo
changed the title
| fn data_with_tag<T>(data: *mut T, tag: usize) -> *mut T { | ||
| // transmute preserves pointer provenance | ||
| let data: usize = core::mem::transmute(data); | ||
| core::mem::transmute((data & !low_bits::<T>()) | (tag & low_bits::<T>())) |
There was a problem hiding this comment.
Even if the transmute preserved provenance, doing integer operations on the pointer will still kill provenance unless we do really awful things (things that we used to do but that I very happily removed when integer-ptr-casts got properly supported).
There was a problem hiding this comment.
Hmm, interesting. Is there any way to support provenance through tagged pointers then?
There was a problem hiding this comment.
See ptr_int_arithmetic removed in this commit for the awful things we used to do.
There was a problem hiding this comment.
I opened rust-lang/miri#1318 to track the Miri-side issue (and to avoid having this discussion in 4 threads in parallel^^).
|
Note in particular the (backwards-compatible) change to |
|
@jonhoo What is the current status of this PR? It seems both rust-lang/rust#71004 and rust-lang/miri#1318 were closed. |
taiki-e
added
S-waiting-on-author
|
It's.. complicated. I suspect that any time we do |
|
Miri (in its default settings) does support ptrs being cast to ints and back. Yes, provenance is lost, but that is a "feature" of int-to-ptr casts and Miri supports this. So you should be able to benefit from Miri's checking regardless. However, the memory leak checker requires provenance to be intact to "recognize" pointers that it has to follow to memory that is still alive. You can either disable the memory leak checker ( Furthermore, So... I guess what I am saying is, I am not entirely sure which problem this PR is solving. ;) IIRC it originated from discussions around the leak checker? It probably makes more sense to first get |
taiki-e
removed
the
S-waiting-on-author
796: epoch: Remove ptr-to-int casts r=taiki-e a=taiki-e Use [this hack](rust-lang/miri#1866 (comment)) to fix compatibility issues with Miri (see #490 (comment) for details). Due to the #545, still not compatible with stacked borrows. This will be fixed by the subsequent PR (#871). Note: this is a breaking change because changes API of Pointable and Pointer traits Fixes #579 881: Remove deprecated items r=taiki-e a=taiki-e This removes the following deprecated items: - crossbeam-epoch: - `CompareAndSetError` - `CompareAndSetOrdering` - `Atomic::compare_and_set` - `Atomic::compare_and_set_weak` - crossbeam-utils: - `AtomicCell::compare_and_swap` Co-authored-by: Taiki Endo <[email protected]>
796: epoch: Remove ptr-to-int casts r=taiki-e a=taiki-e Use [this hack](rust-lang/miri#1866 (comment)) to fix compatibility issues with Miri (see #490 (comment) for details). Due to the #545, still not compatible with stacked borrows. This will be fixed by the subsequent PR (#871). Note: this is a breaking change because changes API of Pointable and Pointer traits Fixes #579 Co-authored-by: Taiki Endo <[email protected]>
Pointers stored as
usizetend to cause miri to lose pointer provenancetracking, which means we can't take advantage of its checking! See also
the discussion at
rust-lang/miri#940 (comment).
This does not yet compile since
AtomicPtrdoes not havefetch_*methods. They were added and then removed from the standard library back
in the day (rust-lang/rust#10154), but I think
the reason they were removed has now been remedied, so they will
hopefully come back again!
cc @RalfJung