On 2013/4/8 22:25, Michal Hocko wrote:
> On Mon 08-04-13 14:36:52, Li Zefan wrote:
> [...]
>> @@ -5188,12 +5154,28 @@ static int mem_cgroup_dangling_read(struct cgroup
>> *cont, struct cftype *cft,
>> struct seq_file *m)
>> {
>> struct mem_cgroup *memcg;
>> + char *memcg_name;
>> + int ret;
>
> The interface is only for debugging, all right, but that doesn't mean we
> should allocate a buffer for each read. Why cannot we simply use
> cgroup_path for seq_printf directly? Can we still race with the group
> rename?
because cgroup_path() requires the caller pass a buffer to it.
>
>> +
>> + /*
>> + * cgroup.c will do page-sized allocations most of the time,
>> + * so we'll just follow the pattern. Also, __get_free_pages
>> + * is a better interface than kmalloc for us here, because
>> + * we'd like this memory to be always billed to the root cgroup,
>> + * not to the process removing the memcg. While kmalloc would
>> + * require us to wrap it into memcg_stop/resume_kmem_account,
>> + * with __get_free_pages we just don't pass the memcg flag.
>> + */
>> + memcg_name = (char *)__get_free_pages(GFP_KERNEL, 0);
>> + if (!memcg_name)
>> + return -ENOMEM;
>>
>> mutex_lock(&dangling_memcgs_mutex);
>>
>> list_for_each_entry(memcg, &dangling_memcgs, dead) {
>> - if (memcg->memcg_name)
>> - seq_printf(m, "%s:\n", memcg->memcg_name);
>> + ret = cgroup_path(memcg->css.cgroup, memcg_name, PAGE_SIZE);
>> + if (!ret)
>> + seq_printf(m, "%s:\n", memcg_name);
>> else
>> seq_printf(m, "%p (name lost):\n", memcg);
>>
>> @@ -5203,6 +5185,7 @@ static int mem_cgroup_dangling_read(struct cgroup
>> *cont, struct cftype *cft,
>> }
>>
>> mutex_unlock(&dangling_memcgs_mutex);
>> + free_pages((unsigned long)memcg_name, 0);
>> return 0;
>> }
>> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
