"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\n\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\"Revert \"md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\"\")\n\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can't issue\nfrom raid5d().\n\nCurrent implementation in raid5d() has a weird dependence:\n\n1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear\n MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\n\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold 'reconfig_mutex', and md_check_recovery() can't update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n'reconfig_mutex' is released.\n\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'\nis released. Meanwhile, the hang problem will be fixed as well."
"value":"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao inform\u00f3 que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una peque\u00f1a posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 (\"Revertir \"md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d\") Sin embargo, Dan inform\u00f3 otro bloqueo despu\u00e9s de eso, y Junxiao investig\u00f3 el problema y descubri\u00f3 que esto se debe a que la biograf\u00eda conectada no puede emitir de raid5d(). La implementaci\u00f3n actual en raid5d() tiene una dependencia extra\u00f1a: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciar\u00e1 una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementaci\u00f3n de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todav\u00eda est\u00e1 configurado despu\u00e9s de md_check_recovery(), el hilo del daemon se activar\u00e1 cuando se publique 'reconfig_mutex'. Mientras tanto, el problema de bloqueo tambi\u00e9n se solucionar\u00e1."
