On 06/13, Oleg Nesterov wrote:
>
> On 06/13, KOSAKI Motohiro wrote:
> >
> > But, again, I have no objection to your patch. because I really hope to
> > fix coredump vs oom issue.
>
> Yes, I think this is important.
Oh. And another problem, vfork() is not interruptible too. This means
that the user can hide the memory hog from oom-killer. But let's forget
about oom.
Roland, any reason it should be uninterruptible? This doesn't look good
in any case. Perhaps the pseudo-patch below makes sense?
Oleg.
--- x/kernel/fork.c
+++ x/kernel/fork.c
@@ -1359,6 +1359,26 @@ struct task_struct * __cpuinit fork_idle
return task;
}
+// ---------------------------------------------------
+// THIS SHOULD BE USED BY mm_release/coredump_wait/etc
+// ---------------------------------------------------
+void complete_vfork_done(struct task_struct *tsk)
+{
+ struct completion *vfork = xchg(tsk->vfork_done, NULL);
+ if (vfork)
+ complete(vfork);
+}
+
+static wait_for_vfork_done(struct task_struct *child, struct completion *vfork)
+{
+ if (!wait_for_completion_killable(vfork))
+ return;
+ if (xchg(child->vfork_done, NULL) != NULL)
+ return;
+ // the child has already read ->vfork_done and it should wake us up
+ wait_for_completion(vfork);
+}
+
/*
* Ok, this is the main fork-routine.
*
@@ -1433,6 +1453,7 @@ long do_fork(unsigned long clone_flags,
if (clone_flags & CLONE_VFORK) {
p->vfork_done = &vfork;
init_completion(&vfork);
+ get_task_struct(p);
}
audit_finish_fork(p);
@@ -1462,7 +1483,8 @@ long do_fork(unsigned long clone_flags,
if (clone_flags & CLONE_VFORK) {
freezer_do_not_count();
- wait_for_completion(&vfork);
+ wait_for_vfork_done(p, &vfork);
+ put_task_struct(p),
freezer_count();
tracehook_report_vfork_done(p, nr);
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>