On 14.04.2016 21:08, Dave Anderson wrote:
>
>
> ----- 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.
Considering that as far back as 2.6.34 this member has been encapsulated
by CONFIG_CGROUPS I think this is unlikely, unless of course the
"patched rebuild" specifically had the ifdef guard removed. In any case
I couldn't reproduce the issue.
Also, as far as the issue concerning a possible null pointer in the
subsys array on 3.13 I too couldn't reproduce that and I tried different
varieties of cgroup hierarchies - full and partial mounts of the cgroups.
>
> Dave
>
>
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
