On 2021/08/18 15:24, Christoph Hellwig wrote: > Hi Jens, > > this series sorts out lock order reversals involving the block layer > open_mutex by drastically reducing the scope of loop_ctl_mutex. To do > so it first merges the cryptoloop module into the main loop driver > as the unregistrtion of transfers on live loop devices was causing > some nasty locking interactions. > > Diffstat: > b/drivers/block/Kconfig | 6 > b/drivers/block/Makefile | 1 > b/drivers/block/loop.c | 327 ++++++++++++++++++++++++--------------------- > b/drivers/block/loop.h | 30 ---- > drivers/block/cryptoloop.c | 204 ---------------------------- > 5 files changed, 188 insertions(+), 380 deletions(-) > Despite big change, this series introduces at least three bugs by ignoring what lock protects what resource and/or operation. Locking explanation is very very wrong. I never want this series merged for v5.14/v5.15 and stable kernels. (1) Will crash at uninitialized mutex_lock_killable(). (2) Will crash at unprotected idr_remove(). (3) Will crash syzbot due to hitting WARNING messages (at least two different causes).
