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

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