【openEuler-22.03-SP1】内核cgroup泄漏

【标题描述】能够简要描述问题：说明什么场景下，做了什么操作，出现什么问题（尽量使用正向表达方式）
【环境信息】
硬件信息：
1）裸机场景提供出问题的硬件信息；Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
2）虚机场景提供虚机XML文件或者配置信息
软件信息：
1） OS版本及分支:
2）内核信息:5.10.0-136.16.0.92.oe2203sp1.x86_64
3）发现问题的组件版本信息:mtos release 22.03 (LTS-SP1)
如果有特殊组网，请提供网络拓扑图
【问题复现步骤】
具体操作步骤
1.安装docker，crash，kernel-debug等，centos docker镜像。
2.将docker-cleanup.service拷贝到/usr/lib/systemd/system/docker-cleanup.service

[Unit]
Description=Docker Cleanup2
#Requires=docker.service


[Service]
Type=oneshot
ExecStart=/usr/bin/sh -c "docker ps -aq -f status=dead;exit 0"

[Install]
WantedBy=multi-user.target

3.后台执行docker_stress.sh

#!/bin/bash

while true
do
	cid=$(docker run -d  --cpu-period=100000 --cpu-quota=800000 -m 4G centos sleep 3600000)
	#echo $cid

	echo "900000" > /sys/fs/cgroup/cpu/system.slice/docker-$cid.scope/cpu.cfs_quota_us

	echo "200000" > /sys/fs/cgroup/cpu/system.slice/docker-$cid.scope/cpu.cfs_quota_us
	docker stop $cid > /dev/null
	docker rm $cid > /dev/null
done

4.后台执行docker_cleanup.sh

#!/bin/bash

while true
do
	systemctl restart docker-cleanup.service
	sleep 0.2
done

5.进入crash
6.extend ./lscgroup.so
7.struct task_group.css -o root_task_group返回的地址记录下，作为一个命令的参数
8.lscpucgroup 步骤7返回的css地址
9.出现如附件中图的红色框部分，就表示有cgroup有内存泄漏。
输入图片说明
出现概率:必现
【预期结果】
描述预期结果，可以通过对比新老版本获取
【实际结果】
描述出问题的结果
【附件信息】
比如系统message日志/组件日志、dump信息、图片等

Hi wufan618223, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers: @YangYingliang , @成坚 (CHENG Jian) , @jiaoff , @刘勇强 , @wangxiongfeng , @朱科潜 , @WangShaoBo , @lujialin , @Xu Kuohai , @冷嘲啊 , @Lingmingqiang , @yuzenghui , @juntian , @OSSIM , @陈结松 , @whoisxxx , @koulihong , @刘恺 , @hanjun-guo , @woqidaideshi , @Chiqijun , @Kefeng , @ThunderTown , @AlexGuo , @kylin-mayukun , @Zheng Zucheng , @柳歆 , @Jackie Liu , @zhujianwei001 , @郑振鹏 , @SuperSix173 , @colyli , @Zhang Yi , @htforge , @Yuehaibing , @xiehaocheng , @guzitao , @CTC-Xibo.Wang , @zhanghongchen , @chen wei , @Jason Zeng , @苟浩 , @DuanqiangWen , @georgeguo , @毛泓博 , @AllenShi , @zhangjialin , @Wei Li , @tcc@hello , @谭小飞 , @Fred Kimmy , @LiYihang , @young1c , @hucz , @WangBoe2022 , @chenke , @李力军 , @Yang Shen , @wsoydl , @sanglipeng , @zhangchangzhong , @jimmy_hero , @YGN-NDWD-Official , @Xie XiuQi , @zhengzengkai

1）此用例复现的cgroup泄漏的场景是处于 dying cgroup 的状态的cpu cgroup。此类cgroup用户态不可见，但是由于某种原因导致内核资源延迟释放，其他业务可以也可以访问到他。 dying状态是cgroup的一种常见的暂态模式 ，是一种用户态感受较好的设计模式，如果等到内核资源全部彻底释放掉，用户态才不可见，那么rmdir动作触发后会一直处于hang住的状态，并且一般情况下暂态持续时间并不长；
2）对于cpu cgroup来说，一般造成暂态的形成dying cgroup的原因是当cpu子系统的css计数为0触发的资源释放的操作是 queue_work触发的异步操作 ， 所以当队列比较繁忙时会有一点延迟，当调度到时资源就会释放 ；

static void css_release(struct percpu_ref *ref)
{
>-------struct cgroup_subsys_state *css =
>------->-------container_of(ref, struct cgroup_subsys_state, refcnt);

>-------INIT_WORK(&css->destroy_work, css_release_work_fn);
>-------queue_work(cgroup_destroy_wq, &css->destroy_work);
}

3）在本地运行用 上述复现用例 产生的处于dying cgroup是一个短暂的过程，随着进程的运行就会消失，不会产生实质性影响。

GVP openEuler / kernel

内容风险标识

评论 (2)

GVPopenEuler / kernel

内容风险标识