Messages in this thread | | | Date | Fri, 6 Jan 2023 17:55:14 -0800 | Subject | Re: [PATCH] alpha: fix FEN fault handling | From | Richard Henderson <> |
| |
On 1/6/23 16:59, Al Viro wrote: > Type 3 instruction fault (FPU insn with FPU disabled) is handled > by quietly enabling FPU and returning. Which is fine, except that > we need to do that both for fault in userland and in the kernel; > the latter *can* legitimately happen - all it takes is this: > > .global _start > _start: > call_pal 0xae > lda $0, 0 > ldq $0, 0($0) > > - call_pal CLRFEN to clear "FPU enabled" flag and arrange for > a signal delivery (SIGSEGV in this case). > > Fixed by moving the handling of type 3 into the common part of > do_entIF(), before we check for kernel vs. user mode. > > Incidentally, check for kernel mode is unidiomatic; the normal > way to do that is !user_mode(regs). The difference is that > the open-coded variant treats any of bits 63..3 of regs->ps being > set as "it's user mode" while the normal approach is to check just > the bit 3. PS is a 4-bit register and regs->ps always will have > bits 63..4 clear, so the open-code variant here is actually equivalent > to !user_mode(regs). Harder to follow, though... > > Reproducer above will crash any box where CLRFEN is not ignored by > PAL (== any actual hardware, AFAICS; PAL used in qemu doesn't > bother implementing that crap).
I didn't realize I'd forgotten this in qemu. Anyway,
Reviewed-by: Richard Henderson <rth@twiddle.net>
r~
| |