This problem was reported by [1] but the fix was incorrect. The issue is that when unix_io was made thread-safe, it was necessary that to add a CACHE_MUTEX to protect multiple threads from potentially colliding with the very simple writeback cache used by the unix_io I/O manager. The original I/O manager was purposefully kept simple, used a fixed-size cache; accordingly, the locking used also kept simple, and used a single global mutex. [1] https://lore.kernel.org/r/310fb77f-dfed-1196-c4ee-30d5138ee5a2@xxxxxxxxxx The problem was that if an application (such as e2fsck) registers a write error handler, that handler would be called with the CACHE_MUTEX still held, and if that application tried to do any I/O --- for example, closing the file system using ext2fs_close() and then exiting --- the application would deadlock. The fixes here are good enough for the use case found in e2fsprogs, and in practice there are very few other users of the error handler feature in libext2fs. *** BLURB HERE *** Theodore Ts'o (3): libext2fs: unix_io: add flag which suppresses calling the write error handler libext2fs: unix_io: fix potential error path deadlock in reuse_cache() libext2fs: unix_io: fix_potential error path deadlock in flush_cached_blocks() lib/ext2fs/unix_io.c | 151 ++++++++++++++++++++++++++++++++++++------- 1 file changed, 126 insertions(+), 25 deletions(-) -- 2.31.0
