Is acquiring `wait_lock` necessary in `kfork`?

[Sam-Ni]

Hi, I have been reading the xv6-riscv source code and have a question about the use of wait_lock in kfork.

From my understanding, wait_lock is primarily used to synchronize interactions between parent and child processes when the parent calls wait and the child calls exit. Based on this, I searched for all usages of wait_lock and found that it is mostly acquired and released in kwait and kexit.

However, I noticed one additional use in kfork, specifically here:

xv6-riscv/kernel/proc.c

Lines 297 to 299 in 5474d4b

	acquire(&wait_lock);
	np->parent = p;
	release(&wait_lock);

In this case, wait_lock is used to protect the assignment to np->parent.

I am wondering whether this protection is strictly necessary. My current reasoning is that while the current process is executing kfork, neither it nor the newly created child process can concurrently execute kwait or kexit, which seem to be the only code paths that would modify np->parent.

So it seems that there may be no concurrent access to np->parent at this point.

I might be missing something about possible interleavings or invariants here. Could you clarify whether the use of wait_lock in kfork is required for correctness, or if it is mainly for consistency with other code paths?

Thanks!