----- Original Message -----
... [ cut ] ...
> > And lastly, I only have one 3.14-based kernel, which shows this:
> >
> > crash> sys | grep RELEASE
> > RELEASE: 3.14.0-rc1+
> > crash> showcg
> > showcg: zero-size memory allocation! (called from 7f3280273719)
> > crash>
> >
> > which would come a cgroup_subsys_arr value of 0 from here
> >
> > en_subsys_cnt = MEMBER_SIZE("css_set", "subsys") / sizeof(void *);
> > cgroup_subsys_arr = (ulong *)GETBUF(en_subsys_cnt * sizeof(ulong));
> >
> > which depends upon CGROUP_SUBSYS_COUNT being something non-zero:
> > /*
> > * Set of subsystem states, one for each subsystem. This array is
> > * immutable after creation apart from the init_css_set during
> > * subsystem registration (at boot time).
> > */
> > struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
> >
> > And in that kernel apparently CONFIG_GROUPS was not configured and
> > therefore CGROUP_SUBSYS_COUNT is 0:
>
> But there is already logic in the initialization routine which should
> handle cases where CONFIG_CGROUP is not selected, simply by checking
> whether the "cgroups" member in task_struct exists. I checked on LXR and
> this member has always been protected by #ifdef CONFIG_CGROUPS. Maybe
> this is fedora kernel specific? Can you please take a look in the
> definition of task_struct whether the 'cgroups' member is protected by
> an ifdef guard? I can easily augment the check to consider the size of
> subsys array. I tested the code on 3.12 and on !CONFIG_CGROUPS the
> extension correctly bails out.
As I mentioned I only have the one 3.14-era kernel, and it's not a Fedora
kernel, but rather a patched rebuild of an upstream "-rc1" kernel:
crash> sys | grep RELEASE
RELEASE: 3.14.0-rc1+
crash>
I don't have the sources available, but my guess is that the member wasn't
encapsulated by CONFIG_CGROUPS at that point in time.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
