Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1607889iob; Fri, 29 Apr 2022 08:52:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ6rnLlFm9FUdhNHprkv0GN1ItLxZ/MH839SS1Sdop5OR4Ri9xRlcHxsr4zLcMDJ3i5yZ8 X-Received: by 2002:a63:2c0c:0:b0:3c1:a611:7ac1 with SMTP id s12-20020a632c0c000000b003c1a6117ac1mr12486pgs.485.1651247545759; Fri, 29 Apr 2022 08:52:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651247545; cv=none; d=google.com; s=arc-20160816; b=j8zQZEj/qRYlI444vZwH1+Nv1wpf103/oyJ7f640dV1PPWaw7vgR17Ez7oPyVkx6EX aRwmOppCrAr7yuArv+1Mgw9lrj730THcLePVaNL1D2RvS8EtmJ6BksmRAIAdRiuinFpi fCmLegKwkwj5cQCfUwMUG90G+y6KscIkAnfey6dl/9gmc/r7Hdd8KXACTJKtH6RMmI+8 D0eaCBUJXfFOA3XOGyRKBl1OeXn71yB13NKHPAaHYvlGAc8imxB1etCPFA52qjdnrx6P bkDTDFU12HiWP65w53Z2jvkcqhY1hKIczrvoHUPo/9O1l0pXhzj47X6EdHjaPFTOodVS jVnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=+1bcTYwLwNlLk5jpRep1k7CRoFPBITJkKUn0poCEksk=; b=oe3LdOj9wpWi2ugkMS8WJAlN83UYENP8cYknrsqLLHN2dBSYGep2kW66/4TAabPl3g ijBgd1eUcl7v/bBvVqjNfmv4Ptz7l1exDr2xiCeRHryJzoaPzl3q1guAyEHdUza8aVZt uIBr1IQUTxIp+CIMv/BpJ0MGi2HmBNyHnkiunI1ijCvTS94Hvd7B4PL99qhHc/knHUoR uQNcrlWICeikdsvCrcPTxnW0RreiWtv0Lw6YhM3sCCzX4bQOIF4zDhRde8E7xRzaR2eh 3Ofx0pJNaXjR/HjhPmmb00um+tatX9Br/bLtNhlMkIl334hGliMARxv1YbtwRTlJgyLw ZMIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o5-20020a056a0015c500b005061e548749si8117371pfu.364.2022.04.29.08.52.08; Fri, 29 Apr 2022 08:52:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354728AbiD2GoX (ORCPT + 99 others); Fri, 29 Apr 2022 02:44:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354665AbiD2Gnx (ORCPT ); Fri, 29 Apr 2022 02:43:53 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31D81B9F31 for ; Thu, 28 Apr 2022 23:40:35 -0700 (PDT) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KqN8f4HK2zGpPK; Fri, 29 Apr 2022 14:37:54 +0800 (CST) Received: from huawei.com (10.175.124.27) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 29 Apr 2022 14:40:32 +0800 From: Miaohe Lin To: , CC: , , Subject: [PATCH 3/9] mm/z3fold: remove buggy use of stale list for allocation Date: Fri, 29 Apr 2022 14:40:45 +0800 Message-ID: <20220429064051.61552-4-linmiaohe@huawei.com> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20220429064051.61552-1-linmiaohe@huawei.com> References: <20220429064051.61552-1-linmiaohe@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.124.27] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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; -- 2.23.0