From: Li Zefan <lizf@cn.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: Matt Helsley <matthltc@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
linux-pm@lists.linux-foundation.org,
Cedric Le Goater <clg@fr.ibm.com>,
"Serge E. Hallyn" <serue@us.ibm.com>
Subject: Re: [PATCH 3/5] Container Freezer: Implement freezer cgroup subsystem
Date: Tue, 04 Nov 2008 14:12:05 +0800 [thread overview]
Message-ID: <490FE7B5.8020400@cn.fujitsu.com> (raw)
In-Reply-To: <6599ad830811032143h51eae533k5b0c17e65a7fa675@mail.gmail.com>
Paul Menage wrote:
> On Mon, Aug 11, 2008 at 3:53 PM, Matt Helsley <matthltc@us.ibm.com> wrote:
>> +}
>> +
>> +static void freezer_fork(struct cgroup_subsys *ss, struct task_struct *task)
>> +{
>> + struct freezer *freezer;
>> +
>> + task_lock(task);
>> + freezer = task_freezer(task);
>> + task_unlock(task);
>> +
>> + BUG_ON(freezer->state == STATE_FROZEN);
>> + spin_lock_irq(&freezer->lock);
>> + /* Locking avoids race with FREEZING -> RUNNING transitions. */
>> + if (freezer->state == STATE_FREEZING)
>> + freeze_task(task, true);
>> + spin_unlock_irq(&freezer->lock);
>> +}
>
> Sorry for such a delayed response to this patch, but I just noticed
> (in mainline now)
> the change to move the task_lock() to only encompass the
> task_freezer() call.
>
> That results in absolutely zero protection from the task_lock() - as
> soon as you drop it, then in theory the current task could move cgroup
> and the old freezer structure be freed.
>
> Having said that, I think that in this case any locking my be
> unnecessary since task isn't on the tasklist yet, so can't be selected
> to move cgroups. (Although this does make me wonder whether
> cpuset.c:move_member_tasks_to_cpuset() can fail silently if it races
> with a fork).
>
> On top of that, for a system that configures in the cgroup freezer
> system but doesn't ever use it, every task is in the same freezer
> cgroup (the root cgroup) and task_freezer(task)->lock becomes a global
> spinlock. I think this would certainly show up on some benchmarks
> although I don't know how bad it would be in a practical sense. But it
> might be worth considering making using of the cgroup bind() callback
> to track whether or not the freezer subsystem is in use, and
> short-circuiting this in freezer_fork() without any locking if you're
> not active.
>
I think another reasonable and easier way is to disable writing freezer.state
of top cgroup, so we can skip checks in freezer_fork() for tasks in top cgroup.
next prev parent reply other threads:[~2008-11-04 6:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-11 23:53 [PATCH 0/5] Container Freezer v6: Reuse Suspend Freezer Matt Helsley
2008-08-11 23:53 ` [PATCH 1/5] Container Freezer: Add TIF_FREEZE flag to all architectures Matt Helsley
2008-08-11 23:53 ` [PATCH 2/5] Container Freezer: Make refrigerator always available Matt Helsley
2008-08-12 20:49 ` Rafael J. Wysocki
2008-08-13 1:01 ` [ProbableSpam]Re: " Matt Helsley
2008-08-13 14:31 ` Rafael J. Wysocki
2008-08-11 23:53 ` [PATCH 3/5] Container Freezer: Implement freezer cgroup subsystem Matt Helsley
2008-08-12 22:56 ` Andrew Morton
2008-08-13 2:38 ` Matt Helsley
2008-08-13 14:51 ` Rafael J. Wysocki
2008-11-04 5:43 ` Paul Menage
2008-11-04 6:12 ` Li Zefan [this message]
2008-11-04 6:40 ` Paul Menage
2008-11-04 7:25 ` Li Zefan
2008-11-04 7:35 ` [RFC][PATCH] freezer_cg: disable writing freezer.state of root cgroup Li Zefan
2008-11-04 7:56 ` Paul Menage
2008-11-04 8:01 ` Li Zefan
2008-11-05 10:18 ` Cedric Le Goater
2008-11-06 0:48 ` Paul Menage
2008-11-04 6:48 ` [PATCH] freezer_cg: remove task_lock from freezer_fork() Li Zefan
2008-08-11 23:53 ` [PATCH 4/5] Container Freezer: Skip frozen cgroups during power management resume Matt Helsley
2008-08-12 20:50 ` Rafael J. Wysocki
2008-08-11 23:53 ` [PATCH 5/5] Container Freezer: Prevent frozen tasks or cgroups from changing Matt Helsley
2008-08-12 22:44 ` [PATCH 0/5] Container Freezer v6: Reuse Suspend Freezer Andrew Morton
2008-08-13 3:47 ` [linux-pm] " Vivek Kashyap
2008-08-13 4:08 ` Andrew Morton
2008-08-15 21:54 ` Matt Helsley
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=490FE7B5.8020400@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=matthltc@us.ibm.com \
--cc=menage@google.com \
--cc=rjw@sisk.pl \
--cc=serue@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox