On Tue, May 13, 2008 at 8:21 PM, YAMAMOTO Takashi
<[EMAIL PROTECTED]> wrote:
>
> note that a failure can affect other subsystems which belong to
> the same hierarchy as well, and, even worse, a back-out attempt can also
> fail.
> i'm afraid that we need to play some kind of transaction-commit g
> >>> + BUG_ON(mm == NULL);
> >>> + BUG_ON(mm->swap_cgroup == NULL);
> >>> + if (scg == NULL) {
> >>> + /*
> >>> + * see swap_cgroup_attach.
> >>> + */
> >>> + smp_rmb();
> >>> + scg = mm->swap_cgroup;
> >> With the mm->owner patches, we need not maintain a
Andrew wrote:
> As Matt observed, this is just a poorly-named variable.
How about the following code for cgroup_file_write():
char buf[64]; /* avoid kmalloc() in small cases */
char *p;/* buf[] or kmalloc'd buffer */
...
if (nbytes < si
On Tue, May 13, 2008 at 6:30 PM, Li Zefan <[EMAIL PROTECTED]> wrote:
>
> It's a bit odd to me that cgroup_is_removed() is removed in
> cgroup_file_write(),
> but it's ressered here.
>
Fair point. It's probably better for me to be consistent.
Paul
___
>> > @@ -1518,16 +1580,21 @@ static ssize_t cgroup_file_read(struct f
>> > struct cftype *cft = __d_cft(file->f_dentry);
>> > struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);
>> >
>> > - if (!cft || cgroup_is_removed(cgrp))
>> > + if (cgroup_is_removed(cgrp))
>>
On Tue, May 13, 2008 at 2:32 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
>
> But do we ever expect that cgroup_mutex will be taken with much
> frequency, or held for much time? If it's only taken during, say,
> configuration of a group or during a query of that configuration then
> perhaps we
On Tue, May 13, 2008 at 1:08 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 12 May 2008 23:37:10 -0700
> [EMAIL PROTECTED] wrote:
>
> > + agentbuf = kmalloc(PATH_MAX, GFP_KERNEL);
> > + if (!agentbuf)
> > + goto continue_free;
> > +
On Tue, 13 May 2008 14:17:29 -0700
"Paul Menage" <[EMAIL PROTECTED]> wrote:
> On Tue, May 13, 2008 at 1:01 PM, Andrew Morton
> <[EMAIL PROTECTED]> wrote:
> >
> > This, umm, doesn't seem to do much to make the kernel a simpler place.
> >
> > Do we expect to gain much from this? Hope so... What?
On Tue, May 13, 2008 at 1:11 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 12 May 2008 23:37:13 -0700
> [EMAIL PROTECTED] wrote:
>
> > @@ -1412,14 +1355,18 @@ static struct cftype files[] = {
> > {
> > .name = "cpus",
> > .read = cpuset_common_file_re
On Tue, May 13, 2008 at 1:01 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
>
> This, umm, doesn't seem to do much to make the kernel a simpler place.
>
> Do we expect to gain much from this? Hope so... What?
>
The goal is to prevent cgroup_mutex becoming a BKL for cgroups, to
make it easier for
On Tue, May 13, 2008 at 2:23 AM, Li Zefan <[EMAIL PROTECTED]> wrote:
> > +
> > +/**
> > + * cgroup_file_lock(). Helper for cgroup read/write methods.
> > + * @cgrp: the cgroup being acted on
> > + * @cft: the control file being written to or read from
> > + * *write: true if the access is
On Tue, May 13, 2008 at 1:07 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> >
> > + /* If non-zero, defines the maximum length of string that can
> > + * be passed to write_string; defaults to 64 */
> > + int max_write_len;
>
> would size_t be a more appropriate type?
>
Probably
On Mon, 2008-05-12 at 23:37 -0700, [EMAIL PROTECTED] wrote:
> plain text document attachment (cgroup_write_string.patch)
> This patch adds a write_string() method for cgroups control files. The
> semantics are that a buffer is copied from userspace to kernelspace
> and the handler function invoked
On Tue, 13 May 2008 13:38:58 -0700
Matthew Helsley <[EMAIL PROTECTED]> wrote:
> > > + char static_buffer[64];
>
> > I'm trying to work out what protects static_buffer?
>
> One of us must be having a brain cramp because it looks to me like the
> buffer doesn't need protection -- it's on the stack.
On Tue, 2008-05-13 at 13:01 -0700, Andrew Morton wrote:
> Fear, doubt and resistance!
>
> On Mon, 12 May 2008 23:37:08 -0700
> [EMAIL PROTECTED] wrote:
>
> > Different cgroup files have different stability requirements of the
> > cgroups framework while the handler is running; currently most
> >
On Mon, 12 May 2008 23:37:13 -0700
[EMAIL PROTECTED] wrote:
> @@ -1412,14 +1355,18 @@ static struct cftype files[] = {
> {
> .name = "cpus",
> .read = cpuset_common_file_read,
> - .write = cpuset_common_file_write,
> + .write_string = updat
On Mon, 12 May 2008 23:37:10 -0700
[EMAIL PROTECTED] wrote:
> + agentbuf = kmalloc(PATH_MAX, GFP_KERNEL);
> + if (!agentbuf)
> + goto continue_free;
> + strcpy(agentbuf, cgrp->root->release_agent_path);
Did we need to allocate all that memor
On Mon, 12 May 2008 23:37:09 -0700
[EMAIL PROTECTED] wrote:
> This patch adds a write_string() method for cgroups control files. The
> semantics are that a buffer is copied from userspace to kernelspace
> and the handler function invoked on that buffer. Any control group
> locking is done after t
Fear, doubt and resistance!
On Mon, 12 May 2008 23:37:08 -0700
[EMAIL PROTECTED] wrote:
> Different cgroup files have different stability requirements of the
> cgroups framework while the handler is running; currently most
> subsystems that don't have their own internal synchronization just
> ca
[EMAIL PROTECTED] wrote:
> Different cgroup files have different stability requirements of the
> cgroups framework while the handler is running; currently most
> subsystems that don't have their own internal synchronization just
> call cgroup_lock()/cgroup_unlock(), which takes the global cgroup_mu
Different cgroup files have different stability requirements of the
cgroups framework while the handler is running; currently most
subsystems that don't have their own internal synchronization just
call cgroup_lock()/cgroup_unlock(), which takes the global cgroup_mutex.
This patch introduces a ran
Adds cgroup_release_agent_write() and cgroup_release_agent_show()
methods to handle writing/reading the path to a cgroup hierarchy's
release agent. As a result, cgroup_common_file_read() is now unnecessary.
As part of the change, a previously-tolerated race in
cgroup_release_agent() is avoided by
This patch moves the write handler for the cgroups notify_on_release
file into a separate handler. This handler requires no cgroups locking
since it relies on atomic bitops for synchronization.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c | 27 +++
Currently read_counter_write() is a raw file handler even though it's
ultimately taking a number, since in some cases it wants to
pre-process the string when converting it to a number.
This patch converts res_counter_write() from a raw file handler to a
write_string() handler; this allows some of
This patch changes attach_task_by_pid() to take a u64 rather than a
string; as a result it can be called directly as a control groups
write_u64 handler, and cgroup_common_file_write() can be removed.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cgroup.c | 67 ++
This patch converts devcgroup_access_write() from a raw file handler
into a handler for the cgroup write_string() method. This allows some
boilerplate copying/locking/checking to be removed and simplifies the
cleanup path, since these functions are performed by the cgroups
framework before calling
This patch tweaks the signatures of the update_cpumask() and
update_nodemask() functions so that they can be called directly as
handlers for the new cgroups write_string() method.
This allows cpuset_common_file_write() to be removed.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
kernel/cpu
Most of the remaining cgroup control files that implement raw file
handlers (those where the userspace pointer/length/ppos are passed
through unchanged by cgroups) appear to do so in order to have some
control over the kind of locking that their handler uses. In
particular, some handlers need to ca
This patch adds a write_string() method for cgroups control files. The
semantics are that a buffer is copied from userspace to kernelspace
and the handler function invoked on that buffer. Any control group
locking is done after the copy from userspace has occurred. The buffer
is guaranteed to be n
29 matches
Mail list logo
