linux-kernel - Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Dec 2012 12:23:29 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	Xishi Qiu <qiuxishi@...wei.com>
Cc:	Jianguo Wu <wujianguo@...wei.com>, tj@...nel.org,
	lizefan@...wei.com, aneesh.kumar@...ux.vnet.ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Liujiang <jiang.liu@...wei.com>, dhillf@...il.com,
	Jiang Liu <liuj97@...il.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org
Subject: Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init

On Wed 12-12-12 18:44:13, Xishi Qiu wrote:
> On 2012/12/12 18:19, Michal Hocko wrote:
> 
> > On Wed 12-12-12 16:25:59, Jianguo Wu wrote:
> >> Build kernel with CONFIG_HUGETLBFS=y,CONFIG_HUGETLB_PAGE=y
> >> and CONFIG_CGROUP_HUGETLB=y, then specify hugepagesz=xx boot option,
> >> system will boot fail.
> >>
> >> This failure is caused by following code path:
> >> setup_hugepagesz
> >> 	hugetlb_add_hstate
> >> 		hugetlb_cgroup_file_init
> >> 			cgroup_add_cftypes
> >> 				kzalloc <--slab is *not available* yet
> >>
> >> For this path, slab is not available yet, so memory allocated will be
> >> failed, and cause WARN_ON() in hugetlb_cgroup_file_init().
> >>
> >> So I move hugetlb_cgroup_file_init() into hugetlb_init().
> > 
> > I do not think this is a good idea. hugetlb_init is in __init section as
> > well so what guarantees that the slab is initialized by then? Isn't this
> > just a good ordering that makes this working?
> 
> Hi Michal,
> 
> __initcall functions will be called in
> start_kernel()
> 	rest_init()  // -> slab is already
> 		kernel_init()
> 			kernel_init_freeable()
> 				do_basic_setup()
> 					do_initcalls()
> 
> and setup_hugepagesz() will be called in
> start_kernel()
> 	parse_early_param()  // -> before mm_init() -> kmem_cache_init()
> 
> Is this right?

Yes this is right. I just noticed that kmem_cache_init_late is an __init
function as well and didn't realize it is called directly. Sorry about
the confusion.
Anyway I still think it would be a better idea to move the call into the
hugetlb_cgroup_create callback where it is more logical IMO but now that
I'm looking at other controllers (blk and kmem.tcp) they all do this from
init calls as well. So it doesn't make sense to have hugetlb behave
differently.

So
Acked-by: Michal Hocko <mhocko@...e.cz>

Thanks!
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/