Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp317743rwi; Wed, 2 Nov 2022 12:16:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4gflIo9JGeo1MN0yH2ponmVo6vXbVnRI9g1ipA3c8nqg6fIoJE25cCHH4YUdXdA21FBkh0 X-Received: by 2002:a17:907:9602:b0:780:8c9f:f99a with SMTP id gb2-20020a170907960200b007808c9ff99amr25578739ejc.465.1667416580705; Wed, 02 Nov 2022 12:16:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667416580; cv=none; d=google.com; s=arc-20160816; b=lUg5XU45cWsVK+qilcbLwzmQ9lnsfInCj9BWdYRnR7u/cuMD02LfR1LtfM/2RYgaq5 IyZh52YNggIzoEyTwEv5LqJaaootYQAA+d9mYe19bz4yNat+kCq9I936dvLMzuEuOpJx E+poGH6yB7HDZSb0TDrg2qkktEuJZYLGh9WR78H9nJVJheZT0vgs29lAHNvsGmJvNTXW Qc0eQ89PPoJv/szE7iIscb+r8Vi/n6lpLGn14QIT+tZsAiLkbjbcqwz1BJjMQEL3E03k i5Ei9l6cHIZNarGZkgXtu5ptYzFBATH/zZu0AQfnIsMAQM9P372GRiCxRbP0Ipgf1+jE gjSw== 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=SJ2ZHLozVbrXFGJhHAp4jFnhNvxFiOfSYk2Zw6TLsHw=; b=DLGHSc8+/OLeXgvkx++qMtb60e2vHoV4q3cHZLY7Z5kImFUaSBvAUvxr7vcwc3RU6h CBB7J0V5t40ndgk00YwX+6yLAjyxBMU8Abx/3phbBQMKeqiKnIzA2zrtCyIHx1bm9FaU jyE0H/dO4zTlIqJJN5rV9ZSNYXitXIPuf5yXbqhh/WHpFn0yxjGC9wrVDxshF4UQATex SZnPFrMsV09Pcd6z7gvUbd2byTaQ+dn+9xdfIbYVbew5MCCGleAWe8gSL544TIvZrkWd Ep/qQfUp1+W8P4Hln5lD6jwC9iCMF2t77rv0kuXBbtcK6HF649Ls6y7+n5IRrhvaZnCc zapw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JTa7n5j0; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji19-20020a170907981300b0078d3b452573si18722368ejc.968.2022.11.02.12.15.55; Wed, 02 Nov 2022 12:16:20 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=JTa7n5j0; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230468AbiKBSEV (ORCPT + 98 others); Wed, 2 Nov 2022 14:04:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230294AbiKBSEQ (ORCPT ); Wed, 2 Nov 2022 14:04:16 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C64BA63B1 for ; Wed, 2 Nov 2022 11:04:15 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id z24so26078604ljn.4 for ; Wed, 02 Nov 2022 11:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SJ2ZHLozVbrXFGJhHAp4jFnhNvxFiOfSYk2Zw6TLsHw=; b=JTa7n5j0LHz9NZAainf6PNxU3H274rfHvdYJLcXpCHUnAIEzpizESke89IFDh1DlOR HBNOlF9OvEdrBXENtjwpUjFwtJ1q6iaJBL+cQOB7imGAu813t80YvOERlt5omuXosZbz QqfWq/yOUaOH2J7NQyWZ7IuqWwxJuqQGbrOBbN85zYctjeL2JuwJ2c4lF3kM9fSQIWbE 8c4zooehsjcLP8gA/VO5uXnaYHCEcLNYCWBFqPqcREXU45OpUQ6YTYdyZnh8PMWT+rsQ x4V+qpE3sA3cvrCuXYV1bedXdKNexSSRLceZ6szE8Kp+PSdyWTDncjGQO3lWMmDLVLJF mruw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SJ2ZHLozVbrXFGJhHAp4jFnhNvxFiOfSYk2Zw6TLsHw=; b=ckI+27szqinxs29xxTtoEMuj825BPN8LJypfIZF6GUAN7lmEte1hgK46Vu3USNV69S 6PW6/baoIzU0emZWqjZYyckQRdQombZB5J0tCOTcJjrEHf2lmcvKFRgflnzXd5P7E9b9 GiB1e7a4kxw1BjkAQ0l1Oh9nwNSzGs/y4MN6tKeJZVWmuG6cRbJDIGbKP9bfJBfm3Kv3 3scsdtFsacgtypfxApW/mR6M1WgewugFcWvzwLrNNN30e2WWHBGuhu2RjdXDOKE6g42a Ge6/1Kf6uhAZShRbea+deV6T3euir2SbDG5veH35KW1qFgcsFoYcVFitd/ragmi/SY4S q1hg== X-Gm-Message-State: ACrzQf2xhUupmf/sXOzMQysmX/UefwZ0KNTtmf2nCwqpDogVdzZpJRcY TzM91vfkDMYYFehqPAWBhkpnDvfLqVxx+tu0gbYvBg== X-Received: by 2002:a2e:9884:0:b0:277:901:69f with SMTP id b4-20020a2e9884000000b002770901069fmr9713281ljj.169.1667412253713; Wed, 02 Nov 2022 11:04:13 -0700 (PDT) MIME-Version: 1.0 References: <20221030212929.335473-1-peterx@redhat.com> <20221030213043.335669-1-peterx@redhat.com> In-Reply-To: <20221030213043.335669-1-peterx@redhat.com> From: James Houghton Date: Wed, 2 Nov 2022 11:04:01 -0700 Message-ID: Subject: Re: [PATCH RFC 09/10] mm/hugetlb: Make hugetlb_fault() RCU-safe To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Kravetz , David Hildenbrand , Andrea Arcangeli , Rik van Riel , Andrew Morton , Muchun Song , Miaohe Lin , Nadav Amit Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 On Sun, Oct 30, 2022 at 2:30 PM Peter Xu wrote: > > RCU makes sure the pte_t* won't go away from under us. Please refer to the > comment above huge_pte_offset() for more information. Thanks for this series, Peter! :) > > Signed-off-by: Peter Xu > --- > mm/hugetlb.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 5dc87e4e6780..6d336d286394 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -5822,6 +5822,8 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, > int need_wait_lock = 0; > unsigned long haddr = address & huge_page_mask(h); > > + /* For huge_pte_offset() */ > + rcu_read_lock(); > ptep = huge_pte_offset(mm, haddr, huge_page_size(h)); > if (ptep) { > /* > @@ -5830,13 +5832,15 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, > * not actually modifying content here. > */ > entry = huge_ptep_get(ptep); > + rcu_read_unlock(); > if (unlikely(is_hugetlb_entry_migration(entry))) { > migration_entry_wait_huge(vma, ptep); ptep is used here (and we dereference it in `__migration_entry_wait_huge`), so this looks unsafe to me. A simple way to fix this would be to move the migration entry check after the huge_pte_alloc call. - James > return 0; > } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) > return VM_FAULT_HWPOISON_LARGE | > VM_FAULT_SET_HINDEX(hstate_index(h)); > - } > + } else > + rcu_read_unlock(); > > /* > * Serialize hugepage allocation and instantiation, so that we don't > -- > 2.37.3 >