possible cpu_switchto() bug. Actual issue appears to be new processes
using lwp0 instead of own memory, which is still not fixed.
Thanks to <chs> for figuring this out.
Remove entries:
- research support PT_SYSCALL & PT_STEP combined like in Linux
- GDB Remote Protocol expects a case with a step with a signal to be sent,
this is currently unsupported on NetBSD
Implemented as PT_SETSTEP and PT_CLEARSTEP.
Remove:
- support QPassSignals (PT_SET_SIGPASS/PT_GET_SIGPASS) in the kernel, a way to
stop routing a set of signals to tracer as they are uninteresting - GDB and
LLDB expect this feature
This interface has been abandoned and will be handled on the debugger level.
Sponsored by <The NetBSD Foundation>
Document PT_SETSTEP and PT_CLEARSTEP in ptrace(2).
Try to explain more details of PT_SYSCALL and PT_SYSCALLEMU.
The description of PT_*STEP has been obtained from FreeBSD.
Sponsored by <The NetBSD Foundation>
These operations allow to mark thread as a single-stepping one.
This allows to i.a.:
- single step and emit a signal (PT_SETSTEP & PT_CONTINUE)
- single step and trace syscall entry and exit (PT_SETSTEP & PT_SYSCALL)
The former is useful for debuggers like GDB or LLDB. The latter can be used
to singlestep a usermode kernel. These examples don't limit use-cases of
this interface.
Define PT_*STEP only for platforms defining PT_STEP.
Add new ATF tests setstep[1234].
These ptrace(2) operations first appeared in FreeBSD.
Sponsored by <The NetBSD Foundation>
crypto_op() waited to be set CRYPTO_F_DONE with crp->crp_cv.
However, there is context switch chances between being set CRYPTO_F_DONE in
crypto_done() and done cv_signal(crp->crp_cv) in cryptodev_cb(), that is,
cryptodev_op() thread can run to cv_destroy(crp->crp_cv) before cryptoret()
thread is waken up. As a result, cryptodev_cb() can call invalid(destroyed)
cv_signal(crp->crp_cv).
Furthermore, below two implementations cause other races.
- waiting CRYPTO_F_DONE with crp->crp_cv
- context witch chances between set CRYPTO_F_DONE and cv_signal(crp->crp_cv)
So, use other flag(CRYPTO_F_DQRETQ) for cryptodev_op() and cryptodev_key(),
and then call cv_signal(crp->crp_cv) immediately after set CRYPTO_F_DQRETQ.
Tested concurrent over 20 processes with software and hardware drivers.
- Allow encapinit to be called twice (by ifinit and ipe4_attach)
- ifinit didn't call encapinit if IPSEC is enabled (ipe4_attach called
it instead), however, on a rump kernel ipe4_attach may not be called
even if IPSEC is enabled. So we need to allow ifinit to call it anyway
christos