Still a mm bug in the fork error path

kernel/fork.c +1 -3

@@ -1104,9 +1146,7 @@
  bad_fork_cleanup_namespace:
  	exit_namespace(p);
  bad_fork_cleanup_mm:
-	exit_mm(p);
-	if (p->active_mm)
-		mmdrop(p->active_mm);
+	mmput(p->mm);
  bad_fork_cleanup_signal:
  	exit_signal(p);
  bad_fork_cleanup_sighand:

However, the new code will panic if the thread being forked is a process with a NULL mm. It looks very unlikely to be hit in the real world, but it is possible.

(My modified kernel makes it much more likely which is how I found it.) The attached patch is against 2.6.9-rc4. This time for sure!

Quoted 12 lines · John Byrne

kernel/fork.c +1 -3

@@ -1104,9 +1146,7 @@
 bad_fork_cleanup_namespace:
 	exit_namespace(p);
 bad_fork_cleanup_mm:
-	exit_mm(p);
-	if (p->active_mm)
-		mmdrop(p->active_mm);
+	mmput(p->mm);
 bad_fork_cleanup_signal:
 	exit_signal(p);
 bad_fork_cleanup_sighand:

Quoted 1 line

However, the new code will panic if the thread being forked is a process with a NULL mm. It looks very unlikely to be hit in the real world, but it is possible.

Hmm.. How does it happen? As far as I can tell, we only get here if
- copy_thread or copy_namespaces had an error
and "mm" can be NULL only for kernel threads.

Now, I don't think any kernel threads will ask for new namespaces, so copy_namespaces can't return an error. Similarly, I don't see how copy_thread() could either (at least on x86 it can only return an error if an IO bitmap allocation fails, I think - again something that shouldn't happen for kernel threads. And most other architectures will never fail at all, I do believe).

Quoted 2 lines

(My modified kernel makes it much more likely which is how I found it.) The attached patch is against 2.6.9-rc4. This time for sure!

I don't mind the patch per se, but I'd rather put it in after 2.6.9 unless you can tell me how this can actually happen with an unmodified kernel.

Linus

In my kernel, it was a SIGKILL to a forking kernel thread that caused the problem. While I see SIGKILLs being sent to some kernel threads, I don't know if any of the kernel threads ever fork. If they don't, barring a demented root user sending SIGKILLs to kernel threads, I don't know if anyone else will ever see this. So, I don't have any problems with it being fixed post 2.6.9.

In my kernel, it was a SIGKILL to a forking kernel thread that caused the problem. While I see SIGKILLs being sent to some kernel threads, I don't know if any of the kernel threads ever fork. If they don't, barring a demented root user sending SIGKILLs to kernel threads, I don't know if anyone else will ever see this. So, I don't have any problems with it being fixed post 2.6.9.