-
Notifications
You must be signed in to change notification settings - Fork 199
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
Conversation
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
There was a problem hiding this comment.
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.
73809da
to
7b65605
Compare
7b65605
to
2158441
Compare
2158441
to
0fd0563
Compare
0fd0563
to
6c4d7cf
Compare
WIP: Do not merge until
Generate fixtures + fuzz runsWill be done once Anza cuts a release for the feature gateImplements SIMD-0182.
Agave implementation for reference