May be indeed remove amd64' proc0_tf now?
For instance, you might initialize thread0.td_frame with some signalling value, which could be also used to initialize other kernel threads td_frame. Hm, I think it is better than checking P_KPROC.

In D32057#723494, @kib wrote:

May be indeed remove amd64' proc0_tf now?

Yes, I think so.

For instance, you might initialize thread0.td_frame with some signalling value, which could be also used to initialize other kernel threads td_frame. Hm, I think it is better than checking P_KPROC.

Isn't it possible for some interrupt handlers to set td_frame, even for kernel threads? The default value is effectively useless for kernel threads, but the field is still used, I think.

In D32057#723598, @markj wrote:

In D32057#723494, @kib wrote:

May be indeed remove amd64' proc0_tf now?

Yes, I think so.

For instance, you might initialize thread0.td_frame with some signalling value, which could be also used to initialize other kernel threads td_frame. Hm, I think it is better than checking P_KPROC.

Isn't it possible for some interrupt handlers to set td_frame, even for kernel threads? The default value is effectively useless for kernel threads, but the field is still used, I think.

I inspected all places where td_frame is assigned for amd64 and generic kernel code (ast), and I do not think it happens.

In D32057#723623, @kib wrote:

In D32057#723598, @markj wrote:

In D32057#723494, @kib wrote:

May be indeed remove amd64' proc0_tf now?

Yes, I think so.

For instance, you might initialize thread0.td_frame with some signalling value, which could be also used to initialize other kernel threads td_frame. Hm, I think it is better than checking P_KPROC.

Isn't it possible for some interrupt handlers to set td_frame, even for kernel threads? The default value is effectively useless for kernel threads, but the field is still used, I think.

I inspected all places where td_frame is assigned for amd64 and generic kernel code (ast), and I do not think it happens.

The suggested approach is still awkward: when creating proc1, i.e., init, the new thread of course needs a valid td_frame pointer, so there is a case where the new thread should not inherit the sentinel value. So we can avoid the P_KPROC check in copy_thread(), but some similar check is still required somewhere in cpu_fork(), I believe.

In D32057#724696, @markj wrote:

The suggested approach is still awkward: when creating proc1, i.e., init, the new thread of course needs a valid td_frame pointer, so there is a case where the new thread should not inherit the sentinel value. So we can avoid the P_KPROC check in copy_thread(), but some similar check is still required somewhere in cpu_fork(), I believe.

We can do something special when creating pid 1, or rather, when setting up init for first return to usermode. But I agree that the scope of this review should be limited to proposed patch.