arm64: Don't enable interrupts when in a spinlock

[andrew]

Summary

When we receive an exception while in a spinlock we shouldn't enable
interrupts. When entering a spinlock we disable interrupts so enabling
them here could cause surprising results.

The three cases that could cause this are:

1. A break-before-make sequence
2. Accessing possibly unmapped code with a fault handler
3. Buggy code

1 and 2 are supported later in the data abort handler, and 3 should be
fixed when found.

Sponsored by: Arm Ltd

[markj]

sys/arm64/arm64/trap.c

345

IMO this shouldn't be conditional on INVARIANTS...

[andrew]

sys/arm64/arm64/trap.c

345

I think it was a KASSERT earlier, so was changes to be this to add the registers.

[markj]

sys/arm64/arm64/trap.c

345

Sure, I'm just saying that the whole block should be unconditional.

[mmel]

imho, arm32 has slightly more correct code/condition, see|: https://cgit.freebsd.org/src/tree/sys/arm/arm/trap-v6.c#n403

[markj]

In D46816#1069327, @mmel wrote:

imho, arm32 has slightly more correct code/condition, see|: https://cgit.freebsd.org/src/tree/sys/arm/arm/trap-v6.c#n403

spinlock_count > 0 implies that interrupts were disabled, so that code is a bit redundant - it could just check whether PSR_I is clear. But yes, I agree it's more correct.

[andrew]

Also check I and F flags before enabling interrupts