Change Details

I observed hangs post-r362977 in QEMU with -smp 2, in which one thread would acquire write access to an rm_lock (sysctllock) and get stuck waiting in smp_rendezvous_cpus while the other CPU was servicing a trap. The other thread was waiting for read access to the same lock, thus causing deadlock. It's clear that this is just one symptom of a larger problem. All other architectures enable interrupts for some subset of trap values, and this somehow got missed in the RISC-V port. The code in exception.S already knows to disable interrupts while handling the return from exception, so there are no changes required there.

I observed hangs post-r362977 in QEMU with -smp 2, in which one thread would acquire write access to an rm_lock (sysctllock) and get stuck waiting in smp_rendezvous_cpus while the other CPU was servicing a trap. The other thread was waiting for read access to the same lock, thus causing deadlock. It's clear that this is just one symptom of a larger problem. The general expectation of MI kernel code is that interrupts are enabled. Violating this assumption will at best create some additional latency, but otherwise might cause locking or other unforeseen issues. All other architectures do so for some subset of trap values, but this somehow got missed in the RISC-V port. Enable interrupts now during kernel page faults and all user trap types. The code in exception.S already knows to disable interrupts while handling the return from exception, so there are no changes required there.

I observed hangs post-r362977 in QEMU with -smp 2, in which one thread would acquire write access to an rm_lock (sysctllock) and get stuck waiting in smp_rendezvous_cpus while the other CPU was servicing a trap. The other thread was waiting for read access to the same lock, thus causing deadlock. It's clear that this is just one symptom of a larger problem. All otherThe general architectures enable interrupts for some subset of trap values,expectation of MI kernel code is that interrupts are enabled. and thisViolating this assumption will at best create some additional latency, but otherwise might cause locking or other unforeseen issues. All other architectures do so for some subset of trap values, but this somehow got missed in the RISC-V port port. Enable interrupts now during kernel page faults and all user trap types. The code in exception.S already knows to disable interrupts while handling the return from exception, so there are no changes required there.