mm/z3fold: fix z3fold_reclaim_page races with z3fold_free
authorMiaohe Lin <linmiaohe@huawei.com>
Fri, 29 Apr 2022 06:40:43 +0000 (14:40 +0800)
committerakpm <akpm@linux-foundation.org>
Fri, 27 May 2022 16:33:44 +0000 (09:33 -0700)
commit04094226d6ce8c0cb590891e13872109aa6722f1
tree02723a23b7785dff1502ea3335bd6560fe76dcb0
parent4a1c3839108afcfec02f4d62d6862b2451b442ab
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>
mm/z3fold.c