kern_thr_exit(): clear kASTs in advance

[kib]

Summary

PR: 289204

[markj]

See my comment in PR 289204: I think this isn't sufficient since it won't catch kernel thread exits (i.e., those which go through kthread_exit()).

[kib]

geom: only set TDP_GEOM for user threads

For kernel threads, ASTs are not handled at all, so there is no reason
to expect that g_waitidle() would be called through AST scheduling.

[markj]

sys/kern/kern_thr.c

351

What does "collecting scheduler locks" refer to?

352

353

354

358

Should we keep calling ask_kclear() in thread_dtor()? Are there other situations where a kernel thread may have an AST scheduled?

[kib]

sys/kern/kern_thr.c

351

Further we go down the thread exit path, more locks we acquire: process lock, thread lock, process spin lock. I mean that ASTs must be handled before we start doing that, since it is not possible to temporary drop the acquired locks.

358

For UFS SU AST, I was careful enough to not schedule it for kthreads.

I think it is better to keep ast_kclear() in destructor, to have the last line of defense against AST leak over the struct thread reallocation from exiting thread to a new thread, and to maintain AST as a generic async call mechanism.

[kib]

Grammar fixes in comment.

[markj]

sys/kern/kern_thr.c

351

I would suggest s/collecting scheduler locks/acquiring locks/.

358

Well, more typical would be to simply assert that ASTs are not scheduled for kthreads or turn ast_sched() into a no-op in that case.