Page MenuHomeFreeBSD

kdb: Handle process enumeration before procinit()
ClosedPublic

Authored by mhorne on Aug 10 2021, 11:11 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 26 2024, 3:43 PM
Unknown Object (File)
Jan 19 2024, 8:43 PM
Unknown Object (File)
Jan 10 2024, 12:11 AM
Unknown Object (File)
Dec 25 2023, 4:38 PM
Unknown Object (File)
Dec 23 2023, 3:51 AM
Unknown Object (File)
Dec 14 2023, 10:37 PM
Unknown Object (File)
Nov 29 2023, 4:14 PM
Unknown Object (File)
Nov 28 2023, 8:08 PM
Subscribers

Details

Summary

Make kdb_thr_first() and kdb_thr_next() return sane values if the
allproc list and pidhashtbl haven't been initialized yet. This can
happen if the debugger is entered very early on, for example with the
'-d' boot flag.

This allows remote gdb to attach at such a time, and fixes some ddb
commands like 'show threads'.

Diff Detail

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

Event Timeline

This seems sane to me.

This revision is now accepted and ready to land.Aug 10 2021, 11:12 PM
sys/kern/subr_kdb.c
612

Why not check pidhashtbl != NULL instead?

656

Similarly here, we could check pidhashtbl != NULL after checking TAILQ_NEXT(thr, td_plist).

sys/kern/subr_kdb.c
612

Sure, this is slightly preferable.

656

Why is it better after this check? It doesn't seem possible for td_plist to be populated but pidhashtbl be NULL.

sys/kern/subr_kdb.c
656

It's not possible today, it just seemed very slightly cleaner to me to not make that assumption, supposing that someone might someday add a static thread1 to proc0 or something.

Update with markj's feedback. Keep the allproc initialization bit, as it may be checked early by db_ps().

This revision now requires review to proceed.Aug 11 2021, 3:04 PM
mhorne marked 3 inline comments as done.

Also give pidhashtbl a specific initial value of NULL. NFC, but semantically correct.

This revision is now accepted and ready to land.Aug 11 2021, 3:15 PM