>> @@ -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;
>> +
>> + /*
>> + * 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);
>>
>
> I'm sorry for dawm question ...when this error happens ?
> We may get ENAMETOOLONG even with PAGE_SIZE(>=4096bytes) buffer ?
>
It does no harm to check the return value, and we don't have to
worry about if cgroup_path() will be changed to return some other
errno like ENOMEM in the future.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>