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 10E71ECAAD4 for ; Wed, 31 Aug 2022 19:33:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 801F78D0001; Wed, 31 Aug 2022 15:33:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B15C6B0073; Wed, 31 Aug 2022 15:33:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 652208D0001; Wed, 31 Aug 2022 15:33:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 525A36B0072 for ; Wed, 31 Aug 2022 15:33:39 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2B34B1A03AD for ; Wed, 31 Aug 2022 19:33:39 +0000 (UTC) X-FDA: 79860887358.31.F7C22FE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id C0AD714005A for ; Wed, 31 Aug 2022 19:33:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661974418; 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=UqeSI+PCWfCsmnj3LueCL7MyoyIRpFEzhaDk1BD2TtU=; b=TP8kYAHojad3htRCO6ZtK3sA1xf+tOMXtrGPK8FiG8YJckxwLqkUwIupOqZSP6NBLEIgTU qM8KChXYJej4DZp4jbcOsyBOZRuX6JyfcQVaYc/jRNuHRxLCH/VCBsKl2t9OwCHHT4GWly xDa1+7BuSRoMwOSGn1L0JzGECJXU3IQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-584-8zAGn_JlPg6xGw-ZABy3Lg-1; Wed, 31 Aug 2022 15:33:35 -0400 X-MC-Unique: 8zAGn_JlPg6xGw-ZABy3Lg-1 Received: by mail-wm1-f71.google.com with SMTP id q16-20020a1cf310000000b003a626026ed1so54662wmq.4 for ; Wed, 31 Aug 2022 12:33:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=UqeSI+PCWfCsmnj3LueCL7MyoyIRpFEzhaDk1BD2TtU=; b=bLn2G5I3mSDkM5D+wYSSeawjy+R+CBgR1y8rn43vQb5mh4ztCPh079LGTDHG78MBHU Tj9gM9Txnxz9SHPsoCxTp0HxAiFIZQh8uHAGM7mdYY9tVX66aH+u/tqm98hTyhHBBLlq H1INXah0K8mRQD78/nYNrpVS+JtgHyiux+s3wQls8M9xpcNAWpbICdo80XOcaBVKD2rD X50X3OEqw1BhlrsS4ZeeLpN18bwbbCGRovS2sR/We+maD7NFhP3i7gmHVm4mLgW1DC+i +d3RL9qmriNkYRCMPPjlvFRx8V9wErrtRoe8CNSn+LA44LQsyzv0qIgnN3wYwVE39mSs CsNg== X-Gm-Message-State: ACgBeo0rIoKakm7omC/yv3KA4UkAVIZ4hDja0m6hugG8td8ViaaCdeF1 qXvFgpfYWnqcQ5/0ZluSMObEBjB3iLTsX5+wSYv9wUChuf1kkDTp+GnH9Oo1GTHrtiA4U46OXmC fhq8soMrKnYs= X-Received: by 2002:a5d:4243:0:b0:226:d45a:3ca6 with SMTP id s3-20020a5d4243000000b00226d45a3ca6mr11319574wrr.588.1661974413855; Wed, 31 Aug 2022 12:33:33 -0700 (PDT) X-Google-Smtp-Source: AA6agR5cqVLd0vaAJsaAhfmYELGkiIyNKNB/GXQqVkzak4unNSaEWjD9RzuZpOJA3n1ed6OiYJEp4Q== X-Received: by 2002:a5d:4243:0:b0:226:d45a:3ca6 with SMTP id s3-20020a5d4243000000b00226d45a3ca6mr11319564wrr.588.1661974413633; Wed, 31 Aug 2022 12:33:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c706:2900:1613:4308:aca3:2786? (p200300cbc706290016134308aca32786.dip0.t-ipconnect.de. [2003:cb:c706:2900:1613:4308:aca3:2786]) by smtp.gmail.com with ESMTPSA id az19-20020a05600c601300b003a342933727sm3201581wmb.3.2022.08.31.12.33.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Aug 2022 12:33:31 -0700 (PDT) Message-ID: <9378bae6-e84f-113f-b41c-60a09c095243@redhat.com> Date: Wed, 31 Aug 2022 21:33:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v1] mm/ksm: update stale comment in write_protect_page() From: David Hildenbrand To: Yang Shi Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Jason Gunthorpe , John Hubbard , Andrea Arcangeli , Hugh Dickins , Peter Xu , "Kirill A. Shutemov" References: <20220831083024.37138-1-david@redhat.com> <4845ae71-b7dd-1707-ebc3-2eb3521e7fa0@redhat.com> Organization: Red Hat In-Reply-To: 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661974418; a=rsa-sha256; cv=none; b=PfoiATrs8yjwdFrjzbmrgoX9qKi56s8+1BkjGjNLhHoDqy15tX/dF6dpT7pDeqTRxt9OrN IBW2GDl4YWShTr3yW0BmrkF8x8j8kK4SWbD7O9JBWviH7/spwSIwKMfMxrICcRnZH4FP9d u202482Clz4iyAeu5vKudgvqYD1/0so= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TP8kYAHo; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@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=1661974418; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UqeSI+PCWfCsmnj3LueCL7MyoyIRpFEzhaDk1BD2TtU=; b=kffEErzsQZuzDisD7jtHTqSJ9neuPyVN3q2JqdvvUYOoLKGTHQWjohj4GoS8Shun5VB4WZ N0ZEHsa0QpYbti9U3ZAOdB+DRwExDNcjwXO/bl2XJS5vJlNxj7igxS5g2DmBQQpzy9fErs sgrsTMilU2GulJhhBgzwJHlCCp/MTH8= X-Rspam-User: X-Stat-Signature: cjqyjhaky85it7y39k1kspqqi6ec9c5h X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C0AD714005A Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TP8kYAHo; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1661974418-132591 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 31.08.22 21:15, David Hildenbrand wrote: > On 31.08.22 21:08, Yang Shi wrote: >> On Wed, Aug 31, 2022 at 11:29 AM David Hildenbrand wrote: >>> >>> On 31.08.22 19:55, Yang Shi wrote: >>>> On Wed, Aug 31, 2022 at 1:30 AM David Hildenbrand wrote: >>>>> >>>>> The comment is stale, because a TLB flush is no longer sufficient and >>>>> required to synchronize against concurrent GUP-fast. This used to be true >>>>> in the past, whereby a TLB flush would have implied an IPI on architectures >>>>> that support GUP-fast, resulting in GUP-fast that disables local interrupts >>>>> from completing before completing the flush. >>>> >>>> Hmm... it seems there might be problem for THP collapse IIUC. THP >>>> collapse clears and flushes pmd before doing anything on pte and >>>> relies on interrupt disable of fast GUP to serialize against fast GUP. >>>> But if TLB flush is no longer sufficient, then we may run into the >>>> below race IIUC: >>>> >>>> CPU A CPU B >>>> THP collapse fast GUP >>>> >>>> gup_pmd_range() <-- see valid pmd >>>> >>>> gup_pte_range() <-- work on pte >>>> clear pmd and flush TLB >>>> __collapse_huge_page_isolate() >>>> isolate page <-- before GUP bump refcount >>>> >>>> pin the page >>>> __collapse_huge_page_copy() >>>> copy data to huge page >>>> clear pte (don't flush TLB) >>>> Install huge pmd for huge page >>>> >>>> return the obsolete page >>> >>> Hm, the is_refcount_suitable() check runs while the PTE hasn't been >>> cleared yet. And we don't check if the PMD changed once we're in >>> gup_pte_range(). >> >> Yes >> >>> >>> The comment most certainly should be stale as well -- unless there is >>> some kind of an implicit IPI broadcast being done. >>> >>> 2667f50e8b81 mentions: "The RCU page table free logic coupled with an >>> IPI broadcast on THP split (which is a rare event), allows one to >>> protect a page table walker by merely disabling the interrupts during >>> the walk." >>> >>> I'm not able to quickly locate that IPI broadcast -- maybe there is one >>> being done here (in collapse) as well? >> >> The TLB flush may call IPI. I'm supposed it is arch dependent, right? >> Some do use IPI, some may not. > > Right, and the whole idea of the RCU GUP-fast was to support > architectures that don't do it. x86-64 does it. IIRC, powerpc doesn't do > it -- but maybe it does so for PMDs? Looking into the details (and the outdated comment for gup_pte_range() we should fixup), THP splitting used in the past pmdp_splitting_flush() for triggering an IPI broadcast. However, that has been removed in 4b471e8898c3 ("mm, thp: remove infrastructure for handling splitting PMDs") due to refcount handling changes that no longer require it. Consequently, I don't think we can expect an IPI broadcast to sync with GUP-fast at that point ... -- Thanks, David / dhildenb