Messages in this thread | | | Subject | Re: [PATCH] kernel_thread race | Date | Thu, 26 Aug 1999 22:52:04 -0400 | From | Jeff Dike <> |
| |
> With your patch you must be careful because the child may always be > rescheduled before the parent after a kernel_thread call
I missed the schedule() in ret_from_syscall because I didn't realize that kernel_thread (in arch/i386) actually does a system call. kernel_thread (in arch/um) just makes a procedure call, and there's no possibility I can see for the child running first.
The stuff below is right, but you missed the real problem.
> struct task_struct child_tsk = NULL; > parent() > { > kernel_thread(child); > } > child() > { > child_tsk = current; > child_tsk->something = pippo; > } > and the above can't fail.
To reiterate, the scenario is parent calls kernel_thread(child) child is created, but doesn't get to run something else calls wake_up(child_tsk), but child_tsk is NULL
BTW, this isn't a theoretical thing I noticed by staring at the code. I ran into this reliably with the user-mode kernel. fsck hit it by running memory down while reading the filesystem. I believe that the problem was triggered by my disk driver not sleeping at all. It just does file reads and writes into the hosting filesystem and returns instantaneously as far as the kernel was concerned. So there was no down time in which kswapd could get to run and initialize kswapd_process. So, try_to_free_pages came along and woke up kswapd_process, which was NULL.
So, if both parent and child can sleep before the kernel_thread returns, while something else runs and tries to wake up the child, I don't see a solution, short of having the something else sleep for a bit and hope that the child wakes up enough to set child_tsk.
Anybody have any better ideas?
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |