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 -0000 1.642 > +++ arch/i386/i386/machdep.c 3 Jan 2021 23:01:34 -0000 > @@ -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 */
