On Tue, 12 Oct 2004, John Byrne wrote:
@@ -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.
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).
(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