When creating a new thread, we unconditionally copy td_frame from the
creating thread. For threads which never return to user mode, this is
unnecessary since td_frame just points to the base of the stack or a
random interrupt frame.
If KASAN is configured this copying can trigger false positives since
the td_frame region may contain poisoned stack regions. It was not
noticed before since thread0 used a dummy proc0_tf trapframe, and kernel
procs are generally created by thread0. Since commit
df8dd6025af88a99d34f549fa9591a9b8f9b75b1, though, we call
cpu_thread_alloc(&thread0), which sets thread0.td_frame. In particular,
I think proc0_tf serves no purpose now.
Work around the problem by not copying the frame unless the copying
thread came from user mode. While here, de-duplicate the copying and
remove redundant re(initialization) of td_frame.
Reported by: firstname.lastname@example.org