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@xxxxxxx> Thanks! -- Michal Hocko SUSE Labs -- 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>