Race between `openat` and `thread_kill`

[jespiron]

Describe the bug Suppose CPU core 0 is running Thread 0 and CPU core 1 is running Thread 1. T0 is doing an openat syscall, relevant line is line 508. T1 is running thread_kill on T0 (i.e. thrd==T0), relevant line is call to kfree

Possible races:

1. If CPU 1 finishes kfree before CPU 0 executes line 508, CPU 0 will access freed memory running_thread->mother_proc (since running_thread will be freed!)
2. If CPU 1 finishes kfree after CPU 0 executes line 508, there may be some non-deterministic behavior. Note that thread_kill destroying the TCB doesn't mean that the other thread will stop executing immediately! In the above case, CPU 0 will continue executing the openat syscall made by T0 even after T0 is destroyed.

To my understanding, the above scenario is possible because the kernel supports multiprocessing, as I see support for SMP. Even if in a uniprocessor environment, the threads could interleave to create the above scenario (looking at the syscall stubs, interrupts are enabled when syscalls are made).

Suggestion Instead of cleaning up the thread immediately upon thread_kill, mark some sort of flag that the thread should be killed. Then clean up the thread when it's safe to do so, likely on the next reschedule.