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 85086ECAAD4 for ; Wed, 31 Aug 2022 21:09:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDE3D6B0072; Wed, 31 Aug 2022 17:09:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8CE28D0001; Wed, 31 Aug 2022 17:09:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D549F6B0074; Wed, 31 Aug 2022 17:09:22 -0400 (EDT) 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 C48C86B0072 for ; Wed, 31 Aug 2022 17:09:22 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 93E8280C20 for ; Wed, 31 Aug 2022 21:09:22 +0000 (UTC) X-FDA: 79861128564.05.AE3DDC2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 392C0A0037 for ; Wed, 31 Aug 2022 21:09:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661980161; 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=O7Gxcm/s5JjFXHzoKoyt8QS8s8qTIKG6E+N6uf7ppnw=; b=FAb4WlklL3KknZOocXoXZ8D6js2ET7AOFnp7RgoL0IxK9nMZIkMLZyxPZJqmc87rPe2uQG ee2YzgCO4Z1Ii6VZ3AqauvTkcHUvBbuy7wmLCVuUs1IXzIEaxHLeiJiVzf6ZE7rOZ8TNzh S3jpkEltYZADx0PM6OZIngsWs4WIEfM= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-408-uRDaRlWyNgKvp_iyz3o-Cg-1; Wed, 31 Aug 2022 17:09:20 -0400 X-MC-Unique: uRDaRlWyNgKvp_iyz3o-Cg-1 Received: by mail-qt1-f200.google.com with SMTP id k9-20020ac80749000000b0034302b53c6cso12260702qth.22 for ; Wed, 31 Aug 2022 14:09:20 -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; bh=O7Gxcm/s5JjFXHzoKoyt8QS8s8qTIKG6E+N6uf7ppnw=; b=0K2KadntXxY2iq0hLHy/ny0sCCXaPY1l9konpK/PbMYUBxs5s7de5k+oz+3E+yCi5B m7Mx/Pcml5xAr+LPWPyWWXys6tHzco6uijVJHTG9A6jf/GNn5iiuCNPrV5Y9PENOVyQY nhuoFy4idkCYUB5akzH/ICRTQLwaQlGK/h/Gl17XoI1xHIAhgrFO86BxkB+e4k9IRolM E4t1z+XaxN0m9ipPLG2zK8ATYU3+SrW7SHhDvykl0WuWDQ9WIKKEKiHW5O6msSmoZZ+a FDDFemCP1sBQoiCkcKy6OHPTHpScukpsTe/RXs/nOJ99ewTNKyBtXGHuBZYDf+Mgvuk7 T9PQ== X-Gm-Message-State: ACgBeo2EKHV9NV3Sci6IMP/lc2Hh0lGDCC4ac9s32suM/riHF37YFI34 uz/oNloHan0gH//1E6p2YEi+IiucqnpSKNJlR5xkl/HNqa0XgLq4LZ7YYLQLV0D4Lf32Kbsnctz SfChdmjAMyfA= X-Received: by 2002:a05:6214:2a4b:b0:499:eb9:6ed3 with SMTP id jf11-20020a0562142a4b00b004990eb96ed3mr9976095qvb.66.1661980160119; Wed, 31 Aug 2022 14:09:20 -0700 (PDT) X-Google-Smtp-Source: AA6agR7KnucFaurEW/OxhH/oVN1y7qvS5ITOg5YIp5lqcCuKoGcQLmHlVatvAlu9P/DXe+Mq5ON7rA== X-Received: by 2002:a05:6214:2a4b:b0:499:eb9:6ed3 with SMTP id jf11-20020a0562142a4b00b004990eb96ed3mr9976082qvb.66.1661980159943; Wed, 31 Aug 2022 14:09:19 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-35-70-27-3-10.dsl.bell.ca. [70.27.3.10]) by smtp.gmail.com with ESMTPSA id s18-20020a05620a255200b006bbc09af9f5sm11066305qko.101.2022.08.31.14.09.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 14:09:19 -0700 (PDT) Date: Wed, 31 Aug 2022 17:09:17 -0400 From: Peter Xu To: Yang Shi Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Jason Gunthorpe , John Hubbard , Andrea Arcangeli , Hugh Dickins , "Kirill A. Shutemov" Subject: Re: [PATCH v1] mm/ksm: update stale comment in write_protect_page() Message-ID: References: <20220831083024.37138-1-david@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=1661980162; a=rsa-sha256; cv=none; b=YjSaiiqwFADb8HRLr0jUy+GxVULffw09dxBDi48JdkdZnbLxIDtzNOvu/QnfsvN2+TuE/g ahoC6OSB5EkzEW1no3CXgp8QNTc/bLaHSZoiTdfxNPILSr59CLIbc2Tj3SSX6K2vF9QNjX 4QtNof2idw1+/EiSar91dPA5Ij4j6Pw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FAb4Wlkl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661980162; 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=O7Gxcm/s5JjFXHzoKoyt8QS8s8qTIKG6E+N6uf7ppnw=; b=Nzus/CAWZz2kW+KYDB06pYQNdRM/8lrugtfihw46hEcDmcqjTORCpB4b7bZklkemoOf4qZ fAPvIZ1VrcVSvmQudB7i6glDMs0F3vWU5pYmjymzXnsqt7OE/ix1qVRbc6SRBVSehD82iP ToBjlNmoItb563F6AzT597r77r8lOqM= X-Rspamd-Queue-Id: 392C0A0037 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FAb4Wlkl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: jd7i7itmgm14r9pxk8wgxnbw18o9mu1e X-HE-Tag: 1661980162-403543 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 Wed, Aug 31, 2022 at 01:38:21PM -0700, Yang Shi wrote: > On Wed, Aug 31, 2022 at 11:52 AM Peter Xu wrote: > > > > On Wed, Aug 31, 2022 at 10:55:43AM -0700, 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 > > > > Maybe the pmd level tlb flush is still needed, but on pte level it's > > optional (where we can rely on fast-gup rechecking on the pte change)? > > Do you mean in khugepaged? What I wanted to say before was that the immediate tlb flush (after pgtable entry cleared) seems to be only needed by pmd level to guarantee safety with concurrent fast-gup, since fast-gup can detect pte change after pinning, and that should already guarantee safe concurrent fast-gup to me. After reading the other emails, afaiu we're on the same page. > It does TLB flush, but some arches may not use IPI. Yeah, I see that ppc book3s code has customized pmdp_collapse_flush() to explicit do the IPIs besides tlb flush using smp calls. I assume pmdp_collapse_flush() should always be properly implemented to guarantee safety against fast-gup, or I also agree it could be a bug. -- Peter Xu