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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D610C11F66 for ; Tue, 13 Jul 2021 06:31:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBF5D61183 for ; Tue, 13 Jul 2021 06:31:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBF5D61183 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0EB246B008C; Tue, 13 Jul 2021 02:31:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09C1A6B0095; Tue, 13 Jul 2021 02:31:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E56EA6B0096; Tue, 13 Jul 2021 02:31:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id BB00A6B008C for ; Tue, 13 Jul 2021 02:31:47 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B71EF27033 for ; Tue, 13 Jul 2021 06:31:46 +0000 (UTC) X-FDA: 78356593812.33.19BBF7F Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf09.hostedemail.com (Postfix) with ESMTP id ACAB73000103 for ; Tue, 13 Jul 2021 06:31:45 +0000 (UTC) Received: by mail-pj1-f46.google.com with SMTP id x21-20020a17090aa395b029016e25313bfcso1459345pjp.2 for ; Mon, 12 Jul 2021 23:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Br8GUMFwUFegAxc9iJgZv/zXdT69t+A8Nufo1mD356g=; b=wao4cd/9u7fGjc9e560agRWg1B6OIVuJAjPDiC+lxPCIpySqZTqxcr06BmkQybfSzq /Ba9X9CZj6XIk/M0ss/En+B+/fdfvNHTkLLNnYgS3Qxs5NffHPD1zv0iznXcvws6QMwN S+smVHifljhWEjCtAZaMFKoAX229UwDDuGY9oK1VG3L0/Gp3A5bZOYO6MV8anSC0OsoX cCpz763mUTgY77HSUce4aHqMKac0ndLgrMI1BaGmHscBR4PSONgZQAphsPDRNzvl/+Lt MWNgwZr61GMQQJoCOdqSppSfXhApCd3vMz5EpX+PjPpOIuW2UqGbAs4ochiAjJ5G1vZl TIkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Br8GUMFwUFegAxc9iJgZv/zXdT69t+A8Nufo1mD356g=; b=MEI8HE8FLcEf/6//Pn+qRS60InXZZ6ZVP9nrhiYdvoo3SwxdZcYGNHVHd3kCeqQzZ/ H6hsH61+tnsNrSXXGa6qgNZYaHv+1snn2X+VRWBGDhOYUcQzsD9FsSBiKeHk1D88+W+o Cvv9sY4DMGpgpE5D3tnv3oGxKWZs4gooRCngobdzaHyMtKz+CQWQKCirCK3HFHX11NtZ 7xT0X0iWUR1tXtMf7usb6imBaY9xOu/AzCfh5q0368nncm8NZDdjQGS88vmUEbq6IocX lXI57aPXVIPz8jZjTmu0QzrDplCTX5eESHYWiOA+EdacxlaJQ3qqKoevykrkCmgDH3dM EEbw== X-Gm-Message-State: AOAM531hps8ApTkqt0m1tr3PLPBHbY1tM8DDCHoC9jycom2DrgTbM+B/ b0ctQvviGSUYQoHGoXM3+GiQJq+E2qvj4LnvTyislg== X-Google-Smtp-Source: ABdhPJz32PTvCL1DociLEj1FUp3UFQ1G2/2HInEOm1k/PEel8a/8ZFZgPD7P75Xp2i9SCuakpZAIXjALI1b/rQEnYhc= X-Received: by 2002:a17:90a:5204:: with SMTP id v4mr17743612pjh.147.1626157904440; Mon, 12 Jul 2021 23:31:44 -0700 (PDT) MIME-Version: 1.0 References: <20210710002441.167759-1-mike.kravetz@oracle.com> <20210710002441.167759-2-mike.kravetz@oracle.com> In-Reply-To: <20210710002441.167759-2-mike.kravetz@oracle.com> From: Muchun Song Date: Tue, 13 Jul 2021 14:31:08 +0800 Message-ID: Subject: Re: [External] [PATCH 1/3] hugetlb: simplify prep_compound_gigantic_page ref count racing code To: Mike Kravetz Cc: Linux Memory Management List , LKML , Michal Hocko , Oscar Salvador , David Hildenbrand , Matthew Wilcox , Naoya Horiguchi , Mina Almasry , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: ACAB73000103 X-Stat-Signature: f5z1bujnkrahmq8g8dg1gkpwmp9ny7g3 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b="wao4cd/9"; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf09.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-HE-Tag: 1626157905-408176 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 Sat, Jul 10, 2021 at 8:25 AM Mike Kravetz wrote: > > Code in prep_compound_gigantic_page waits for a rcu grace period if it > notices a temporarily inflated ref count on a tail page. This was due > to the identified potential race with speculative page cache references > which could only last for a rcu grace period. This is overly complicated > as this situation is VERY unlikely to ever happen. Instead, just quickly > return an error. Right. The race is very very small. IMHO, that does not complicate the code is the right thing to do. > > Also, only print a warning in prep_compound_gigantic_page instead of > multiple callers. > > Signed-off-by: Mike Kravetz > --- > mm/hugetlb.c | 15 +++++---------- > 1 file changed, 5 insertions(+), 10 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 924553aa8f78..e59ebba63da7 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -1657,16 +1657,12 @@ static bool prep_compound_gigantic_page(struct page *page, unsigned int order) > * cache adding could take a ref on a 'to be' tail page. > * We need to respect any increased ref count, and only set > * the ref count to zero if count is currently 1. If count > - * is not 1, we call synchronize_rcu in the hope that a rcu > - * grace period will cause ref count to drop and then retry. > - * If count is still inflated on retry we return an error and > - * must discard the pages. > + * is not 1, we return an error and caller must discard the > + * pages. Shall we add more details about why we discard the pages? Thanks. > */ > if (!page_ref_freeze(p, 1)) { > - pr_info("HugeTLB unexpected inflated ref count on freshly allocated page\n"); > - synchronize_rcu(); > - if (!page_ref_freeze(p, 1)) > - goto out_error; > + pr_warn("HugeTLB page can not be used due to unexpected inflated ref count\n"); > + goto out_error; > } > set_page_count(p, 0); > set_compound_head(p, page); > @@ -1830,7 +1826,6 @@ static struct page *alloc_fresh_huge_page(struct hstate *h, > retry = true; > goto retry; > } > - pr_warn("HugeTLB page can not be used due to unexpected inflated ref count\n"); > return NULL; > } > } > @@ -2828,8 +2823,8 @@ static void __init gather_bootmem_prealloc(void) > prep_new_huge_page(h, page, page_to_nid(page)); > put_page(page); /* add to the hugepage allocator */ > } else { > + /* VERY unlikely inflated ref count on a tail page */ > free_gigantic_page(page, huge_page_order(h)); > - pr_warn("HugeTLB page can not be used due to unexpected inflated ref count\n"); > } > > /* > -- > 2.31.1 >