[Crash-utility] [PATCHv2] Add the proccgroup extension

[nborisov]

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
> 
> 
>