sys_exec, and probably other functions, use pcpui in such as way as to assume they don't block. that clearly isn't the case. this shows up as a bad kfree, where we try to kfree the kernel string for the etherread4 ktask. what happened is the exec started on core 0 (or some core), blocked, and then resumed on another core. when it went to free_sysc_str, it freed the string of whatever was on its old core.
at least two things:
make systrace_finish_sysc not take a kth, which cuts down on the number of pcpui uses
make sys_exec not cache pcpui.
maybe don't cache the pcpui pointer at all, except in careful places. (i think it is a little faster, but not worth the hassle in less performance-critical syscalls).
brho
commented
6 years ago
sys_exec, and probably other functions, use pcpui in such as way as to assume they don't block. that clearly isn't the case. this shows up as a bad kfree, where we try to kfree the kernel string for the etherread4 ktask. what happened is the exec started on core 0 (or some core), blocked, and then resumed on another core. when it went to free_sysc_str, it freed the string of whatever was on its old core.
at least two things: