Skip to content

Conversation

@resistor
Copy link
Collaborator

@resistor resistor commented Oct 8, 2025

The existing downstream alignment handling stopped merging in
unsplittable slices if they would be unaligned. However, in this case,
we're already covering at least part of such slices with the current
partition, and that partition contains unsplittable slices, so we cannot
just stop early. This had the result that, if we ever hit that case, the
next call to advance would fail the assertion that BeginOffset didn't go
backwards.

The current single-pass implementation from upstream is complicated to
reason about, mixing correctness properties (handling of unsplittable
slices and, in our extended code, alignment) with heuristics on where to
split within those constraints. It's also done as a single pass which,
whilst workable without alignment constraints, is not in general
possible once alignment is required (at least not unless you want to
introduce the concept of head padding).

This new implementation introduces AllocaSplitCandidates, which
pre-scans the slices to determine a set of possible split points, and
AllocaSplitRequester, which takes a heuristic-based request from
AllocaSlices::partition_iterator and returns a legal split point for it
to use. It also allows multiple queries before committing to one, so the
split point can be advanced and walked back as more slices are scanned.

The intent is that, despite the new implementation, the returned
partitions are unchanged for all cases that weren't previously
incorrectly-handled. In particular, since slices only ever have
alignment other than 1 for CHERI, non-CHERI should not see any changes.

The existing downstream alignment handling stopped merging in
unsplittable slices if they would be unaligned. However, in this case,
we're already covering at least part of such slices with the current
partition, and that partition contains unsplittable slices, so we cannot
just stop early. This had the result that, if we ever hit that case, the
next call to advance would fail the assertion that BeginOffset didn't go
backwards.

The current single-pass implementation from upstream is complicated to
reason about, mixing correctness properties (handling of unsplittable
slices and, in our extended code, alignment) with heuristics on where to
split within those constraints. It's also done as a single pass which,
whilst workable without alignment constraints, is not in general
possible once alignment is required (at least not unless you want to
introduce the concept of head padding).

This new implementation introduces AllocaSplitCandidates, which
pre-scans the slices to determine a set of possible split points, and
AllocaSplitRequester, which takes a heuristic-based request from
AllocaSlices::partition_iterator and returns a legal split point for it
to use. It also allows multiple queries before committing to one, so the
split point can be advanced and walked back as more slices are scanned.

The intent is that, despite the new implementation, the returned
partitions are unchanged for all cases that weren't previously
incorrectly-handled. In particular, since slices only ever have
alignment other than 1 for CHERI, non-CHERI should not see any changes.
@resistor resistor merged commit 8261528 into CHERIoT-Platform:cheriot Oct 8, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants