版本
Linux 6.5
背景
在學習cgroupv2的時候，想給子cgroup開啟cpu控制器結果失敗了：
# 檢視可以開啟哪些控制器
root@ubuntu-vm:/sys/fs/cgroup# cat cgroup.controllers
cpuset cpu io memory hugetlb pids rdma misc
# 上面看到，是支援cpu控制器的，透過下面命令檢視目前子cgroup開啟了哪些控制器
root@ubuntu-vm:/sys/fs/cgroup# cat cgroup.subtree_control
memory pids
# 透過下面的命令給子cgroup開啟cpu控制器
root@ubuntu-vm:/sys/fs/cgroup# echo +cpu > cgroup.subtree_control
-bash: echo: write error: Invalid argument
在給子cgroup開啟cpu控制器時提示引數無效，即-EINVAL，錯誤碼是-22.
定位
之前給linux核心的function graph增加了顯示函式返回值的功能，正好可以派上用場。
- 使用下面的命令配置ftrace
echo 0 > /sys/kernel/debug/tracing/tracing_on
echo 14080 > /sys/kernel/debug/tracing/buffer_size_kb
echo ksys_write > /sys/kernel/debug/tracing/set_graph_function
echo $$ > /sys/kernel/debug/tracing/set_ftrace_pid
echo 1 > /sys/kernel/debug/tracing/options/funcgraph-retval
echo 1 > /sys/kernel/debug/tracing/options/funcgraph-retval-trim
echo function_graph > /sys/kernel/debug/tracing/current_tracer
目前社群版本還不支援funcgraph-retval-trim，這個是為了對返回值進行裁剪
然後使用下面的方法抓取log：
> /sys/kernel/debug/tracing/trace;echo 1 > /sys/kernel/debug/tracing/tracing_on; echo +cpu > cgroup.subtree_control;echo 0 > /sys/kernel/debug/tracing/tracing_on
收集到trace日誌後，從上往下搜尋-22錯誤碼，看到下面的內容：
4) | cgroup_migrate_execute() {
4) | cpu_cgroup_can_attach() {
4) | cgroup_taskset_first() {
4) 0.190 us | cgroup_taskset_next(); /* = 0xffff8881003b0000 */
4) 0.551 us | } /* cgroup_taskset_first = 0xffff8881003b0000 */
4) 0.170 us | sched_rt_can_attach(); /* = 0x1 */
4) 0.180 us | cgroup_taskset_next(); /* = 0xffff888100994e00 */
4) 0.171 us | sched_rt_can_attach(); /* = 0x1 */
4) 0.180 us | cgroup_taskset_next(); /* = 0xffff88810bed4e00 */
4) 0.170 us | sched_rt_can_attach(); /* = 0x1 */
4) 0.191 us | cgroup_taskset_next(); /* = 0xffff8881083d1a00 */
4) 0.170 us | sched_rt_can_attach(); /* = 0x1 */
4) 0.170 us | cgroup_taskset_next(); /* = 0xffff888108e20000 */
4) 0.181 us | sched_rt_can_attach(); /* = 0x0 */
4) 4.248 us | } /* cpu_cgroup_can_attach = -22 */
可以看到，cpu_cgroup_can_attach先返回了-22錯誤碼，具體分析原始碼：
#ifdef CONFIG_RT_GROUP_SCHED
static int cpu_cgroup_can_attach(struct cgroup_taskset *tset)
{
struct task_struct *task;
struct cgroup_subsys_state *css;
cgroup_taskset_for_each(task, css, tset) {
if (!sched_rt_can_attach(css_tg(css), task))
return -EINVAL;
}
return 0;
}
#endif
結合日誌和原始碼，是由於sched_rt_can_attach返回了0，才會返回-EINVAL。
繼續檢視sched_rt_can_attach：
int sched_rt_can_attach(struct task_group *tg, struct task_struct *tsk)
{
/* Don't accept realtime tasks when there is no way for them to run */
if (rt_task(tsk) && tg->rt_bandwidth.rt_runtime == 0)
return 0;
return 1;
}
返回0的條件：程式是實時程式，但是目的task group沒有給實時任務設定時間份額。
在核心文件中有下面的描述：
WARNING: cgroup2 doesn't yet support control of realtime processes and the cpu controller can only be enabled when all RT processes are in the root cgroup. Be aware that system management software may already have placed RT processes into nonroot cgroups during the system boot process, and these processes may need to be moved to the root cgroup before the cpu controller can be enabled.
上面的意思是說，在開啟CPU控制器之前，需要首先將實時任務移動到根cgroup下。
那這裡是哪個實時程式導致的呢？sched_rt_can_attach函式的第二個引數就是task_struct地址，可以藉助bpftrace檢視這個對應的哪個程式：
# cat trace.bt
#!/usr/bin/env bpftrace
kprobe:sched_rt_can_attach
{
printf("task: %lx, comm: %s\n", arg1, ((struct task_struct *)arg1)->comm);
}
執行上面的指令碼，然後再次執行開啟CPU控制器的操作，可以看到下面的日誌：
root@ubuntu-vm:~# ./trace.bt
Attaching 1 probe...
task: ffff8881003b0000, comm: systemd
task: ffff888107e38000, comm: agetty
task: ffff888107f3ce00, comm: agetty
task: ffff888107e39a00, comm: systemd-journal
task: ffff88810862b400, comm: multipathd
可以看到，最後一個程式是multipathd，這個程式是否為實時程式呢？
# ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm | grep -E 'PID|multipathd'
PID TID CLS RTPRIO NI PRI PSR %CPU STAT WCHAN COMMAND
153 153 RR 99 - 139 6 0.0 SLsl futex_wait_que multipathd
可以看到確實是實時程式。
下面手動將這個程式加到根cgroup下：
root@ubuntu-vm:/sys/fs/cgroup# cat /proc/153/cgroup
0::/system.slice/multipathd.service
root@ubuntu-vm:/sys/fs/cgroup# echo 153 > cgroup.procs
root@ubuntu-vm:/sys/fs/cgroup# cat /proc/153/cgroup
0::/
然後再次開啟CPU控制器：
root@ubuntu-vm:/sys/fs/cgroup# echo +cpu > cgroup.subtree_control
root@ubuntu-vm:/sys/fs/cgroup# cat cgroup.subtree_control
cpu memory pids
到這裡，這個問題就解決了。
如果bpftrace不能用的話，可以使用kprobe_event，下面是comm在task_struct中的偏移：
(gdb) p &((struct task_struct *)0)->comm
$1 = (char (*)[16]) 0x840
或者：
crash> *task_struct.comm -ox
struct task_struct {
[0x840] char comm[16];
}
用下面的命令新增kprobe_event，同時對ftrace進一步配置：
echo 'p sched_rt_can_attach $arg* +0x840($arg2):string' > dynamic_events
echo kprobe_ftrace_handler > /sys/kernel/debug/tracing/set_graph_notrace
echo 1 > events/kprobes/p_sched_rt_can_attach_0/enable
上面
$arg*的用法是新版本的核心才有的，藉助BTF來獲取函式的入參，比之前方便多了，可以用來輸出函式的全部入參
這個方法跟funcgraph-retval結合起來，既實現了輸出核心函式的入參，同時也輸出了核心函式的返回值
再次按照之前的方法復現一次，可以抓到下面的log：
2) | cgroup_migrate_execute() {
2) | cpu_cgroup_can_attach() {
2) | cgroup_taskset_first() {
2) 0.190 us | cgroup_taskset_next(); /* = 0xffff8881003b0000 */
2) 0.581 us | } /* cgroup_taskset_first = 0xffff8881003b0000 */
2) | sched_rt_can_attach() {
2) | /* p_sched_rt_can_attach_0: (sched_rt_can_attach+0x4/0x30) tg=0xffff88810a1b1c00 tsk=0xffff8881003b0000 arg3="systemd" */
2) 4.529 us | } /* sched_rt_can_attach = 0x1 */
2) 0.291 us | cgroup_taskset_next(); /* = 0xffff888107e38000 */
2) | sched_rt_can_attach() {
2) | /* p_sched_rt_can_attach_0: (sched_rt_can_attach+0x4/0x30) tg=0xffff88810a1b1880 tsk=0xffff888107e38000 arg3="agetty" */
2) 1.603 us | } /* sched_rt_can_attach = 0x1 */
2) 0.251 us | cgroup_taskset_next(); /* = 0xffff888107f3ce00 */
2) | sched_rt_can_attach() {
2) | /* p_sched_rt_can_attach_0: (sched_rt_can_attach+0x4/0x30) tg=0xffff88810a1b1880 tsk=0xffff888107f3ce00 arg3="agetty" */
2) 1.413 us | } /* sched_rt_can_attach = 0x1 */
2) 0.241 us | cgroup_taskset_next(); /* = 0xffff888107e39a00 */
2) | sched_rt_can_attach() {
2) | /* p_sched_rt_can_attach_0: (sched_rt_can_attach+0x4/0x30) tg=0xffff88810a1b1880 tsk=0xffff888107e39a00 arg3="systemd-journal" */
2) 2.324 us | } /* sched_rt_can_attach = 0x1 */
2) 0.250 us | cgroup_taskset_next(); /* = 0xffff88810862b400 */
2) | sched_rt_can_attach() {
2) | /* p_sched_rt_can_attach_0: (sched_rt_can_attach+0x4/0x30) tg=0xffff88810a1b1880 tsk=0xffff88810862b400 arg3="multipathd" */
2) 2.014 us | } /* sched_rt_can_attach = 0x0 */
2) + 15.820 us | } /* cpu_cgroup_can_attach = -22 */
kprobe_event的好處是，可以跟function_graph的日誌一塊結合起來看，也比較方便。上面的日誌顯示呼叫sched_rt_can_attach時，當程式是multipathd時，返回了0，進而導致cpu_cgroup_can_attach返回了-22.