Ensure "init" (PID 1) also executes userret() initially

[olce]

Summary

Calling userret() from fork_return() misses the first return to
userspace of the "init" (PID 1) process. The latter is indeed created
by fork1() followed by a call to cpu_fork_kthread_handler() call that
replaces fork_return() by start_init() as the function to execute after
fork.

A new process' initial return to userspace in the end always happens
through returning from fork_exit(), so move userret() there instead to
fix the omission.

This problem was discovered as part of a revamp of scheduling priorities
that lead to experimenting with asserting and sometimes resetting
priorities in sched_userret(), in the course of which the author
stumbled on panics being triggered only in init() or only in other
processes, depending on the modifications to sched_userret(). This
change currently has no practical effect but will have some in the near
future.

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation

[markj]

How did you notice this?

sys/kern/kern_fork.c

1234

Shouldn't this move as well?

[olce]

I would have loved to be able to say it was only through thorough code analysis, and it seems I was quite close at some point. But I stumbled into it in a more "traditional way", by playing with adding behaviors and assertions in sched_userret(), and getting panics because init didn't get its priority reset correctly, whereas all other processes would, to my amazement.

sys/kern/kern_fork.c

1234

I don't think so because, if I'm not mistaken, ktrsysret() is here to log syscall returns with the return value, which is useful for a regular fork() or (a failing) exec() called from userland, but not for init's initial return because there was initially no system call to give a return value to (it's the first userland execution).

[emaste]

I think it's worth mentioning in the commit message something about how this was found, or under what conditions it would cause a practical problem -- I think it's the case that there's no practical impact (correct?) and it would be good to convey that in the message.

[olce]

In D42257#964120, @emaste wrote:

I think it's worth mentioning in the commit message something about how this was found, or under what conditions it would cause a practical problem -- I think it's the case that there's no practical impact (correct?) and it would be good to convey that in the message.

Currently, there is no practical problem, but the priority changes will introduce one. Going to amend the message as you requested.

[olce]

Indicate how the bug was found and its practical scope in the commit message.