概要

In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDINGXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang withsmall possibility, the root cause is exactly the same as commitbed9e27baf52 ( Revert md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d )However, Dan reported another hang after that, and junxiao investigatedthe problem and found out that this is caused by plugged bio can t issuefrom raid5d().Current implementation in raid5d() has a weird dependence:1) md_check_recovery() from raid5d() must hold reconfig_mutex to clear MD_SB_CHANGE_PENDING;2) raid5d() handles IO in a deadloop, until all IO are issued;3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;This behaviour is introduce before v2.6, and for consequence, if othercontext hold reconfig_mutex , and md_check_recovery() can t updatesuper_block, then raid5d() will waste one cpu 100% by the deadloop, until reconfig_mutex is released.Refer to the implementation from raid1 and raid10, fix this problem byskipping issue IO if MD_SB_CHANGE_PENDING is still set aftermd_check_recovery(), daemon thread will be woken up when reconfig_mutex is released. Meanwhile, the hang problem will be fixed as well.

CVSS v3 指标

安全公告

影响产品