wireguard-openbsd/sys/arch/powerpc/ddb/db_interface.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/powerpc/ddb/db_interface.c?h=jd%2Fqueueboosts 2019-11-07T15:58:39Z Substitute boolean_t/TRUE/FALSE by int/1/0. 2019-11-07T15:58:39Z mpi mpi@openbsd.org 2019-11-07T15:58:39Z urn:sha1:1d47df5535a8eecf36a407d475096db35dd70ad6 Use the debugger mutex for `ddb_mp_mutex'. This should prevent a race 2019-03-23T05:47:22Z visa visa@openbsd.org 2019-03-23T05:47:22Z urn:sha1:6c78d705e4830fa073b47e28a89f766740a85331 that could leave `ddb_mp_mutex' locked if one CPU incremented `db_active' while another CPU was in the critical section. When the race hit, the debugger was unable to resume execution or switch between CPUs. Race analyzed by patrick@ OK mpi@ patrick@ Do not panic from ddb(4) when a lock requirement isn't fulfilled. 2018-03-20T15:45:32Z mpi mpi@openbsd.org 2018-03-20T15:45:32Z urn:sha1:8ed6e35ec4a629d7af0dd1b32a143cc56dbf5b66 Extend the logic already present for panic() to any DDB-related operation such that if ddb(4) is entered because of a fault or other trap it is still possible to call 'boot reboot'. While here stop printing splassert() messages as well, to not fill the buffer. ok visa@, deraadt@ Rename Debugger() into db_enter(). 2017-04-30T16:45:45Z mpi mpi@openbsd.org 2017-04-30T16:45:45Z urn:sha1:e97088d66c8eee044cad550a3fd9fad00889544f Using a name with the 'db_' prefix makes it invisible from the dynamic profiler. ok deraadt@, kettenis@, visa@ DDB_REGS -> ddb_regs 2016-03-06T13:41:34Z mpi mpi@openbsd.org 2016-03-06T13:41:34Z urn:sha1:005d06226affe4489b739cd1e29eeb5e09afad02 One ddb interface is enough for ppc. 2016-03-05T17:41:55Z mpi mpi@openbsd.org 2016-03-05T17:41:55Z urn:sha1:89ca63b341b363fefc6a91513bb79523126d3001