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 361B3C4332F for ; Thu, 3 Nov 2022 18:11:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD64D6B0073; Thu, 3 Nov 2022 14:11:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B85F68E0002; Thu, 3 Nov 2022 14:11:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4DCD8E0001; Thu, 3 Nov 2022 14:11:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 94A376B0073 for ; Thu, 3 Nov 2022 14:11:39 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3F7B3140109 for ; Thu, 3 Nov 2022 18:11:39 +0000 (UTC) X-FDA: 80092923918.14.0F00FAA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 7E4D14000A for ; Thu, 3 Nov 2022 18:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667499095; 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=2WMjOJmGY0GsqjDFw7J9b6jhLGxRZTGjZleyCuJ0qI4=; b=c74agBjk9H+CXUKON2rTyAQoqDX/oEt8v8rl1jtXgrkbx3oDQoKg7farquVzVj/WFVUCod DC3JvDe8cluE0d2xIIJgnGc19UhfSPNR1WWgu5I8Bn4XAabJ824DojzGHad3njepw7ta6q Qw/UMmHxCptsNx+h8q3JS6xbaYlobiU= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-411-JK54UIRHPSu9JGF_aimolg-1; Thu, 03 Nov 2022 14:11:34 -0400 X-MC-Unique: JK54UIRHPSu9JGF_aimolg-1 Received: by mail-qt1-f199.google.com with SMTP id i13-20020ac8764d000000b003a4ec8693dcso2354130qtr.14 for ; Thu, 03 Nov 2022 11:11:34 -0700 (PDT) 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=2WMjOJmGY0GsqjDFw7J9b6jhLGxRZTGjZleyCuJ0qI4=; b=b9lHTcdT7L3C7GTM+8td+7/TK7iCaJphTB8/EhJcFZclaor3GOjF+MzvJyz3434cs4 CiWN8EKZ1Hks/axfd27REEdVEwtKYOmsFiDd0kn/2qYuVI7mSIsH+LQv+NwD7Vx0nt+0 fp1PUIwQbf6+EfV3uoH2Cm9UMNNMgQk6sjC3qM9uj6ta3lYFUIO07W2UCO9y59ytDMxU Y/hgVVc5OgfPYAqiTnbinj553jrTqzem+Fgg5MsaXajWUeaq9S8ezbVjKhKWSIdW0BKP 2Lw1ZYYaQDGTqji5db/grOdFiS2JPYERLwOfEGIl+ygeGlNnDWKCYSDURF6YomlorRjc iZxg== X-Gm-Message-State: ACrzQf0VPaFwexYZLDGIJs101ospyI+Rq8EXQLY3vM3AMCIILWtKtnMs FB/UTIBoYXLqtk9K3Q7BYxnzwOLy15WMnGYYe2SRCaD7bdSTbLUHVYyQxKNkWUdjlyy/E8dNBep Tjczz7K4D7zw= X-Received: by 2002:ac8:7190:0:b0:3a5:10c1:5d3d with SMTP id w16-20020ac87190000000b003a510c15d3dmr25252444qto.483.1667499094025; Thu, 03 Nov 2022 11:11:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM45yQ8MdqKISd6W1U+UOvmGYfurrB6CD4B4rFpjr+ZM1lRQ4FxyzPKu9VEbP8mAK7W3NlT0iA== X-Received: by 2002:ac8:7190:0:b0:3a5:10c1:5d3d with SMTP id w16-20020ac87190000000b003a510c15d3dmr25252422qto.483.1667499093772; Thu, 03 Nov 2022 11:11:33 -0700 (PDT) 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 fe4-20020a05622a4d4400b00397b1c60780sm918078qtb.61.2022.11.03.11.11.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Nov 2022 11:11:33 -0700 (PDT) Date: Thu, 3 Nov 2022 14:11:31 -0400 From: Peter Xu To: Mike Kravetz Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , James Houghton , Miaohe Lin , David Hildenbrand , Muchun Song , Andrea Arcangeli , Nadav Amit , Rik van Riel Subject: Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte_offset() for its locking requirements Message-ID: References: <20221030212929.335473-1-peterx@redhat.com> <20221030212929.335473-3-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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667499096; a=rsa-sha256; cv=none; b=kZiGyUiF/cTsOvmrunhpTHVrfTt/HCx1JgE1xbPjKo4UrcVFGJq3X4UrnfIDJlfaYryXB7 ScCIQwPEfZ3/IzWUqaUA/m8iroZQsgDV+pN+JaeYqW2GjZ1O4u561aO1roZQ0a+LYG7Rbn oMYr3SJctDFqDvFr6+cxzRTF+jAwDYE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=c74agBjk; spf=pass (imf01.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=1667499096; 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=2WMjOJmGY0GsqjDFw7J9b6jhLGxRZTGjZleyCuJ0qI4=; b=1HENjQm7d7AkgC13iZD6ybA7u6+YvHinuv8QMhKvXKsfokpstFgTagpEnSwVIG6vTwdrWI WyVByZa4Wot42pR3uiGkdyW4Isroqb9AsXx6d5E+lK+yEs/z+vg75sa+jWGLchzgYJYAca W+/M8ltlXz/bLWwRFNYSZinqrVO/TL0= X-Stat-Signature: shffj9frs3t9dykprxs7hkibrde718t7 X-Rspamd-Server: rspam09 X-Rspam-User: X-Rspamd-Queue-Id: 7E4D14000A Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=c74agBjk; spf=pass (imf01.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 X-HE-Tag: 1667499096-970168 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 Thu, Nov 03, 2022 at 08:42:01AM -0700, Mike Kravetz wrote: > On 10/30/22 17:29, Peter Xu wrote: > > huge_pte_offset() is potentially a pgtable walker, looking up pte_t* for a > > hugetlb address. > > > > Normally, it's always safe to walk the pgtable as long as we're with the > > mmap lock held for either read or write, because that guarantees the > > pgtable pages will always be valid during the process. > > > > But it's not true for hugetlbfs: hugetlbfs has the pmd sharing feature, it > > means that even with mmap lock held, the PUD pgtable page can still go away > > from under us if pmd unsharing is possible during the walk. > > > > It's not always the case, e.g.: > > > > (1) If the mapping is private we're not prone to pmd sharing or > > unsharing, so it's okay. > > > > (2) If we're with the hugetlb vma lock held for either read/write, it's > > okay too because pmd unshare cannot happen at all. > > > > Document all these explicitly for huge_pte_offset(), because it's really > > not that obvious. This also tells all the callers on what it needs to > > guarantee huge_pte_offset() thread-safety. > > > > Signed-off-by: Peter Xu > > --- > > arch/arm64/mm/hugetlbpage.c | 32 ++++++++++++++++++++++++++++++++ > > 1 file changed, 32 insertions(+) > > > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c > > index 35e9a468d13e..0bf930c75d4b 100644 > > --- a/arch/arm64/mm/hugetlbpage.c > > +++ b/arch/arm64/mm/hugetlbpage.c > > @@ -329,6 +329,38 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct vm_area_struct *vma, > > return ptep; > > } > > > > +/* > > + * huge_pte_offset(): Walk the hugetlb pgtable until the last level PTE. > > + * Returns the pte_t* if found, or NULL if the address is not mapped. > > + * > > + * NOTE: since this function will walk all the pgtable pages (including not > > + * only high-level pgtable page, but also PUD that can be unshared > > + * concurrently for VM_SHARED), the caller of this function should be > > + * responsible of its thread safety. One can follow this rule: > > + * > > + * (1) For private mappings: pmd unsharing is not possible, so it'll > > + * always be safe if we're with the mmap sem for either read or write. > > + * This is normally always the case, so IOW we don't need to do > > + * anything special. > > Not sure if it is worth calling out that we are safe if the process owning the > page table being walked is single threaded? Although, a pmd can be 'unshared' > due to an operation in another process, the primary is when the pmd is cleared > which only happens when the unshare is initiated by a thread of the process > owning the page tables being walked. Even if the process is single threaded, the pmd unshare can still trigger from other threads too, am I right? Looking at huge_pmd_unshare() callers, the major ones that doesn't need current mm context are: - __unmap_hugepage_range() (e.g. hole punch from other process on file?) - try_to_unmap_one() - try_to_migrate_one() So for example, even for a single thread process, if its pmd shared with another process, the other process can do (1) punch hole on pmd shared region, then (2) munmap() the pmd shared region, then it seems the single thread process can be still on risk of accessing freed pgtable. Thanks, -- Peter Xu