On Mon, Jan 04, 2021 at 10:00:25AM +1000, Jonathan Matthew wrote:
> I don't have a real 586, but I can tell qemu to pretend to be one,
> which at least executes this code.
You can run regress/sys/arch/i386/f00f/ .
> Using kd_waitok here seems suspect, because if we're out of memory
> this early I can't see anything else freeing any up, but
> uvm_km_zalloc() will also sleep rather than return failure.
> Should this use kd_nowait and panic if the allocation fails instead?
Calling malloc(9) with M_WAITOK during boot is the correct way. It
will always succeed or panic in malloc() if it tries to sleep during
boot.
Although km_alloc() does not have this check, I would also call it
with kd_waitok. I don't think we will trigger sleeping during boot.
But if there is concern, better put a similar check into km_alloc()
instead of checks in every caller.
> ok?
OK bluhm@
> Index: arch/i386/i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.642
> diff -u -p -u -p -r1.642 machdep.c
> --- arch/i386/i386/machdep.c 28 Dec 2020 14:02:07 - 1.642
> +++ arch/i386/i386/machdep.c 3 Jan 2021 23:01:34 -
> @@ -3100,7 +3100,7 @@ fix_f00f(void)
> void *p;
>
> /* Allocate two new pages */
> - va = uvm_km_zalloc(kernel_map, NBPG*2);
> + va = (vaddr_t)km_alloc(NBPG*2, &kv_any, &kp_zero, &kd_waitok);
> p = (void *)(va + NBPG - 7*sizeof(*idt));
>
> /* Copy over old IDT */
