Fix exec's proc state / owning_proc invariant
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 13 Jun 2018 22:16:20 +0000 (18:16 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 13 Jun 2018 22:26:00 +0000 (18:26 -0400)
commitd2e22b27a292e748f50a5f67a98addadf70a9c03
treeaaf5c2fb0111dfd8c768f62b689093323dc2d316
parenta44067a0d12b76b09441ccf8cf834e558797b3a0
Fix exec's proc state / owning_proc invariant

We had a binary that failed the load_elf() part of the mess.  That was
after owning_proc was cleared.  proc_destroy() sent the __death message,
since we were still RUNNING_S.  That was OK some of the time, but if we had
another process running, such as the parent of the
process-who-failed-to-exec, then *that* process would get hit with the
__death (which now panics).

To avoid that, we now enforce a previously unstated (and possibly
incorrect) invariant: RUNNING_S processes are the owning_proc.  I think
this is true.  If not, it warrants a closer look.

To do so, we change the process's state very early on, ideally before
blocking, such that we can save the context (in case of recoverable
errors).  We'll change the state too (to WAITING), in accordance with the
aforementioned invariant.  Since the owning_proc and the state are synced
up, we won't get any weird __death messages meant for other processes.

Since we're moving things around, including some checks that were
previously pre-goto-error-style, I attempted to clarify the error handling.
This includes setting the error codes for the load_elf, so we can get a
decent error.  (We had been getting ENOENT, which was generated inside 9ns
during the successful path walk).

It's still a nightmare, and I'll be happy the day we can get rid of exec.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/src/syscall.c