diff options
author | Kyeong Yoo <kyeong.yoo@alliedtelesis.co.nz> | 2017-07-04 16:22:38 +1200 |
---|---|---|
committer | Richard Weinberger <richard@nod.at> | 2021-12-23 22:33:41 +0100 |
commit | aa39cc675799bc92da153af9a13d6f969c348e82 (patch) | |
tree | efe21f0016c70e6aa2322d4aba2e32b274b08084 /drivers/mtd | |
parent | 50cb4373254433ad015dd50a061194c693b37c16 (diff) | |
download | linux-stable-aa39cc675799bc92da153af9a13d6f969c348e82.tar.gz linux-stable-aa39cc675799bc92da153af9a13d6f969c348e82.tar.bz2 linux-stable-aa39cc675799bc92da153af9a13d6f969c348e82.zip |
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 'drivers/mtd')
0 files changed, 0 insertions, 0 deletions