Message ID | 20231219075538.414708-10-peterx@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-4843-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp1778920dyi; Mon, 18 Dec 2023 23:58:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IHWAs7ZNinOZzdXrQ5k9HMc4SvUfKFF+bU4XLgBsd0438pLINIT2QNb87toKXlbnn9Dn6L5 X-Received: by 2002:a05:6358:591f:b0:170:ca20:6fd with SMTP id g31-20020a056358591f00b00170ca2006fdmr20512746rwf.62.1702972737113; Mon, 18 Dec 2023 23:58:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702972737; cv=none; d=google.com; s=arc-20160816; b=U8AiJntAZ+tw6+32QJt/RP02M5cXgEDA8itzNLJpYCn3CReQ671zyGcpH3sLHwfacY yxrsYOz3KlNastIAO7n45Mw+L9BbtH5ddrv7e19KxyrQNKEsjPqZKILQGTYC8PgkhVFU c4Y96PhzOINdpTrdWXYZ8erYw/ewfxJbqxtgQ4zM5lPWOKRxcck3W+xNSSkuzLEs+2Ac D3f0yuu/cmYfw4V7ZXAWpoKnzMziT/M7aMnzTG/0ut+3jcy9fU9cHlmK+8okScI3l/CG O/csFeZS1IMX2R+7kUeGb1wrfMMf+MGOGel7n9xkxu3BWWQgsYIqFVg7oizGsLAs//O9 XscQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=7UtlH+qJqHqzo7Y62yc3egVvRJlUYI/8xtDdmttQSUc=; fh=3mpu6Yyr5hMzDKtkQvzcApl7ZSQGU4G8QyIY2BAU7VY=; b=VuFt5FunACto/Kk7ybmdsBk35t4lpQKoFL3hMmnIL1OoIM0/SL/ZVozvNjlauRQZhP ygVd+kvjgwVnwqzXA91ZolsFPFBxKj9xxvy6ohWi4DHk9YjbOSs0W0Om6jGqBkvM5/7w RZbGBQQ7qpnvykWwsoNWjtUsVo15uHQoepRwQIIkaAKLnHE3g8sSY4ucUhFn4gpq6+oy HHeAoZ3xDyKk3/hNHp5ZvIocGtTuV83dMXERCmqR0lNvNX10Hn4iyjplJ5frbWVXKKIz OYVCR5ip9/WjdyY14a4tNDz/jpfxwH+fEa8FayvYoQ/k5lBBpC/HchhyuXgVv0e790QW 2b9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y5b7wywr; spf=pass (google.com: domain of linux-kernel+bounces-4843-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4843-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id a9-20020aa78e89000000b006d93838b44esi417173pfr.41.2023.12.18.23.58.56 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 23:58:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4843-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y5b7wywr; spf=pass (google.com: domain of linux-kernel+bounces-4843-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4843-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D96F5286BC5 for <ouuuleilei@gmail.com>; Tue, 19 Dec 2023 07:58:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 519B214F69; Tue, 19 Dec 2023 07:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Y5b7wywr" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 413501429A for <linux-kernel@vger.kernel.org>; Tue, 19 Dec 2023 07:57:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702972666; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7UtlH+qJqHqzo7Y62yc3egVvRJlUYI/8xtDdmttQSUc=; b=Y5b7wywrl16gpY3+tzbsVsuvPxD5fZXreYpvcGhI4HODV4jgYBqgD2MDW6GhvWJiEOdbc3 flgTQM1SNdI+rbNOjOc9rCpkh0EsCijIMtev+gG9mcLn2HnW+NZ4w1SSYyaR5XJfadxxHE KRe6IX2k5lPo69getGFoq8tln6Qpocg= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-197-HHPXr_gTMGKJxc1F8Y3Vvw-1; Tue, 19 Dec 2023 02:57:42 -0500 X-MC-Unique: HHPXr_gTMGKJxc1F8Y3Vvw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 13EAF1C0513F; Tue, 19 Dec 2023 07:57:41 +0000 (UTC) Received: from x1n.redhat.com (unknown [10.72.116.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id D699F2026D66; Tue, 19 Dec 2023 07:57:28 +0000 (UTC) From: peterx@redhat.com To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Matthew Wilcox <willy@infradead.org>, Christophe Leroy <christophe.leroy@csgroup.eu>, Lorenzo Stoakes <lstoakes@gmail.com>, David Hildenbrand <david@redhat.com>, Vlastimil Babka <vbabka@suse.cz>, Mike Kravetz <mike.kravetz@oracle.com>, Mike Rapoport <rppt@kernel.org>, Christoph Hellwig <hch@infradead.org>, John Hubbard <jhubbard@nvidia.com>, Andrew Jones <andrew.jones@linux.dev>, linux-arm-kernel@lists.infradead.org, Michael Ellerman <mpe@ellerman.id.au>, "Kirill A . Shutemov" <kirill@shutemov.name>, linuxppc-dev@lists.ozlabs.org, Rik van Riel <riel@surriel.com>, linux-riscv@lists.infradead.org, Yang Shi <shy828301@gmail.com>, James Houghton <jthoughton@google.com>, "Aneesh Kumar K . V" <aneesh.kumar@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Jason Gunthorpe <jgg@nvidia.com>, Andrea Arcangeli <aarcange@redhat.com>, peterx@redhat.com, Axel Rasmussen <axelrasmussen@google.com> Subject: [PATCH 09/13] mm/gup: Cache *pudp in follow_pud_mask() Date: Tue, 19 Dec 2023 15:55:34 +0800 Message-ID: <20231219075538.414708-10-peterx@redhat.com> In-Reply-To: <20231219075538.414708-1-peterx@redhat.com> References: <20231219075538.414708-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785696341175676439 X-GMAIL-MSGID: 1785696341175676439 |
Series |
mm/gup: Unify hugetlb, part 2
|
|
Commit Message
Peter Xu
Dec. 19, 2023, 7:55 a.m. UTC
From: Peter Xu <peterx@redhat.com> Introduce "pud_t pud" in the function, so the code won't dereference *pudp multiple time. Not only because that looks less straightforward, but also because if the dereference really happened, it's not clear whether there can be race to see different *pudp values if it's being modified at the same time. Signed-off-by: Peter Xu <peterx@redhat.com> --- mm/gup.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
Comments
On Tue, Dec 19, 2023 at 2:57 AM <peterx@redhat.com> wrote: > > From: Peter Xu <peterx@redhat.com> > > Introduce "pud_t pud" in the function, so the code won't dereference *pudp > multiple time. Not only because that looks less straightforward, but also > because if the dereference really happened, it's not clear whether there > can be race to see different *pudp values if it's being modified at the > same time. > > Signed-off-by: Peter Xu <peterx@redhat.com> > --- > mm/gup.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/mm/gup.c b/mm/gup.c > index 6c0d82fa8cc7..97e87b7a15c3 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -753,26 +753,27 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma, > unsigned int flags, > struct follow_page_context *ctx) > { > - pud_t *pud; > + pud_t *pudp, pud; > spinlock_t *ptl; > struct page *page; > struct mm_struct *mm = vma->vm_mm; > > - pud = pud_offset(p4dp, address); > - if (pud_none(*pud)) > + pudp = pud_offset(p4dp, address); > + pud = *pudp; I think you might want a READ_ONCE() on this so that the compiler doesn't actually read the pud multiple times. > + if (pud_none(pud)) > return no_page_table(vma, flags, address); > - if (pud_devmap(*pud)) { > - ptl = pud_lock(mm, pud); > - page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap); > + if (pud_devmap(pud)) { > + ptl = pud_lock(mm, pudp); > + page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap); > spin_unlock(ptl); > if (page) > return page; > return no_page_table(vma, flags, address); > } > - if (unlikely(pud_bad(*pud))) > + if (unlikely(pud_bad(pud))) > return no_page_table(vma, flags, address); Not your change, but reading this, it's not clear to me that `pud_present(*pudp)` (and non-leaf) would necessarily be true at this point -- like, I would prefer to see `!pud_present(pud)` instead of `pud_bad()`. Thank you for adding that in the next patch. :) Feel free to add: Acked-by: James Houghton <jthoughton@google.com>
On Tue, Dec 19, 2023 at 11:28:54AM -0500, James Houghton wrote: > On Tue, Dec 19, 2023 at 2:57 AM <peterx@redhat.com> wrote: > > > > From: Peter Xu <peterx@redhat.com> > > > > Introduce "pud_t pud" in the function, so the code won't dereference *pudp > > multiple time. Not only because that looks less straightforward, but also > > because if the dereference really happened, it's not clear whether there > > can be race to see different *pudp values if it's being modified at the > > same time. > > > > Signed-off-by: Peter Xu <peterx@redhat.com> > > --- > > mm/gup.c | 17 +++++++++-------- > > 1 file changed, 9 insertions(+), 8 deletions(-) > > > > diff --git a/mm/gup.c b/mm/gup.c > > index 6c0d82fa8cc7..97e87b7a15c3 100644 > > --- a/mm/gup.c > > +++ b/mm/gup.c > > @@ -753,26 +753,27 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma, > > unsigned int flags, > > struct follow_page_context *ctx) > > { > > - pud_t *pud; > > + pud_t *pudp, pud; > > spinlock_t *ptl; > > struct page *page; > > struct mm_struct *mm = vma->vm_mm; > > > > - pud = pud_offset(p4dp, address); > > - if (pud_none(*pud)) > > + pudp = pud_offset(p4dp, address); > > + pud = *pudp; > > I think you might want a READ_ONCE() on this so that the compiler > doesn't actually read the pud multiple times. Makes sense. I probably only did the "split" part which Christoph requested, without thinking futher than that. :) > > > + if (pud_none(pud)) > > return no_page_table(vma, flags, address); > > - if (pud_devmap(*pud)) { > > - ptl = pud_lock(mm, pud); > > - page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap); > > + if (pud_devmap(pud)) { > > + ptl = pud_lock(mm, pudp); > > + page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap); > > spin_unlock(ptl); > > if (page) > > return page; > > return no_page_table(vma, flags, address); > > } > > - if (unlikely(pud_bad(*pud))) > > + if (unlikely(pud_bad(pud))) > > return no_page_table(vma, flags, address); > > Not your change, but reading this, it's not clear to me that > `pud_present(*pudp)` (and non-leaf) would necessarily be true at this > point -- like, I would prefer to see `!pud_present(pud)` instead of > `pud_bad()`. Thank you for adding that in the next patch. :) I think the assumption here is it is expected to be a directory entry when reaching here, and for a valid directory entry pud_present() should always return true (a side note: pud_present() may not mean "PRESENT bit set", see m68k's implementation for example). Yeah I added that in the next patch, my intention was to check !pud_present() for all cases without the need to take pgtable lock, though. > > Feel free to add: > > Acked-by: James Houghton <jthoughton@google.com> Thanks,
diff --git a/mm/gup.c b/mm/gup.c index 6c0d82fa8cc7..97e87b7a15c3 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -753,26 +753,27 @@ static struct page *follow_pud_mask(struct vm_area_struct *vma, unsigned int flags, struct follow_page_context *ctx) { - pud_t *pud; + pud_t *pudp, pud; spinlock_t *ptl; struct page *page; struct mm_struct *mm = vma->vm_mm; - pud = pud_offset(p4dp, address); - if (pud_none(*pud)) + pudp = pud_offset(p4dp, address); + pud = *pudp; + if (pud_none(pud)) return no_page_table(vma, flags, address); - if (pud_devmap(*pud)) { - ptl = pud_lock(mm, pud); - page = follow_devmap_pud(vma, address, pud, flags, &ctx->pgmap); + if (pud_devmap(pud)) { + ptl = pud_lock(mm, pudp); + page = follow_devmap_pud(vma, address, pudp, flags, &ctx->pgmap); spin_unlock(ptl); if (page) return page; return no_page_table(vma, flags, address); } - if (unlikely(pud_bad(*pud))) + if (unlikely(pud_bad(pud))) return no_page_table(vma, flags, address); - return follow_pmd_mask(vma, address, pud, flags, ctx); + return follow_pmd_mask(vma, address, pudp, flags, ctx); } static struct page *follow_p4d_mask(struct vm_area_struct *vma,