sunshowers requested wasmtime-core-reviewers for a review on PR #9620.
sunshowers requested alexcrichton for a review on PR #9620.
sunshowers opened PR #9620 from sunshowers:host-aligned
to bytecodealliance:main
:
As part of the work to allow mmaps to be backed by other implementations (#9544), I realized that we didn't have any way to track whether a particular usize is host-page-aligned at compile time.
Add a
HostAlignedByteCount
which tracks that a particular usize is aligned to the host page size. This also does not expose safe unchecked arithmetic operations, to ensure that overflows always error out.With
HostAlignedByteCount
, a lot of runtime checks can go away thanks to the type-level assertion.In the interest of keeping the diff relatively small, I haven't converted everything over yet. More code can be converted over as we go along.
sunshowers submitted PR review.
sunshowers created PR review comment:
This code and the similar section below would be good to convert over, but I decided to do this in a followup.
sunshowers submitted PR review.
sunshowers created PR review comment:
I first named this
AlignedByteCount
, but then realized that the VM page size might not be the same as the host page size, so named itHostAlignedByteCount
instead. Happy to rename this to something else if it makes sense.
sunshowers updated PR #9620.
sunshowers updated PR #9620.
sunshowers submitted PR review.
sunshowers created PR review comment:
Should this print the size in hex or as a decimal?
sunshowers edited PR #9620:
As part of the work to allow mmaps to be backed by other implementations (#9544), I realized that we didn't have any way to track whether a particular usize is host-page-aligned at compile time.
Add a
HostAlignedByteCount
which tracks that a particular usize is aligned to the host page size. This also does not expose safe unchecked arithmetic operations, to ensure that overflows are always handled.With
HostAlignedByteCount
, a lot of runtime checks can go away thanks to the type-level assertion.In the interest of keeping the diff relatively small, I haven't converted everything over yet. More code can be converted over as we go along.
sunshowers commented on PR #9620:
I started working on a followup as well: https://github.com/bytecodealliance/wasmtime/commit/03efe42fb4d8fdd760d945ce6ceb95b8ca338974
Unfortunately GitHub's review flow does not let you manage stacked PRs unless you have push access to the destination repo, so I'll have to put these up one at a time. Sigh :(
alexcrichton submitted PR review:
Thanks for this!
alexcrichton created PR review comment:
For here I think it's probably ok to discard the precise values that were being operated on as otherwise that makes the errors here pretty large for a low-level type such as this.
alexcrichton created PR review comment:
Mind putting this type/impls/errors/etc in a dedicated submodule of the
vm
module?
alexcrichton created PR review comment:
Same seems reasonable to me :+1:
alexcrichton created PR review comment:
Let's go with hex perhaps to clearly show that the low bits are all zero
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Reviewing some other code elsewhere, I think that the
from_file
constructor may cause problems here because file lengths aren't always page-aligned.To help catch this mind adding a
debug_assert!
tonew_unchecked
? That I think should make the test suite panic
alexcrichton commented on PR #9620:
As a heads up I'm adding https://github.com/bytecodealliance/wasmtime/pull/9614 to the merge queue which is going to have a number of conflicts with this. It should (hopefully) be just a few
#[cfg(feature = "signals-based-traps")]
in a few places but if anything is overly difficult or onerous lemme know and I can help out
sunshowers updated PR #9620.
sunshowers submitted PR review.
sunshowers created PR review comment:
Done.
sunshowers submitted PR review.
sunshowers created PR review comment:
This ended up becoming #9639.
sunshowers created PR review comment:
Hmm good point, done.
sunshowers submitted PR review.
sunshowers updated PR #9620.
sunshowers commented on PR #9620:
(Apologies for the force push -- had to do it as part of the rebase. GH makes me cry)
alexcrichton submitted PR review:
Thanks again for this!
sunshowers updated PR #9620.
sunshowers commented on PR #9620:
All right, think I fixed the Miri issue.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
I think this may be the source of the bug, albeit it's a bit indirect. Previously the
>
condition is now morally becoming>=
sincenew_accessible == self.accessible()
didn't run this block before but it's now running this block withdifference == 0
. I think then it may be the case that mprotect for 0 bytes is succeeding on unix but failing on Windows.On Linux I see
mprotect(0x740d36001000, 0, PROT_READ|PROT_WRITE) = 0
in strace with this patch when running the failing spec test and while I haven't executed this on Windows this is what I would suspect is going on.Another option is to update the
Mmap
type to skipmake_accessible
when the byte size is zero which I think would also be reasonable.
sunshowers submitted PR review.
sunshowers created PR review comment:
Oh that's terrifying -- I'm going to fix this (probably by making
make_accessible
ignore zero-sized regions) and go through this code again to make sure I didn't miss any other sign changes. Thanks for diagnosing this!
sunshowers updated PR #9620.
sunshowers created PR review comment:
Made
make_accessible
a no-op on zero-length allocations, as well as the other mprotect calls (make_executable
andmake_readonly
). They also had this as a lurking bug because they had assertions thatrange.start <= range.end
, notrange.start < range.end
.I've also added tests for zero-length calls, and re-reviewed everything -- didn't see any other changes.
sunshowers submitted PR review.
sunshowers edited PR review comment.
alexcrichton merged PR #9620.
Last updated: Dec 23 2024 at 12:05 UTC