Re: [PATCH] mm/hugetlb: create hugetlb cgroup file in hugetlb_init

[Michal Hocko]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/