All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: balbir@linux.vnet.ibm.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Paul Menage <menage@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Containers <containers@lists.linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] cgroups: handle failure of cgroup_populate_dir() at	mount/remount
Date: Tue, 26 May 2009 09:24:44 +0800	[thread overview]
Message-ID: <4A1B44DC.5050000@cn.fujitsu.com> (raw)
In-Reply-To: <20090525131753.GL4858@balbir.in.ibm.com>

Balbir Singh wrote:
> * Li Zefan <lizf@cn.fujitsu.com> [2009-05-22 11:00:12]:
> 
>> Now we have 'stat' file in both memory and cpuacct subsystems. If we
>> mount these 2 subsystems with option 'noprefix', the creation of 'stat'
>> file for cpuacct will fail, but without any notificatin to the user.
>>
>> With this patch, we fail the mount/remount in this case.
>>
>> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
>> ---
>>  kernel/cgroup.c |   18 ++++++++++++++++--
>>  1 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
>> index a7267bf..eab83f7 100644
>> --- a/kernel/cgroup.c
>> +++ b/kernel/cgroup.c
>> @@ -896,6 +896,7 @@ static int parse_cgroupfs_options(char *data,
>>  static int cgroup_remount(struct super_block *sb, int *flags, char *data)
>>  {
>>  	int ret = 0;
>> +	unsigned long subsys_bits;
>>  	struct cgroupfs_root *root = sb->s_fs_info;
>>  	struct cgroup *cgrp = &root->top_cgroup;
>>  	struct cgroup_sb_opts opts;
>> @@ -914,12 +915,17 @@ static int cgroup_remount(struct super_block *sb, int *flags, char *data)
>>  		goto out_unlock;
>>  	}
>>
>> +	subsys_bits = root->subsys_bits;
>>  	ret = rebind_subsystems(root, opts.subsys_bits);
>>  	if (ret)
>>  		goto out_unlock;
>>
>>  	/* (re)populate subsystem files */
>> -	cgroup_populate_dir(cgrp);
>> +	ret = cgroup_populate_dir(cgrp);
>> +	if (ret) {
> 
> if (ret) means a failure right? So we rebind_subsystems to the older
> subsys_bits? Could you please add a comment, the code can be misread.
> 

Sure.

>> +		rebind_subsystems(root, subsys_bits);
>> +		goto out_unlock;
>> +	}
>>
>>  	if (opts.release_agent)
>>  		strcpy(root->release_agent_path, opts.release_agent);
>> @@ -1122,9 +1128,13 @@ static int cgroup_get_sb(struct file_system_type *fs_type,
>>  		BUG_ON(!list_empty(&root_cgrp->children));
>>  		BUG_ON(root->number_of_cgroups != 1);
>>
>> -		cgroup_populate_dir(root_cgrp);
>> +		ret = cgroup_populate_dir(root_cgrp);
>> +
>>  		mutex_unlock(&inode->i_mutex);
>>  		mutex_unlock(&cgroup_mutex);
>> +
>> +		if (ret)
>> +			goto drop_new_super;
>>  	}
>>
>>  	simple_set_mnt(mnt, sb);
>> @@ -1803,6 +1813,10 @@ int cgroup_add_file(struct cgroup *cgrp,
>>  		dput(dentry);
>>  	} else
>>  		error = PTR_ERR(dentry);
>> +
>> +	if (error)
>> +		printk(KERN_WARNING "cgroup: Failed to create file '%s': %d\n",
>> +		       name, error);
>>  	return error;
>>  }
>>
> 
> Looks good, should we mark cgroup_populate_dir with __must_check? 
> 

Actually cgroup_populate_dir() is called in 3 cases:
  - mount
  - remount
  - mkdir

This patch only handles the former 2 cases. The return value of
cgroup_populate_dir() is also ignored when mkdir, and that piece of code
is inhereted from cpuset. I guess it's because it's hard to handle this
failure and there was no possibility of name collisions in old cpuset.

Normally name collisions can be caught when mount/remount, thus there
won't be subsequent mkdir()s.



      parent reply	other threads:[~2009-05-26  1:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-22  3:00 [PATCH] cgroups: handle failure of cgroup_populate_dir() at mount/remount Li Zefan
2009-05-22  3:00 ` Li Zefan
2009-05-22  8:25 ` KAMEZAWA Hiroyuki
2009-05-22  8:35   ` Li Zefan
2009-05-22  8:34     ` KAMEZAWA Hiroyuki
2009-05-22  9:10       ` Dhaval Giani
2009-05-25  9:14         ` Li Zefan
2009-05-25  9:47           ` Dhaval Giani
     [not found]           ` <4A1A6192.6050608-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-05-25  9:47             ` Dhaval Giani
     [not found]         ` <20090522091034.GC8696-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2009-05-25  9:14           ` Li Zefan
     [not found]       ` <20090522173421.ecacb40e.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-05-22  9:10         ` Dhaval Giani
     [not found]     ` <4A1663C2.4080401-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-05-22  8:34       ` KAMEZAWA Hiroyuki
     [not found]   ` <20090522172545.1e5e5f81.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-05-22  8:35     ` Li Zefan
2009-05-26 22:06     ` Paul Menage
2009-05-26 22:06   ` Paul Menage
     [not found]     ` <6599ad830905261506x480f2167naf1034177bbc7036-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-05-27  1:07       ` Li Zefan
2009-05-27  1:07     ` Li Zefan
     [not found]       ` <4A1C9253.3060108-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-05-27  1:34         ` KAMEZAWA Hiroyuki
2009-05-27  1:34       ` KAMEZAWA Hiroyuki
2009-05-27  3:24         ` Li Zefan
     [not found]           ` <4A1CB266.8000400-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-05-27  6:16             ` KAMEZAWA Hiroyuki
2009-05-27  6:16           ` KAMEZAWA Hiroyuki
     [not found]         ` <20090527103404.81d3c1a4.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-05-27  3:24           ` Li Zefan
     [not found] ` <4A16153C.2080004-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-05-22  8:25   ` KAMEZAWA Hiroyuki
2009-05-25 13:17   ` Balbir Singh
2009-05-25 13:17 ` Balbir Singh
     [not found]   ` <20090525131753.GL4858-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2009-05-26  1:24     ` Li Zefan
2009-05-26  1:24   ` Li Zefan [this message]

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=4A1B44DC.5050000@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.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 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.