From: Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
To: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Oren Laadan <orenl-RdfvBDnrOiyVc3sceRu5cw@public.gmane.org>
Subject: Re: [PATCH] c/r: fix race of prepare_descendant() with an ongoing fork()
Date: Tue, 22 Sep 2009 19:41:21 -0400 [thread overview]
Message-ID: <4AB960A1.2090209@librato.com> (raw)
In-Reply-To: <20090922213858.GA30048-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org):
>> From: Oren Laadan <orenl-RdfvBDnrOiyVc3sceRu5cw@public.gmane.org>
>>
>> If prepare_descendants() is walking a tree and one of the tasks is
>> forking, one of two bads can happen. If the child doesn't inherit the
>> ->ctx, it breaks the assumption that the entire subtree is prepared.
>> If the child inherits the ->ctx, it will have one without having taken
>> a reference.
>>
>> This patch closed this race by explicitly getting and referencing the
>> ->ctx for a child process should the parent have one, atomically under
>> the tasklist_lock.
>>
>> Signed-off-by: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
>> ---
>> kernel/fork.c | 11 ++++++++---
>> 1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 9f13d7b..57118e4 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -62,6 +62,7 @@
>> #include <linux/fs_struct.h>
>> #include <linux/magic.h>
>> #include <linux/perf_counter.h>
>> +#include <linux/checkpoint.h>
>>
>> #include <asm/pgtable.h>
>> #include <asm/pgalloc.h>
>> @@ -1148,9 +1149,6 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> INIT_LIST_HEAD(&p->pi_state_list);
>> p->pi_state_cache = NULL;
>> #endif
>> -#ifdef CONFIG_CHECKPOINT
>> - p->checkpoint_ctx = NULL;
>> -#endif
>> /*
>> * sigaltstack should be cleared when sharing the same VM
>> */
>> @@ -1188,6 +1186,13 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>> /* Need tasklist lock for parent etc handling! */
>> write_lock_irq(&tasklist_lock);
>>
>> +#ifdef CONFIG_CHECKPOINT
>> + /* If parent is restarting, child should be too */
>> + if (unlikely(current->checkpoint_ctx)) {
>> + p->checkpoint_ctx = current->checkpoint_ctx;
>
> Won't break anything, but technically p->checkpoint_ctx will
> already be copied from current->checkpoint_ctx, so only the
> ckpt_ctx_get() is necessary, so this could really read
>
> if (p->checkpoint_ctx)
> ckpt_ctx_get(p->checkpoint_ctx);
>
> Right?
That's what I initially thought. However, it _is_ possible that
the following occurs:
1) Task A starts a fork an does some of copy_process(): so
@p is NULL, but copy_process() isn't complete
2) An ancestor of task A calls prepare_descendants(), which
then places a valid checkpoint_ctx on A.
That is why I placed this test-and-set snippet while holding
tasklist_lock (write): it ensure that the child has whatever
the parent has, because prepare_descendants() uses the same
lock.
Oren.
>
>> + ckpt_ctx_get(p->checkpoint_ctx);
>> + }
>> +#endif
>> /*
>> * The task hasn't been attached yet, so its cpus_allowed mask will
>> * not be changed, nor will its assigned CPU.
>> --
>> 1.6.0.4
>>
>> _______________________________________________
>> Containers mailing list
>> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
>> https://lists.linux-foundation.org/mailman/listinfo/containers
next prev parent reply other threads:[~2009-09-22 23:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 20:47 [PATCH] c/r: fix race of prepare_descendant() with an ongoing fork() Oren Laadan
[not found] ` <1253652463-11529-1-git-send-email-orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
2009-09-22 21:38 ` Serge E. Hallyn
[not found] ` <20090922213858.GA30048-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-09-22 21:46 ` Serge E. Hallyn
[not found] ` <20090922214619.GA30215-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-09-22 23:43 ` Oren Laadan
2009-09-22 23:41 ` Oren Laadan [this message]
[not found] ` <4AB960A1.2090209-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
2009-09-23 0:05 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AB960A1.2090209@librato.com \
--to=orenl-rdfvbdnroixbdgjk7y7tuq@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=orenl-RdfvBDnrOiyVc3sceRu5cw@public.gmane.org \
--cc=serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.