diff options
| author | Miaohe Lin <linmiaohe@huawei.com> | 2022-04-29 14:40:43 +0800 |
|---|---|---|
| committer | akpm <akpm@linux-foundation.org> | 2022-05-27 09:33:44 -0700 |
| commit | 04094226d6ce8c0cb590891e13872109aa6722f1 (patch) | |
| tree | 02723a23b7785dff1502ea3335bd6560fe76dcb0 /mm/mlock.c | |
| parent | 4a1c3839108afcfec02f4d62d6862b2451b442ab (diff) | |
| download | linux-04094226d6ce8c0cb590891e13872109aa6722f1.tar.bz2 | |
mm/z3fold: fix z3fold_reclaim_page races with z3fold_free
Think about the below scenario:
CPU1 CPU2
z3fold_reclaim_page z3fold_free
spin_lock(&pool->lock) get_z3fold_header -- hold page_lock
kref_get_unless_zero
kref_put--zhdr->refcount can be 1 now
!z3fold_page_trylock
kref_put -- zhdr->refcount is 0 now
release_z3fold_page
WARN_ON(!list_empty(&zhdr->buddy)); -- we're on buddy now!
spin_lock(&pool->lock); -- deadlock here!
z3fold_reclaim_page might race with z3fold_free and will lead to pool lock
deadlock and zhdr buddy non-empty warning. To fix this, defer getting the
refcount until page_lock is held just like what __z3fold_alloc does. Note
this has the side effect that we won't break the reclaim if we meet a soon
to be released z3fold page now.
Link: https://lkml.kernel.org/r/20220429064051.61552-9-linmiaohe@huawei.com
Fixes: dcf5aedb24f8 ("z3fold: stricter locking and more careful reclaim")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Vitaly Wool <vitaly.wool@konsulko.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'mm/mlock.c')
0 files changed, 0 insertions, 0 deletions