jffs2: GC deadlock reading a page that is used in jffs2_write_begin()
authorKyeong Yoo <kyeong.yoo@alliedtelesis.co.nz>
Tue, 4 Jul 2017 04:22:38 +0000 (16:22 +1200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 27 Jan 2022 10:04:49 +0000 (11:04 +0100)
commit8c641409536dbcd4e1bf8e3704f85de1fa78b05f
tree87085f2b85c4a5838d1a53ee4b65d8e03ed68c61
parent46241ec22925290e1f5d894de3ba7280fd4865f2
jffs2: GC deadlock reading a page that is used in jffs2_write_begin()

[ Upstream commit aa39cc675799bc92da153af9a13d6f969c348e82 ]

GC task can deadlock in read_cache_page() because it may attempt
to release a page that is actually allocated by another task in
jffs2_write_begin().
The reason is that in jffs2_write_begin() there is a small window
a cache page is allocated for use but not set Uptodate yet.

This ends up with a deadlock between two tasks:
1) A task (e.g. file copy)
   - jffs2_write_begin() locks a cache page
   - jffs2_write_end() tries to lock "alloc_sem" from
 jffs2_reserve_space() <-- STUCK
2) GC task (jffs2_gcd_mtd3)
   - jffs2_garbage_collect_pass() locks "alloc_sem"
   - try to lock the same cache page in read_cache_page() <-- STUCK

So to avoid this deadlock, hold "alloc_sem" in jffs2_write_begin()
while reading data in a cache page.

Signed-off-by: Kyeong Yoo <kyeong.yoo@alliedtelesis.co.nz>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/jffs2/file.c