Some fixes for kern.kstack_pages on arm64/riscv

[kib]

Summary

arm64 locore.S: fix typos

arm64, riscv: Use KSTACK_PAGES for the thread0 kstack size designator

instead of kstack_pages. Although it is correct right now to use
kstack_pages on amd64 since the kern.kstack_pages tunable is not
functional on arm64, this is too fragile and wrong on riscv.

arm64: do not disable the kern.kstack_pages tunable on arm64

Add a comment explaining what is not quite correct with arm64 and riscv.

[zlei]

Ahh, it looks sane to me ;)

[andrew]

sys/arm64/arm64/machdep.c

383

@brooks changed this in e1b610f76caa09bbc3910477da878ea5078c6569

[kib]

sys/arm64/arm64/machdep.c

383

So include of opt_kstack_pages.h needs to be added.

[kib]

include "opt_kstack_pages.h"

[markj]

sys/arm64/arm64/machdep.c

383

You might go further and make the stack size a parameter to init_proc0(). In particular, you could add a kern_stack_size field to struct arm64_bootparams and riscv_bootparams, set in locore. Then init_proc0() will make fewer assumptions about locore behaviour.

sys/kern/subr_param.c

175

[andrew]

sys/arm64/arm64/machdep.c

383

We could allocate the stack in initarm like we do on arm so it would be correctly sized.

[jhb]

sys/arm64/arm64/machdep.c

383

I think this is perhaps the best fix: allocate the real stack in C and switch to it in asm before calling mi_startup the way we do for other architectures.

[kib]

sys/arm64/arm64/machdep.c

383

I agree of course, but that would be a change of different size. Esp. taking into account some mitigations set up for arm64 stack.

Proposed change is minimal and fixes the bug at hands. Next it could be improved from there.

[markj]

sys/arm64/arm64/machdep.c

383

IMO the real bug is that machdep.c and locore.S are independently hard-coding the initial stack size. My proposal makes locore.S be the source of truth, so a similar bug cannot arise again.

[jhb]

sys/arm64/arm64/machdep.c

383

I think it would indeed be better for locore to pass along its notion of the stack size, and that we should use that if we reuse locore's stack rather than allocating a new one. Probably that can be a followup to @kib's series though?

[brooks]

I'd rather limit the use of KSTACK_PAGES as much as possible since it's prone to misuse, but this is fine if we're not going willing to fix the init_proc0 interface right now.

sys/kern/subr_param.c

178

IMO we should warn on arm64 and riscv if kstack_pages != KSTACK_PAGES.

[kib]

Add a warning about kstack_pages.

[zlei]

@kib
The fix can also be applied to stable/14, are you planning to do that ?
Ideally it can go into releng/14.0.