DDB can be running in the interrupt context, e.g., when activated from
console. Therefore, we use kmem_intr_alloc(9) and friends in order to
avoid assertion failure.
Exceptions: when we're only testing whether it's there, not about to
dereference it.
Note: We do not use atomic_store_release to set it because the
preceding mutex_exit should be enough.
(That said, it's not clear the mutex_enter/exit is needed unless
refcnt > 0 already, in which case maybe it would be a win to switch
from the membar implied by mutex_enter to the membar implied by
atomic_store_release -- which I would generally expect to be much
cheaper. And a little clearer without a long comment.)
Exceptions: when fd_refcnt <= 1, or when holding fd_lock.
While here:
- Restore KASSERT(mutex_owned(&fdp->fd_lock)) in fd_unused.
=> This is used only in fd_close and fd_abort, where it holds.
- Move bounds check assertion in fd_putfile to where it matters.
- Store fd_dt with atomic_store_release.
- Move load of fd_dt under lock in knote_fdclose.
- Omit membar_consumer in fdesc_readdir.
=> atomic_load_consume serves the same purpose now.
=> Was needed only on alpha anyway.
where curcpu() is defined as curlwp->l_cpu:
- mi_switch(): undo the ~2007ish optimisation to unlock curlwp before
calling cpu_switchto(). It's not safe to let other actors mess with the
LWP (in particular l->l_cpu) while it's still context switching. This
removes l->l_ctxswtch.
- Move the LP_RUNNING flag into l->l_flag and rename to LW_RUNNING since
it's now covered by the LWP's lock.
- Ditch lwp_exit_switchaway() and just call mi_switch() instead. Everything
is in cache anyway so it wasn't buying much by trying to avoid saving old
state. This means cpu_switchto() will never be called with prevlwp ==
NULL.
- Remove some KERNEL_LOCK handling which hasn't been needed for years.
the system is shutting down or rebooting.
- Set this global in a new function called kern_reboot(), which is currently
just a basic wrapper around cpu_reboot().
- Call kern_reboot() instead of cpu_reboot() almost everywhere; a few
places remain where it's still called directly, but those are in early
pre-main() machdep locations.
Eventually, all of the various cpu_reboot() functions should be re-factored
and common functionality moved to kern_reboot(), but that's for another day.
The former is what DDB repl calls. The latter performs the actual
input so let other code use it without the unwanted db> prompt. It's
already used by ACPI (and AcpiOsWaitCommandReady supplies its own
prompt). I also use it for my uncommitted Forth scripting for DDB.
or the user's terminal.
kind of wrong to be called db_*() when they'll typically be used
outside of ddb itself, but db_stacktrace() itself is no different.
fix this by making the stack trace support separate from ddb?
stops on '\0'. Probably this doesn't matter a lot because the read is
supposed to be safe, but let's not have bugs in the debugger.
Detected by kASan, via skrll@ on aarch64, by typing "ps/l" on DDB.
(christos has a good idea to add a function that does all 3,
and we should switch all the callers in this sequence to use
it (and fix the MD ones missing it still). not all can, as
eg, line-grabbing functions can use cngetsn(), which only
calls cnpollc() twice.)
- interrupts can work afterwards
- this also means if IO stalls, serial break might work again.
this mimics how reboot(2) ends up calling cpu_reboot().
minimal lockdebug checks in place, even without LOCKDEBUG.
adjust lockdebug_abort() to ignore problems after ld_panic is set
so that there's a chance of this working.
this fixes ddb 'reboot' on softiron od1000.
skrll