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 B5D71C47089 for ; Mon, 5 Dec 2022 23:36:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36EEC8E0002; Mon, 5 Dec 2022 18:36:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 31EDB8E0001; Mon, 5 Dec 2022 18:36:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BF838E0002; Mon, 5 Dec 2022 18:36:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 08CE08E0001 for ; Mon, 5 Dec 2022 18:36:37 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AC61480C2C for ; Mon, 5 Dec 2022 23:36:36 +0000 (UTC) X-FDA: 80209864392.14.DD90A82 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf18.hostedemail.com (Postfix) with ESMTP id A65301C000D for ; Mon, 5 Dec 2022 23:36:35 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HdtR8fA7; spf=pass (imf18.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670283396; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bnO7sa7gSzPB4vbpmgmHXbkc9bOWdh6rM7DpO68yVMw=; b=QcwS7GEXZkpXva1y53QoWa61Ea7+eo3Gv51Ctg8m+zQGn0h5hGp0w2sK0aBpfiwWDxLM0S s8PAVwjmMmNRXxEW7XxkJTF5ANVQjXzAH1Jufv41aCjUt3UxDD2Mw/k7zaFz7XFMsDgUz0 g+ey5y9vnh7SBKj170mO8rJnaFS0Ma8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HdtR8fA7; spf=pass (imf18.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670283396; a=rsa-sha256; cv=none; b=B8e/LANh4h2EY86AeTaOx9GxVXh1HGL1y19NP6tVOJYRACI6cAuDe6rcBffOL/mN8qwgqh SrC6OZB9YKQnHENHzAWAXd5Zciz++ctpI1OXwO3VYaiD1BXWVYttSLP72P6qnU4LrPf5CK KW2gvekDV4H6HsnznvWOpB+rPuPsHl8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670283395; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bnO7sa7gSzPB4vbpmgmHXbkc9bOWdh6rM7DpO68yVMw=; b=HdtR8fA7VlUQQX2YVI2sn0lx2ovmcifY9bngAzQCEYM6v5RDMj/bc2jeZzFXn/0m9S1cWB x842IqcKJc0NVB4cVPwUXckOjLLLg6UYrsy61WCpp4ZJtrITxICBJI0zs2Soi8v0t5txVq eQL1NFv9ifgvmV4t9e/7e2F2S+5+Ads= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-319-HNSjqvC4OGaTCHWOukd4JQ-1; Mon, 05 Dec 2022 18:36:33 -0500 X-MC-Unique: HNSjqvC4OGaTCHWOukd4JQ-1 Received: by mail-qt1-f198.google.com with SMTP id h26-20020ac8505a000000b003a7e8e8b03bso2141363qtm.18 for ; Mon, 05 Dec 2022 15:36:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bnO7sa7gSzPB4vbpmgmHXbkc9bOWdh6rM7DpO68yVMw=; b=WloQC4k3xauB7hXzHwiAn4WciUIlinY7cbM1VDJLapWGrP/JjTz3PN8TA2qAqI6dX9 QFpEjFykKYQIAAhQcnfCeJ0f8eDSKPzE4CwxFPzeq6rc2NBNVuBr59jO0WOdFuRxVaNw ktkYYUM9X3mtp5+Bt5vuCnkPMRggNuyXTnGqTc8SprXLjfHh0KEqDfQ8iqaTFeRC5+PE jEAlrNwiAGjvNK5gtz1zTGruB8lPd+GL9VBJvPOhXeNYRzs7J3AgKr3N85bsrQ9J1sbs pRQVgZbBpwFhi8tIBcYkcWvIGYDhUfNsMZWeFU6DQoveCd/gN6xMUXs38gLWDrIDK5qb Lzeg== X-Gm-Message-State: ANoB5pm7Wn1foqXleKc+2B3voMyJ3I5rTrYt6g88bY5lvw0J90s4hkTc yEDAtjP7/sDEw/zyNvcsQOXjy6PL7h/b/iZbEBgcnT8/o5OJ+zC3Tj4kSJGlsSTLtcfMB2MiG6z O3g+X3gY4IBA= X-Received: by 2002:ad4:5849:0:b0:4c7:933:144c with SMTP id de9-20020ad45849000000b004c70933144cmr30574164qvb.80.1670283393227; Mon, 05 Dec 2022 15:36:33 -0800 (PST) X-Google-Smtp-Source: AA0mqf4lr+1n1Z+ukiqEUTq0BmC2P5iDPk1qbzmNGUgtKxSx5t+iR8zsMGwkhO4+Jhs1P04Va1COBg== X-Received: by 2002:ad4:5849:0:b0:4c7:933:144c with SMTP id de9-20020ad45849000000b004c70933144cmr30574141qvb.80.1670283392964; Mon, 05 Dec 2022 15:36:32 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id g13-20020a05620a40cd00b006fc7c5d456asm10575370qko.136.2022.12.05.15.36.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Dec 2022 15:36:32 -0800 (PST) Date: Mon, 5 Dec 2022 18:36:31 -0500 From: Peter Xu To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, James Houghton , Jann Horn , Andrew Morton , Andrea Arcangeli , Rik van Riel , Nadav Amit , Miaohe Lin , Muchun Song , David Hildenbrand Subject: Re: [PATCH 04/10] mm/hugetlb: Move swap entry handling into vma lock when faulted Message-ID: References: <20221129193526.3588187-1-peterx@redhat.com> <20221129193526.3588187-5-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A65301C000D X-Stat-Signature: d55eqhmebmu51betpq3nu5tdauc6skzd X-Spamd-Result: default: False [3.75 / 9.00]; SORBS_IRL_BL(3.00)[209.85.160.198:received]; SUSPICIOUS_RECIPS(1.50)[]; BAYES_HAM(-1.35)[82.97%]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; DKIM_TRACE(0.00)[redhat.com:+]; RCPT_COUNT_TWELVE(0.00)[12]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[redhat.com,none]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; R_DKIM_ALLOW(0.00)[redhat.com:s=mimecast20190719]; ARC_NA(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:170.10.129.0/24]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspam-User: X-HE-Tag: 1670283395-310254 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 Mon, Dec 05, 2022 at 02:14:38PM -0800, Mike Kravetz wrote: > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index dfe677fadaf8..776e34ccf029 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -5826,22 +5826,6 @@ 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); > > > > - ptep = huge_pte_offset(mm, haddr, huge_page_size(h)); > > - if (ptep) { > > - /* > > - * Since we hold no locks, ptep could be stale. That is > > - * OK as we are only making decisions based on content and > > - * not actually modifying content here. > > - */ > > - entry = huge_ptep_get(ptep); > > - if (unlikely(is_hugetlb_entry_migration(entry))) { > > - migration_entry_wait_huge(vma, ptep); > > - return 0; > > - } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry))) > > - return VM_FAULT_HWPOISON_LARGE | > > - VM_FAULT_SET_HINDEX(hstate_index(h)); > > - } > > - > > Before acquiring the vma_lock, there is this comment: > > /* > * Acquire vma lock before calling huge_pte_alloc and hold > * until finished with ptep. This prevents huge_pmd_unshare from > * being called elsewhere and making the ptep no longer valid. > * > * ptep could have already be assigned via hugetlb_walk(). That > * is OK, as huge_pte_alloc will return the same value unless > * something has changed. > */ > > The second sentence in that comment about ptep being already assigned no > longer applies and can be deleted. Correct, this can be removed. One thing to mention is there's an inline touch-up above in the last patch of the series when introducing hugetlb_walk() to s/pte_offset/walk/, but I saw that Andrew has already done the right thing on the fixup one in his local tree, so I think we're all good. Thanks! -- Peter Xu