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 07B16C433F5 for ; Sat, 19 Mar 2022 10:22:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 931DD8D0003; Sat, 19 Mar 2022 06:22:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E23A8D0001; Sat, 19 Mar 2022 06:22:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70D6C8D0003; Sat, 19 Mar 2022 06:22:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 5E5DC8D0001 for ; Sat, 19 Mar 2022 06:22:34 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0F6B71828AC60 for ; Sat, 19 Mar 2022 10:22:34 +0000 (UTC) X-FDA: 79260746628.31.81FE427 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 8C4E1180023 for ; Sat, 19 Mar 2022 10:22:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1647685353; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eYzCtz1CNfRKahEjWPEJ8iTJHu5ovNDwPIFtJOiY5m4=; b=Y+TNcU86pPl1RyVzSzYJ5YGhbPOowTHIzjGWZ78D3wQ9LqRxvgUtvCcK0VoicFLqUhGH2B 4Koekf6nki1Kni/TEvLcaimcDd423YLgUe9j6m/e3WrO+pRthaeYi7CeGngeNzH28HiFZk f7M5JDUHmqBGKlxF0/coxSiVyEwLWfQ= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-223-KJ0hexFsOBOa8NlzPfdB_w-1; Sat, 19 Mar 2022 06:22:31 -0400 X-MC-Unique: KJ0hexFsOBOa8NlzPfdB_w-1 Received: by mail-wm1-f69.google.com with SMTP id c126-20020a1c3584000000b00380dee8a62cso3990520wma.8 for ; Sat, 19 Mar 2022 03:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=eYzCtz1CNfRKahEjWPEJ8iTJHu5ovNDwPIFtJOiY5m4=; b=v+XBrEtBXZ+OqiZeNZIYTeMcnk9t6+zqJphH2GflfJjq0I7zYk7NzkXC4d7dTfKjWE 4iwzLF3O9gTAVqaiohqkBybrJEstzfdUehzFfFUeBq8gj0QRXpWtn49p35wjsUAp/BvW z3URJSmGYIqcae+z5HqL9kAItbmlthxxLsi250ld2TDfMG2RextPb4+b5YuyoQ8YbH8+ topCqRElMXXrxHp9KhWh89qZYX2nojbFoJORK9yIE2/kxIPbxux27VG0FwvxreWYlWFJ TS3Qi3m2wULAcLr0M8mw+1a3Xxckqr3IWQbBynioGoCIW0xJjcAsAzrzUvlm7MbUdNeJ sIQw== X-Gm-Message-State: AOAM531xSvQb0Ty6F/qwBQ9qDy4C6/aQeauV3NIYE5Fa147G6aZ4dn23 4zi0ZyxHCK+yJlINObTHfjcoeGScod5GSFrRDijZ/0pv56E5ae1NEelAI6+VDAnXMcW89RofJl5 fhnRAQgwq0/0= X-Received: by 2002:adf:fd02:0:b0:203:f2aa:37f2 with SMTP id e2-20020adffd02000000b00203f2aa37f2mr7569860wrr.396.1647685350598; Sat, 19 Mar 2022 03:22:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfG/V414ObjvO0GfXKiNYm84GOq5X2QUhUrz5EcUsvg2AQ/ehs8iwkMJnK9/RAUcodn+cBtg== X-Received: by 2002:adf:fd02:0:b0:203:f2aa:37f2 with SMTP id e2-20020adffd02000000b00203f2aa37f2mr7569816wrr.396.1647685350211; Sat, 19 Mar 2022 03:22:30 -0700 (PDT) Received: from ?IPV6:2003:d8:2f24:9200:124e:f0bf:6f8c:cbd8? (p200300d82f249200124ef0bf6f8ccbd8.dip0.t-ipconnect.de. [2003:d8:2f24:9200:124e:f0bf:6f8c:cbd8]) by smtp.gmail.com with ESMTPSA id v20-20020a7bcb54000000b0037fa63db8aasm12327769wmj.5.2022.03.19.03.22.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Mar 2022 03:22:29 -0700 (PDT) Message-ID: <0178ec26-f957-159d-a163-a98557de7156@redhat.com> Date: Sat, 19 Mar 2022 11:22:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2 15/15] mm/gup: sanity-check with CONFIG_DEBUG_VM that anonymous pages are exclusive when (un)pinning To: Jason Gunthorpe Cc: linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , linux-mm@kvack.org References: <20220315104741.63071-1-david@redhat.com> <20220315104741.63071-16-david@redhat.com> <20220318233527.GB11336@nvidia.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220318233527.GB11336@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8C4E1180023 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Y+TNcU86; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: 8p53s4dnzkfjj9hkmp39och1mefd4bk6 X-Rspamd-Server: rspam04 X-HE-Tag: 1647685353-352803 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 19.03.22 00:35, Jason Gunthorpe wrote: > On Tue, Mar 15, 2022 at 11:47:41AM +0100, David Hildenbrand wrote: >> Let's verify when (un)pinning anonymous pages that we always deal with >> exclusive anonymous pages, which guarantees that we'll have a reliable >> PIN, meaning that we cannot end up with the GUP pin being inconsistent >> with he pages mapped into the page tables due to a COW triggered >> by a write fault. >> >> When pinning pages, after conditionally triggering GUP unsharing of >> possibly shared anonymous pages, we should always only see exclusive >> anonymous pages. Note that anonymous pages that are mapped writable >> must be marked exclusive, otherwise we'd have a BUG. >> >> When pinning during ordinary GUP, simply add a check after our >> conditional GUP-triggered unsharing checks. As we know exactly how the >> page is mapped, we know exactly in which page we have to check for >> PageAnonExclusive(). >> >> When pinning via GUP-fast we have to be careful, because we can race with >> fork(): verify only after we made sure via the seqcount that we didn't >> race with concurrent fork() that we didn't end up pinning a possibly >> shared anonymous page. >> >> Similarly, when unpinning, verify that the pages are still marked as >> exclusive: otherwise something turned the pages possibly shared, which >> can result in random memory corruptions, which we really want to catch. >> >> With only the pinned pages at hand and not the actual page table entries >> we have to be a bit careful: hugetlb pages are always mapped via a >> single logical page table entry referencing the head page and >> PG_anon_exclusive of the head page applies. Anon THP are a bit more >> complicated, because we might have obtained the page reference either via >> a PMD or a PTE -- depending on the mapping type we either have to check >> PageAnonExclusive of the head page (PMD-mapped THP) or the tail page >> (PTE-mapped THP) applies: as we don't know and to make our life easier, >> check that either is set. >> >> Take care to not verify in case we're unpinning during GUP-fast because >> we detected concurrent fork(): we might stumble over an anonymous page >> that is now shared. >> >> Signed-off-by: David Hildenbrand >> mm/gup.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++- >> mm/huge_memory.c | 3 +++ >> mm/hugetlb.c | 3 +++ >> 3 files changed, 63 insertions(+), 1 deletion(-) >> >> diff --git a/mm/gup.c b/mm/gup.c >> index 92dcd92f9d67..72e39b77da10 100644 >> +++ b/mm/gup.c >> @@ -45,6 +45,38 @@ static void hpage_pincount_sub(struct page *page, int refs) >> atomic_sub(refs, compound_pincount_ptr(page)); >> } >> >> +static inline void sanity_check_pinned_pages(struct page **pages, >> + unsigned long npages) >> +{ >> +#ifdef CONFIG_DEBUG_VM > > Perhaps: > > if (!IS_ENABLED(CONFIG_DEBUG_VM)) > return; > > So this gets compilation coverage Makes sense, that code should compile just fine without CONFIG_DEBUG_VM. Thanks! -- Thanks, David / dhildenb