TB: Track permissions on the byte-level

[yoctocell]

This makes the tracking of permissions on the byte-level, like in Stacked Borrows, which makes the tracking of interior mutable data more fine-grained.

cc @RalfJung @JoJoDeveloping

[RalfJung]

I don't understand this comment, where does the || true come from?

[yoctocell]

The true is the protected argument in new_reserved when
we enable protectors

        if ty_is_freeze || protected { Self::new_reserved_frz() } else { Self::new_reserved_im() }

[RalfJung]

Okay.... so what is the point of this comment then? I am still confused.

We do set ty_is_freeze properly here, right? So why is it relevant that the value does not matter?

[yoctocell]

The comment is more of a note. The current master branch also has a similar
comment:

miri/src/borrow_tracker/tree_borrows/mod.rs

Line 511 in 3919c4b

// Note: if we were to inline `new_reserved` below we would find out that

[JoJoDeveloping]

So, how does adding a new node work (and why do we need to call visit_freeze_sensitive three times:

• First, you do a read access at the parent node
• Then, you add the new node. Note that adding a new node is a per-block operation, not per-access
• Then you set the correct permissions for the new node
• Then you reset the SIFA thingy (also per-block)
• Then you call into the data race model

For Stacked Borrows, there are no per-block operations: each stack at each offset its own stack and completely independent from the other ones at different offsets in the same allocation. So there, more (basically everything) can be moved into the per-offset function.

So what do we do for Tree Borrows? One answer is to combine parent reading, permission setting and data race notifying together. This would be somewhat ugly, because you're constructing a node, while also accessing the tree, and this would only be fine because you're careful to not actually add the node into the children array of its parent so that it's not visited when walking the tree.

Should we do this?

[RalfJung]

Ignoring the SIFA thingy since I already forgot how it works, what I think would make sense is to do a single visit_freeze_sensitive where you

• do the parent access
• do the data race access
• prepare a RangeMap<LocationState> of per-location initial states that will later be passed to Tree::new_child

Does that makes sense or is it too ugly as well?

[JoJoDeveloping]

That would work. It has to construct an extra RangeMap but presumably this is cheaper than calling visit_freeze_sensitive thrice.
And it requires moving some logic for retags around quite a bit.

[RalfJung]

presumably this is cheaper than calling visit_freeze_sensitive thrice.

I'm not sure, but that's at least plausible. I also prefer it conceptually.