For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan <[email protected]>
---
net/core/netprio_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 13ddd68..fc21035 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -250,6 +250,7 @@ struct cgroup_subsys net_prio_cgrp_subsys = {
.css_free = cgrp_css_free,
.attach = net_prio_attach,
.base_cftypes = ss_files,
+ .early_init = 0,
};
static int netprio_device_event(struct notifier_block *unused,
--
2.0.0-rc0
On Tue, Apr 22, 2014 at 01:32:02PM +0800, Jianyu Zhan wrote:
> For a cgroup subsystem who should init early, then it should carefully
> take care of the implementation of css_alloc, because it will be called
> before mm_init() setup the world.
>
> Luckily we don't, and we better explicitly assign the early_init field
> to 0, for document reason.
>
> Signed-off-by: Jianyu Zhan <[email protected]>
> ---
> net/core/netprio_cgroup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
> index 13ddd68..fc21035 100644
> --- a/net/core/netprio_cgroup.c
> +++ b/net/core/netprio_cgroup.c
> @@ -250,6 +250,7 @@ struct cgroup_subsys net_prio_cgrp_subsys = {
> .css_free = cgrp_css_free,
> .attach = net_prio_attach,
> .base_cftypes = ss_files,
> + .early_init = 0,
> };
>
> static int netprio_device_event(struct notifier_block *unused,
> --
> 2.0.0-rc0
>
>
NACK, for the same reason that it doesn't make sense for net_classid.
Early_init should already be zero. What problem are you trying to solve here?
Neil
On Tue, Apr 22, 2014 at 7:19 PM, Neil Horman <[email protected]> wrote:
> NACK, for the same reason that it doesn't make sense for net_classid.
> Early_init should already be zero. What problem are you trying to solve here?
Hi, Neil,
I'm sorry I should have made this more clear.
Sure, for this global variable struct, if not initailized, its all
fields will be initialized
to 0 or null(depending on its type). The point here is no to deprive
the rights of compiler/linker of doing this initialization, it is mainly for
documentation reason. Actually this field's value would affect how ->css_alloc
should implemented.
Concretely, if early_init is nonzero, then ->css_alloc *must not* call kzalloc,
because in cgroup implementation, ->css_alloc will be called earlier before
mm_init().
I don't think that the value of one field(early_init) has a so subtle
restrition on the another field(css_alloc) is a good thing, but since
it is there, docment it should be needed.
Thanks,
Jianyu Zhan
From: Jianyu Zhan <[email protected]>
Date: Tue, 22 Apr 2014 19:25:41 +0800
> I don't think that the value of one field(early_init) has a so subtle
> restrition on the another field(css_alloc) is a good thing, but since
> it is there, docment it should be needed.
This is not a reasonable change.
We depend upon implicit initialization to zero all over the kernel,
and adding explicit assignments hurts rather then helps.