summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorKyeong Yoo <kyeong.yoo@alliedtelesis.co.nz>2017-07-04 07:22:38 +0300
committerRichard Weinberger <richard@nod.at>2021-12-24 00:33:41 +0300
commitaa39cc675799bc92da153af9a13d6f969c348e82 (patch)
treeefe21f0016c70e6aa2322d4aba2e32b274b08084 /README
parent50cb4373254433ad015dd50a061194c693b37c16 (diff)
downloadlinux-aa39cc675799bc92da153af9a13d6f969c348e82.tar.xz
jffs2: GC deadlock reading a page that is used in jffs2_write_begin()
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>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions