版本 Linux 6.5 背景 在學習cgroupv2的時候，想給子cgroup開啟cpu控制器結果失敗了： # 查看可以開啟哪些控制器 root@ubuntu-vm:/sys/fs/cgroup# cat cgroup.controllers cpuset cpu io memory hugetl ...
版本
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.
本文來自博客園，作者：摩斯電碼，未經同意，禁止轉載
