Stream: git-wasmtime

Topic: wasmtime / PR #14619 winch: Don't treat memory_reservatio...

Wasmtime GitHub notifications bot (Oct 08 2026 at 23:49):

saulecabrera requested alexcrichton for a review on PR #14619.

Wasmtime GitHub notifications bot (Oct 08 2026 at 23:49):

saulecabrera requested wasmtime-compiler-reviewers for a review on PR #14619.

Wasmtime GitHub notifications bot (Oct 08 2026 at 23:49):

saulecabrera opened PR #14619 from saulecabrera:winch-issue-oob to bytecodealliance:main:

Closes: https://github.com/bytecodealliance/wasmtime/issues/14588

With memory_may_move disabled, Winch treated memory_reservation as an upper bound on accessible memory and turned any access whose offset + access size exceeded it into an unconditional trap. But when a memory's minimum size is larger than the reservation, the runtime sizes the allocation from the minimum instead, so in-bounds accesses past the reservation trapped spuriously.

The static out-of-bounds check now applies the reservation only when the memory's minimum byte size fits within it; otherwise the access falls through to a regular dynamic bounds check.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Oct 08 2026 at 23:49):

saulecabrera requested wasmtime-core-reviewers for a review on PR #14619.

Wasmtime GitHub notifications bot (Oct 08 2026 at 23:55):

saulecabrera edited PR #14619.

Wasmtime GitHub notifications bot (Oct 09 2026 at 00:23):

saulecabrera edited PR #14619.

Wasmtime GitHub notifications bot (Oct 09 2026 at 03:55):

github-actions[bot] added the label winch on PR #14619.

Wasmtime GitHub notifications bot (Oct 09 2026 at 03:56):

github-actions[bot] commented on PR #14619:

Subscribe to Label Action

cc @saulecabrera

<details>
This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

• saulecabrera: winch

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Oct 09 2026 at 18:33):

:memo: alexcrichton submitted PR review:

Would it make sense to perhaps just remove this clause entirely? I'm having a tough time reasoning about the precise condition here and if it works just deleting the clause related to memory-reservation outright seems like a possibly simpler approach

Wasmtime GitHub notifications bot (Oct 10 2026 at 20:29):

saulecabrera updated PR #14619.

Wasmtime GitHub notifications bot (Oct 10 2026 at 20:30):

saulecabrera edited PR #14619:

Closes: https://github.com/bytecodealliance/wasmtime/issues/14588

With memory_may_move disabled, Winch treated memory_reservation as an
upper bound on accessible memory and turned any access whose
offset + access size exceeded it into an unconditional trap. But when a
memory's minimum size is larger than the reservation, the runtime sizes
the allocation from the minimum instead, so in-bounds accesses past the
reservation trapped spuriously.

This removes the reservation clause, leaving maximum_byte_size as the
only compile-time out-of-bounds check, which matches Cranelift. Accesses
past the reservation now get the regular bounds check, which still traps
when the memory can't grow past the reservation.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Oct 10 2026 at 20:35):

saulecabrera commented on PR #14619:

That makes sense to me @alexcrichton, I was not sure as well on the original motivation for this check (and admittedly took me a bit to wrap my head around it). I've removed it in https://github.com/bytecodealliance/wasmtime/pull/14619/commits/90d3cddd3de39f7c4841242226cc6c53c5d26cf3; decided to keep the run test since there was none covering this feature.

Wasmtime GitHub notifications bot (Oct 10 2026 at 23:54):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 10 2026 at 23:54):

alexcrichton added PR #14619 winch: Don't treat memory_reservation as a bound when minimum exceeds it to the merge queue.

Wasmtime GitHub notifications bot (Oct 11 2026 at 00:17):

:check: alexcrichton merged PR #14619.

Wasmtime GitHub notifications bot (Oct 11 2026 at 00:17):

alexcrichton removed PR #14619 winch: Don't treat memory_reservation as a bound when minimum exceeds it from the merge queue.

Last updated: Oct 11 2026 at 04:10 UTC