panic()/KERNEL_PANICKED(): Move back to using 'panicstr' as a flag

[olce]

Summary

Currently, no performance-critical path tests for a panic. Moreover, we
today have KERNEL_PANICKED() which wraps the test into
__predict_false(), already catering to those (potential) use cases.
Also, in practice we don't support 64-bit architectures without caches,
so reading an 'int' instead of a pointer doesn't (directly) save any
memory access. Finally, 'panicked' is redundant with 'panicstr' (and
wastes a tiny amount of memory).

Consequently:

1. Use again 'panicstr' as a flag indicating that the system is

panicking. To this end:

1. • Modify panic() so that it ensures this pointer is set to some non-NULL value even if the caller didn't pass any panic string.
   • Modify KERNEL_PANICKED() to test for 'panicstr'.
   • Remove 'panicked'.
2. Annotate 'panicstr' with '__read_mostly' (instead of using

'__read_frequently' as for 'panicked'). This may have to be changed if,
in the future, some performance-intensive path needs to test it.

3. Convert a few more direct tests of 'panicstr' to using

KERNEL_PANICKED().

MFC after: 2 weeks

[emaste]

sys/kern/kern_shutdown.c

901–908

This is just defensive, there are no current callers that call panic(NULL) at present, right?

[olce]

sys/kern/kern_shutdown.c

901–908

Exactly.

[kib]

sys/kern/kern_shutdown.c

918

I do not understand this conversion. Is KERNEL_PANICED() check reversed?

[olce]

Fix inverted test after panicstr => KERNEL_PANICKED() conversion.

[olce]

sys/kern/kern_shutdown.c

918

Oh yes, you're right... I tested different working scenarios but not a panic one, should have... Thanks for noticing this.