Page MenuHomeFreeBSD

Use KERNEL_PANICKED() in more places
ClosedPublic

Authored by mhorne on May 31 2022, 6:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, May 17, 3:30 PM
Unknown Object (File)
May 10 2024, 10:52 PM
Unknown Object (File)
May 10 2024, 3:04 AM
Unknown Object (File)
May 10 2024, 3:03 AM
Unknown Object (File)
May 9 2024, 9:30 PM
Unknown Object (File)
Feb 19 2024, 9:51 PM
Unknown Object (File)
Feb 6 2024, 1:12 PM
Unknown Object (File)
Dec 30 2023, 1:36 PM
Subscribers

Details

Summary

This is slightly more optimized than checking panicstr directly. For
most of these instances performance doesn't matter, but let's make
KERNEL_PANICKED() the common idiom.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.May 31 2022, 7:06 PM
sys/kern/subr_asan.c
390

So you didn't preserve the __predict_false here... but...

sys/kern/subr_msan.c
181

.... but you did here. Is there a reason for the difference?

sys/kern/subr_msan.c
181

the latter is a part of a bigger statement

i would argue the KERNEL_PANICKED || kdb_active thing should also be short-circuited into one macro which performs one branch

sys/kern/subr_asan.c
390

It is not obvious from this review, but KERNEL_PANICKED() expands to __predict_false(panicked).

sys/kern/subr_asan.c
390

Yea, I was wondering about the difference treatment... Though I misread the parens in at least one place.

This revision was automatically updated to reflect the committed changes.