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 9950EECAAD4 for ; Wed, 31 Aug 2022 21:44:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A3B76B0072; Wed, 31 Aug 2022 17:44:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 153466B0073; Wed, 31 Aug 2022 17:44:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F36408D0001; Wed, 31 Aug 2022 17:44:47 -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 E41CA6B0072 for ; Wed, 31 Aug 2022 17:44:47 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B9874407F5 for ; Wed, 31 Aug 2022 21:44:47 +0000 (UTC) X-FDA: 79861217814.03.E9B71B3 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf01.hostedemail.com (Postfix) with ESMTP id 5E7CD40037 for ; Wed, 31 Aug 2022 21:44:47 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id z3-20020a17090abd8300b001fd803e34f1so570213pjr.1 for ; Wed, 31 Aug 2022 14:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=WRCQZgWLTXU/lpwaQlz63bh8ZvhuW6knrkLWrQ9v+Ds=; b=DHX2VRhksok+uLiBnn5V9eNyQQ6MwdoobPxth/5Ok1rK0Lb3E4TIsiEGwWMxYGYSQx Dj8Dxjvu4F/y2801SdQtXiPkrNlyF0leyPC/W4BzZi8Zfg1KqA9jMIFPRQJ6NSQhH0si 82PMXpVUg1TEwi58+eg/k8yoxwvaU4rCjawWNsKU5KdWNU9VwI424vkwqBQhEd7E2WhL UPLGytahb8T6YERt11ky+8I2I1+xEKdk69wgypF+QqLyKdukTML83N7Qa24y3ywsR4Zd jJ68BV04GQryJkVUgSR2vQh3eCAIuTAAtHy0UdswJ9yIf05/3LJM28UfxsnPYI0WRsgc yzSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=WRCQZgWLTXU/lpwaQlz63bh8ZvhuW6knrkLWrQ9v+Ds=; b=UEm5xaNS0tyrDhkxpJUeBgL4bl2vPXm4AfMvyG4KAZQmA6rQTlGQPaabeV3sddrM4r 7EFhkOTfioLUxOCxEe6SQjnZaI+/5dYgyCvgwTPPPxa3zoNvW65VsNMIqvMTfwxZkIB/ eSUiKGv26ls0IGbJaDMxJGiMvuVmwPQX4i78iVvlFTOIyoHsS46qKXWZ8O9ia8fJsO+H JL5/NLdM2LbiCM6H/Ko7UcEiFRntCa/uor84v9ILggf5MKD/Je9WC4+P5XhPTBdXlamn oqyfkFbv1Oa7XfG2k5pbg5TlmVCGZ0p07rGcX3zCSVVwFJqd939H7dWkTe88tQZ9gky4 JX6g== X-Gm-Message-State: ACgBeo2pq4wcT0/Q2KI8SaNHrDFInxUq83dpr1WcSa/3LS+1kZZp+ESn FrUA97F1uN3laQHJmGTFx8z6MXBppsJkEEnAU00= X-Google-Smtp-Source: AA6agR6yLUEaa+unbuL6M919BQOAcjP+MXwl8XGRVKd+X2QiYw2s3p6yCo+0ISBgxX/ZLvYXfuU7FGSjEpnZrt00xKU= X-Received: by 2002:a17:902:e5c3:b0:175:534:1735 with SMTP id u3-20020a170902e5c300b0017505341735mr11716724plf.87.1661982286512; Wed, 31 Aug 2022 14:44:46 -0700 (PDT) MIME-Version: 1.0 References: <20220831083024.37138-1-david@redhat.com> In-Reply-To: From: Yang Shi Date: Wed, 31 Aug 2022 14:44:33 -0700 Message-ID: Subject: Re: [PATCH v1] mm/ksm: update stale comment in write_protect_page() To: Peter Xu 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" Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=DHX2VRhk; spf=pass (imf01.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661982287; a=rsa-sha256; cv=none; b=DCaBFfI8xMYAifgSbvAKV5baL5xkGkTWwdBjNibbLwv5rphpEchqRIiBQLyOiW6c8XPgpk XYuq6UyRVWpB7BRsMla5M0hoE79noc8bDdnqTdzL3aVJUqYwQs2U5slOH9BrA17cKPRKQk mTUl/ywMOAycrrUMvTbgxUnz+IoyZEo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661982287; 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=WRCQZgWLTXU/lpwaQlz63bh8ZvhuW6knrkLWrQ9v+Ds=; b=3tvgQTWO74XMG7Kvzuj0O2u5dxZA3qulPil3anP668PD6BxmQ9cAxOnDdMjePrQs0E272c zREnWRS/f3ZRoUiKoPJi4aovhYDQQYUIun1b9/2yTEJ9L4OHfiS8Okk0EidXybpcvzurd7 Ax7ETYrHVyXGETPIPtOCnULtrmneo10= X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5E7CD40037 X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=DHX2VRhk; spf=pass (imf01.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: 1ygmtjf1ti7ec465hdhdpedqqx9nu3rz X-HE-Tag: 1661982287-987118 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 2:09 PM Peter Xu wrote: > > 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. Yeah, so ptep_clear() is used in __collapse_huge_page_copy() instead of clear and flush. > > 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. This was what I thought before I saw this patch. > > -- > Peter Xu >