问题原因
长稳测试中,频繁修改cfs_watch_dog,该路径中存在
cpus_read_lock()
smp_call_on_cpu()
cpus_read_unlock()
由于smp_call_on_cpu()中加队列操作,worker_thread中发现没有idle,化身为manager执行管理操作,创建worker。
worker_thread
maybe_create_worker
create_worker
__kthread_create_on_node
wait_for_completion_killable
wait_for_common
schedule_timeout
create_kthread
kernel_thread
_do_fork
copy_process
cgroup_threadgroup_change_begin
threadgroup_rwsem_read
此时如果有cpu上下线操作
获取了cpus_write_lock(),此时cpus_write_lock被前面得cpus_read_lock卡住,且后续cpus_read_lock也会被卡住。
此时还有cgroup_procs_write操作,写入cgroup.procs,先拿到了cgroup_threadgroup_rwsem写锁,再尝试拿cpus_read_lock,被之前cpu上下线得cpus_write_lock阻塞。
cgroup_file_write
__cgroup1_procs_write
cpus_read_lock
cgroup_threadgroup_rwsem
cgroup_attach_task
cgroup_migrate_execute
cpuset_attach
//cpus_read_lock
线程上下线启动线程中threadgroup_rwsem_read,被刺客cgroup_threadgroup_rwsem写信号量阻塞,形成死锁。
解决方案,保障cpus_read_lock一定在cgroup_threadgroup_rwsem之前上锁。考虑4.19当前cpuset_mutex在cpus_read_lock之前上锁,此时合入cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock会引起这个cpus_read_lock在cpuset_mutex之前上锁,很容易导致死锁。故回合5.4补丁,交换cpus_read_lock和cpuset_mutex锁顺序。
补丁1(cgroup/cpuset: Change cpuset_rwsem and hotplug lock order)
修改上锁顺序,保障cpus_read_lock在cpuset_mutex之前上锁。
冲突说明 :
补丁2(cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock)由于唤醒cpu执行创建或销毁任务时,可能会请求threadgroup_rwsem的读锁,因此threadgroup_rwsem需要在cpus_read_lock的保护之下。但是,cpuset的attach()函数,需要被threadgroup_rwsem的写锁保护,同时也希望禁止cpu的hotplug (这需要执行cpus_read_lock()),这样就会导致死锁。
也就是存在这样一个路径,一个唤醒cpu执行任务操作,先请求了cpus_read_lock,再请求threadgroup_rwsem的读锁。同时另一个任务执行了cpuset的attach操作,先获取了threadgroup_rwsem的写锁,去请求cpu_read_lock。两者顺序相反,导致死锁。
故解决方案为,保障cpuset在获取threadgroup_rwsem写锁之前,先拿cpu_read_lock,保障获取锁顺序一致。
补丁冲突说明 :未合入两个性能补丁,其作用在于判断某些条件不需要上锁,在上锁时加入判断。适配修改,不加判断,都上锁。
9a3284fad42f66bb43629c6716709ff791aaa457 (cgroup: Optimize single thread migration)
671c11f0619e5ccb380bcf0f062f69ba95fc974a (cgroup: Elide write-locking threadgroup_rwsem when updating csses on an empty subtree)
补丁3("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock")补丁中,遗漏cgroup_attach_task_all函数未设置cpu_read_lock就执行cpuset_attach。
冲突说明 直接引入cpus_read_lock无定义报错,引入linux/cpu.h头文件发生kabi冲突,询问因为头文件导致某些结构体的可见性发生了改变。参考主线补丁075b593f54f0f3883532cb750081cae6917bc8fe("cgroup: Use cgroup_attach_{lock,unlock}() from cgroup_attach_task_all()")把cgroup_attach_lock引入。无kabi冲突
Hi airsola0711, 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 , @zhengzengkai , @刘勇强 , @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 , @Qiuuuuu , @Yuehaibing , @xiehaocheng , @guzitao , @CTC-Xibo.Wang , @zhanghongchen , @chen wei , @Jason Zeng , @苟浩 , @DuanqiangWen , @georgeguo , @毛泓博 , @AllenShi , @zhangjialin , @zhangchangzhong , @Xie XiuQi
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
登录 后才可以发表评论