Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3631720pxv; Mon, 12 Jul 2021 23:33:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVOdJgEVpHQX0zWJUzoj+XydQgXQ9F23dWDIofh5rpQ1y9EeHhXrURF0rYaQB5NOuJnaZ8 X-Received: by 2002:a05:6402:2034:: with SMTP id ay20mr3680612edb.188.1626158007796; Mon, 12 Jul 2021 23:33:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626158007; cv=none; d=google.com; s=arc-20160816; b=SaIkyoBnEf2luGqcv78XZgA36Wa264bXVAXMm38haYJuA4wIVtXa5EDbvTn4r0BszE w3/JAGA7CiE5REk3iqbLRRxt61xaXi0ktFas83d/9WFBWt1W7Yd5r+XowSTtbMtNu2Xr JTyqftmyroP5r2xKpRd9oQfXQcId9eFChzuNzPFNwqzvChEy7WMVZ0mleqX82HDomq1r fFgUDcm4MRfRbRHYSjtIn8D8vXv1dgH1xGUQK+jnOpOrNLkEW730KJT7LFlMCnaXih0v g4SH8f2l000AFs8zKVCQ+sgtnLgwqfSLWPFa1KONW87clNe1sBSxSr5ejyNGOwulQAlC YDHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Br8GUMFwUFegAxc9iJgZv/zXdT69t+A8Nufo1mD356g=; b=qZKFvgZsLcx8+KKszCTVhb9CKtVIclq37kjP8pj5wWsfsqE8PZ532e/OKJ8h90Sdx5 C2sdzMXoUjxRJOHi1Uksy9bU+bVDMBw0SETwfXjp5cuII10RRIIynkkYu39KtSNintBk gSDg5HL1h1BBqP24gWWsXAUs6J5eChb+b0B/VlaUMAkjVDLE2/gTPiHuXbRmAeQSQHd7 ZyvC0HWu7du8QC/Fmd70LrO1OJehm4lGkLFgnnkAhBiNZKLPXVlqZkideMitM8h7+yxm 1NEXxMjniW4JaKMSobb7LXjmogmuT15ykSN4uRc8jakBd5sBHWO6lig/xCJnrxCTaShe d7OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b="wao4cd/9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j10si19716699ejd.87.2021.07.12.23.33.05; Mon, 12 Jul 2021 23:33:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b="wao4cd/9"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233918AbhGMGef (ORCPT + 99 others); Tue, 13 Jul 2021 02:34:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233374AbhGMGef (ORCPT ); Tue, 13 Jul 2021 02:34:35 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC8EDC0613DD for ; Mon, 12 Jul 2021 23:31:44 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id b5-20020a17090a9905b029016fc06f6c5bso1454429pjp.5 for ; Mon, 12 Jul 2021 23:31:44 -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=H7Y1+TEH9a45AVYQsU6Kn3xeHncALY/6Rpsx6w6f0ZaHX/5ZshuWwqBj2gw0Mtty+G 7Apr44UPhqB5xTIFue1xsuUFBaa3d/nt4L5pJVhtd1rJBi4VvbbnAEt8tBm2cheDp8G5 Igi/DZJSZP8bnSRrgT41XKRoxnrX/RUpQfbNG/g/HNExzLNHHj+r//k3xmuF92/ohMSU n8iwld9CACDDGxSpEMWxvRYJIsBvwEOP7vdAHapD6z+gy/ne4jVeCEZhV1th1Jeh6RB6 qbVr2RFukjkEb23fCF3Qp9M7dlA6lrEjqjtCWUPEFLftixSkVvufR8QxPFjUX75YchJ+ jwWg== X-Gm-Message-State: AOAM531i1741ygMTsmx0VnF6049wxzcikz5qPWer7EjR9wAwYt6gQCq0 C9gR+bVD+DOsD22oBbzn5+A7RF4Faxb7Y1N9aBVz2w== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >