From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD5EDC433EF for ; Thu, 19 May 2022 07:06:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 646BE6B0072; Thu, 19 May 2022 03:06:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F5596B0073; Thu, 19 May 2022 03:06:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BD146B0074; Thu, 19 May 2022 03:06:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 39F216B0072 for ; Thu, 19 May 2022 03:06:35 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 111EE60B6A for ; Thu, 19 May 2022 07:06:35 +0000 (UTC) X-FDA: 79481609550.17.D2EFA00 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf20.hostedemail.com (Postfix) with ESMTP id DDB1F1C00DD for ; Thu, 19 May 2022 07:06:16 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id v71so7482824ybi.4 for ; Thu, 19 May 2022 00:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YwGdObx2rN49pGl6m0/GqaEWdkz1IZaGgAWMTIaY1MQ=; b=NL0wn/oE6V1itp4kAHF911Q1QFEhRcBt6i3r8skcUAkzgzmyPF2Og0z3erS3hnOqYa ckkoTrnqmPjfrf3xn5u3ZtvVxO9YWJN+kzy2QGXpnDFsoYuBpb4KDWg3YcPmNpw0wy3d 2lv/Y5V5eacwcibq4WvyoqY3VtmsKFk1pk33c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YwGdObx2rN49pGl6m0/GqaEWdkz1IZaGgAWMTIaY1MQ=; b=cUGw3zEoxaLzsnYFQ62pRntKHPcx5s0qjBC4NfzJCPvzP2Qm8cQa9A7YtA5w1ggk7o 7x0hxq7Zbu/w8dY0smRdMtIMASAEw3gnyO7YbsCXymwbzvg3fnHo9kyPSrE7VzNUlqG9 vIwXo15RHDmJ0Ylq7Ju/XBXwVIGsMHdrC9mresEN5xpvPwG4Kn5+d/kbLZytpEx2uE8r xdz/i60H0H+agUmeW3Qa6kPdTn7rauCRRJLYZs7P4XTAQNFDy7pS7H88eY2LC92SuWaH A/NOQ/0K4WO1hH9dgPC4ZQsVBaWEviIz6enFN/Rag3+ViiL4n2t578vqMqI3znrp9UK8 l+4g== X-Gm-Message-State: AOAM531rcd5iKx9JJ/zBJt4tLlhIhejXr7Mf0PF5q+ftROh/NbLjxPx4 O50azbO3XWBkX8UTZysBBNIRl72qC2q6bT+n6rkm1Y9cIp4= X-Google-Smtp-Source: ABdhPJwXMsrkDRDjElIr5XkTyARF49d8zBfzI8qyiCHp6sygr/oTHpLqiQm1O6srVsjnwmPN+S82fZZotEvF2OxlkfM= X-Received: by 2002:a25:f506:0:b0:64d:f8a5:b2bd with SMTP id a6-20020a25f506000000b0064df8a5b2bdmr2819186ybe.610.1652943988678; Thu, 19 May 2022 00:06:28 -0700 (PDT) MIME-Version: 1.0 References: <20220429064051.61552-1-linmiaohe@huawei.com> <20220429064051.61552-4-linmiaohe@huawei.com> In-Reply-To: <20220429064051.61552-4-linmiaohe@huawei.com> From: Vitaly Wool Date: Thu, 19 May 2022 09:06:17 +0200 Message-ID: Subject: Re: [PATCH 3/9] mm/z3fold: remove buggy use of stale list for allocation To: Miaohe Lin Cc: Andrew Morton , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: j5yb3udhfwbycsm471ek655ru9acc3bx X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DDB1F1C00DD X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b="NL0wn/oE"; dmarc=pass (policy=none) header.from=konsulko.com; spf=pass (imf20.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com X-HE-Tag: 1652943976-754368 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 29, 2022 at 8:41 AM Miaohe Lin wrote: > > Currently if z3fold couldn't find an unbuddied page it would first try to > pull a page off the stale list. But this approach is problematic. If init > z3fold page fails later, the page should be freed via free_z3fold_page to > clean up the relevant resource instead of using __free_page directly. And > if page is successfully reused, it will BUG_ON later in __SetPageMovable > because it's already non-lru movable page, i.e. PAGE_MAPPING_MOVABLE is > already set in page->mapping. In order to fix all of these issues, we can > simply remove the buggy use of stale list for allocation because can_sleep > should always be false and we never really hit the reusing code path now. > > Signed-off-by: Miaohe Lin > --- > mm/z3fold.c | 23 +---------------------- > 1 file changed, 1 insertion(+), 22 deletions(-) > > diff --git a/mm/z3fold.c b/mm/z3fold.c > index 5d8c21f2bc59..4e6814c5694f 100644 > --- a/mm/z3fold.c > +++ b/mm/z3fold.c > @@ -1102,28 +1102,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp, > bud = FIRST; > } > > - page = NULL; > - if (can_sleep) { > - spin_lock(&pool->stale_lock); > - zhdr = list_first_entry_or_null(&pool->stale, > - struct z3fold_header, buddy); > - /* > - * Before allocating a page, let's see if we can take one from > - * the stale pages list. cancel_work_sync() can sleep so we > - * limit this case to the contexts where we can sleep > - */ > - if (zhdr) { > - list_del(&zhdr->buddy); > - spin_unlock(&pool->stale_lock); > - cancel_work_sync(&zhdr->work); > - page = virt_to_page(zhdr); > - } else { > - spin_unlock(&pool->stale_lock); > - } > - } > - if (!page) > - page = alloc_page(gfp); > - > + page = alloc_page(gfp); > if (!page) > return -ENOMEM; Reviewed-by: Vitaly Wool > -- > 2.23.0 >