Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flamenco, vm: (SIMD-0182) consume requested CUs for VM Interp failures #3656

Merged
merged 1 commit into from
Dec 27, 2024

Conversation

ravyu-jump
Copy link
Contributor

@ravyu-jump ravyu-jump commented Dec 6, 2024

WIP: Do not merge until

Implements SIMD-0182.

Agave implementation for reference

@ravyu-jump ravyu-jump marked this pull request as draft December 6, 2024 20:53
sigill: err = FD_VM_ERR_SIGILL; FD_VM_INTERP_FAULT; goto interp_halt;
sigsegv: err = FD_VM_ERR_SIGSEGV; FD_VM_INTERP_FAULT; goto interp_halt;
sigcost: err = FD_VM_ERR_SIGCOST; /* ic current */ cu = 0UL; goto interp_halt;
sigsyscall: err = FD_VM_ERR_SIGSYSCALL; /* ic current */ /* cu current */ goto interp_halt;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this changes the semantic? Syscalls return a typed error. If we change it to "syscall error", then we loose the type.

FWIW I think the SIMD is very unclear because they rely on SyscallError which is a rust thing, and it's also very unclear when it's thrown vs not. For example, memory violation inside a syscall... is that syscall error or ebpf!?

If we want to avoid syscalls (and I think we should), I think we need to store another var that says "error_because_of_syscall", not reuse the existing err.

Copy link
Contributor Author

@ravyu-jump ravyu-jump Dec 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to avoid syscalls (and I think we should), I think we need to store another var that says "error_because_of_syscall", not reuse the existing err.

This FD_VM_ERR_SIGSYSCALL is a new VM error code specifically for the purpose you mentioned. Do we need a separate variable? Would the error information that's stored in the txn_ctx suffice in that case?

FWIW I think the SIMD is very unclear because they rely on SyscallError which is a rust thing, and it's also very unclear when it's thrown vs not. For example, memory violation inside a syscall... is that syscall error or ebpf!?

Yeah it's a little confusing. I am taking it as a "read the error code output of the VM execution and determine if it was caused by a syscall" situation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's about whether or not the error was thrown in the middle of a basic block or not. Syscall errors are thrown at boundaries of basic blocks, so we don't have to set consume all the requested in the failure cases.

For example, memory violation inside a syscall... is that syscall error or ebpf!?

This is classified as a syscall error because of where it was thrown. I do agree that the SIMD can be made clearer.

@ravyu-jump ravyu-jump force-pushed the ravyu/consume-req-cu-vm-err branch from 73809da to 7b65605 Compare December 7, 2024 04:28
0x0ece
0x0ece previously approved these changes Dec 9, 2024
@ravyu-jump ravyu-jump marked this pull request as ready for review December 9, 2024 20:09
@ravyu-jump ravyu-jump force-pushed the ravyu/consume-req-cu-vm-err branch from 7b65605 to 2158441 Compare December 9, 2024 21:54
@ravyu-jump ravyu-jump force-pushed the ravyu/consume-req-cu-vm-err branch from 2158441 to 0fd0563 Compare December 10, 2024 15:39
@ravyu-jump ravyu-jump marked this pull request as draft December 10, 2024 19:39
@ravyu-jump ravyu-jump force-pushed the ravyu/consume-req-cu-vm-err branch from 0fd0563 to 6c4d7cf Compare December 26, 2024 18:29
@ravyu-jump ravyu-jump marked this pull request as ready for review December 26, 2024 18:29
@ravyu-jump ravyu-jump enabled auto-merge December 26, 2024 19:12
@ravyu-jump ravyu-jump added this pull request to the merge queue Dec 27, 2024
Merged via the queue into main with commit fe1198a Dec 27, 2024
12 checks passed
@ravyu-jump ravyu-jump deleted the ravyu/consume-req-cu-vm-err branch December 27, 2024 11:15
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.

3 participants