[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A6882C0.6020302@librato.com>
Date: Thu, 23 Jul 2009 11:33:20 -0400
From: Oren Laadan <orenl@...rato.com>
To: "Serge E. Hallyn" <serue@...ibm.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...l.org>,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-api@...r.kernel.org, Dave Hansen <dave@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Pavel Emelyanov <xemul@...nvz.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Oren Laadan <orenl@...columbia.edu>
Subject: Re: [RFC v17][PATCH 22/60] c/r: external checkpoint of a task other
than ourself
Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl@...rato.com):
>> +/* setup checkpoint-specific parts of ctx */
>> +static int init_checkpoint_ctx(struct ckpt_ctx *ctx, pid_t pid)
>> +{
>> + struct task_struct *task;
>> + struct nsproxy *nsproxy;
>> + int ret;
>> +
>> + /*
>> + * No need for explicit cleanup here, because if an error
>> + * occurs then ckpt_ctx_free() is eventually called.
>> + */
>> +
>> + ctx->root_pid = pid;
>> +
>> + /* root task */
>> + read_lock(&tasklist_lock);
>> + task = find_task_by_vpid(pid);
>> + if (task)
>> + get_task_struct(task);
>> + read_unlock(&tasklist_lock);
>> + if (!task)
>> + return -ESRCH;
>> + else
>> + ctx->root_task = task;
>> +
>> + /* root nsproxy */
>> + rcu_read_lock();
>> + nsproxy = task_nsproxy(task);
>> + if (nsproxy)
>> + get_nsproxy(nsproxy);
>> + rcu_read_unlock();
>> + if (!nsproxy)
>> + return -ESRCH;
>> + else
>> + ctx->root_nsproxy = nsproxy;
>> +
>> + /* root freezer */
>> + ctx->root_freezer = task;
>> + geT_task_struct(task);
>> +
>> + ret = may_checkpoint_task(ctx, task);
>> + if (ret) {
>> + ckpt_write_err(ctx, NULL);
>> + put_task_struct(task);
>> + put_task_struct(task);
>> + put_nsproxy(nsproxy);
>
> I don't think this is safe - the ckpt_ctx_free() will
> free them a second time because you're not setting them
> to NULL, right?
Yes. Fortunately this hole chunk is removed by the 3rd-next patch.
I'll make sure it's correct here too.
Thanks,
Oren.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists