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 77EF6C433F5 for ; Thu, 19 May 2022 07:12:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 024476B0072; Thu, 19 May 2022 03:12:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEF426B0073; Thu, 19 May 2022 03:12:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8FC66B0074; Thu, 19 May 2022 03:12:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C55BD6B0072 for ; Thu, 19 May 2022 03:12:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 9F0568088C for ; Thu, 19 May 2022 07:12:28 +0000 (UTC) X-FDA: 79481624376.02.96F89B1 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf31.hostedemail.com (Postfix) with ESMTP id 4DE4D200C5 for ; Thu, 19 May 2022 07:11:58 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id j2so7593006ybu.0 for ; Thu, 19 May 2022 00:12:27 -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=FWAr/J4HmuD6FhHb4kDYBZ2K/uqMD4MgkdggSBZ6fPY=; b=eumPdvyYgagzbji2kuY9ZtyStkcXWG1yv4KJh/hoJN55IWpgZO1fkjYF7aDelTQegS dINXV3fLCza0Xg+Dakk5qmag+ZV+nh+GljaBQkvNEjIDr+hq4F50BStF3CRgHs75Socx SB2tMBmEmzyLbBNmuIlmCvqnogij2vbbCHp4I= 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=FWAr/J4HmuD6FhHb4kDYBZ2K/uqMD4MgkdggSBZ6fPY=; b=orCGWFW/nDcfSZHx2wLbIKNjCN5g68kN9GG1bZ41CVVkPHx96CfUfLPVGy55i60oUJ /Kdhh/biGSQQtqtN0+Uh7ZNpp+KL2lltPPDgYqltuiorvb+u0TH1xNJjmG6lD/i/23e2 cikiYjGeKaFXaOo56O4ZcJZjkrjVA0eUAcglZcil0/5MmUw9teF8qqX73yxrlgyQgAzi xD/5M+PHo7PfWZpjlEapcS/wZ4SNKfWTqFCr5g6bL/47vT++KGrL7PFV7tZUTwkPSHQM 7L/iCt6r8IuxNJepObRYEjWf/yVHRATmt1+QUlZ1oN1D2tStyk8q+Wb5y38XBJBSN++7 R77g== X-Gm-Message-State: AOAM530Z5UzCfnFUVCPKFbfIpSxHbpHmLaKsZt1yxrL6mPcImi9CjAKw q3PoGEihcaFKjsOJrAqfAMuQ+d7xVBybb1bIW6p6BQ== X-Google-Smtp-Source: ABdhPJymMQ0FDt9pyHOJfXPZaSal9k7mWPMALlyrlNV6GGHjRuKXDoHiG79Ft8KeONIbhbqf3h3mlHEb/OVG+WTNBx4= X-Received: by 2002:a05:6902:703:b0:64f:47d2:2497 with SMTP id k3-20020a056902070300b0064f47d22497mr593ybt.451.1652944345946; Thu, 19 May 2022 00:12:25 -0700 (PDT) MIME-Version: 1.0 References: <20220429064051.61552-1-linmiaohe@huawei.com> <20220429064051.61552-6-linmiaohe@huawei.com> In-Reply-To: <20220429064051.61552-6-linmiaohe@huawei.com> From: Vitaly Wool Date: Thu, 19 May 2022 09:12:14 +0200 Message-ID: Subject: Re: [PATCH 5/9] revert "mm/z3fold.c: allow __GFP_HIGHMEM in z3fold_alloc" To: Miaohe Lin Cc: Andrew Morton , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4DE4D200C5 X-Stat-Signature: uyo5wwsd948t4g418tqmg7ozxwzw5ijq Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b=eumPdvyY; dmarc=pass (policy=none) header.from=konsulko.com; spf=pass (imf31.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1652944318-427607 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: > > Revert commit f1549cb5ab2b ("mm/z3fold.c: allow __GFP_HIGHMEM in > z3fold_alloc"). > > z3fold can't support GFP_HIGHMEM page now. page_address is used > directly at all places. Moreover, z3fold_header is on per cpu > unbuddied list which could be access anytime. So we should rid > the support of GFP_HIGHMEM allocation for z3fold. Could you please clarify how kmem_cache is affected here? Thanks, Vitaly > Signed-off-by: Miaohe Lin > --- > mm/z3fold.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/mm/z3fold.c b/mm/z3fold.c > index b3b4e65c107f..5f5d5f1556be 100644 > --- a/mm/z3fold.c > +++ b/mm/z3fold.c > @@ -212,10 +212,8 @@ static int size_to_chunks(size_t size) > static inline struct z3fold_buddy_slots *alloc_slots(struct z3fold_pool *pool, > gfp_t gfp) > { > - struct z3fold_buddy_slots *slots; > - > - slots = kmem_cache_zalloc(pool->c_handle, > - (gfp & ~(__GFP_HIGHMEM | __GFP_MOVABLE))); > + struct z3fold_buddy_slots *slots = kmem_cache_zalloc(pool->c_handle, > + gfp); > > if (slots) { > /* It will be freed separately in free_handle(). */ > @@ -1075,7 +1073,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t size, gfp_t gfp, > enum buddy bud; > bool can_sleep = gfpflags_allow_blocking(gfp); > > - if (!size) > + if (!size || (gfp & __GFP_HIGHMEM)) > return -EINVAL; > > if (size > PAGE_SIZE) > -- > 2.23.0 >