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/