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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA51AC433EF for ; Mon, 11 Oct 2021 03:45:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5E29560F14 for ; Mon, 11 Oct 2021 03:45:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5E29560F14 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BFE916B006C; Sun, 10 Oct 2021 23:45:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAECB6B0071; Sun, 10 Oct 2021 23:45:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A765C6B0072; Sun, 10 Oct 2021 23:45:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 93E956B006C for ; Sun, 10 Oct 2021 23:45:23 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4BBE02D4A5 for ; Mon, 11 Oct 2021 03:45:23 +0000 (UTC) X-FDA: 78682766526.32.48383CE Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf15.hostedemail.com (Postfix) with ESMTP id F3FC6D001F23 for ; Mon, 11 Oct 2021 03:45:22 +0000 (UTC) Received: by mail-pf1-f176.google.com with SMTP id w6so2130145pfd.11 for ; Sun, 10 Oct 2021 20:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=65ujd5zWPxKALq+MmqVYqoTyiZcmFSF+8wsgTyrTV+k=; b=GOmKg7vgvi8duuzeIia+J3wyH8CQQAAhsJSo0RCw6MdSoO6pjsp1J+eeSt4cDQvw/o IsU3GIeKPYYx1UkDW6D2xZ7Q2163jKJvAZNvK75LvgPfk6M+9bCzuTON9fL4/z+V8xVa FRXn8sgkVxMWK0B6KOGHmSIOvpBmykiQepg7yMGSNYoxJOvowbkRo1UZQYxBbczwdb8M OLQIu6XZJS7wVNzN2tuXdeDWe8piRDeM0A5wA5qZ2mS5gADyMEN14Eb7hESfJ4tym0eO OggNMj94SOo1MFlO/Ao7jEtEcbz7er9AIKBLfrWwiZrXeUZhWBlTlsPf0ho2vZvKXxxU h2qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=65ujd5zWPxKALq+MmqVYqoTyiZcmFSF+8wsgTyrTV+k=; b=tToK9Sv4ZCnkXAle8qOwnD+nUgsfyN25+TEkm+Fy1x8jtiK8pu1XK7xCT6WjjFFz0+ azd84wyONjtvjNVPTAnvSyPxPokUEIGMvOrxOMxdKB7arrMMsP1CpDnvCbOtcXcek7Ep E5i48ZqNU51pxSMQApmOm9fungbAJBMdGYGXh1AxF7h+wfTIBzzO1mHnPAhYGRSKTs9e jC13oCR8M36yIYkl9LhMaybhxjtCWy6G8CHzzPffrpLafV7nFdvEmigBQb0pWzVp87eU sLxOAQclhf1I/RlrBoEdft+XUzKu69uBw5CaziOBrrN3IGNbfFzvX4fXjksNjIL2ms2L OAVw== X-Gm-Message-State: AOAM5332mBys5NgO4c5AocD0mSm3cTeMXzjZADZu8tVhlGCSJl+MhKns 4GSMTNWytWgvfQmPGGd0rwE= X-Google-Smtp-Source: ABdhPJyTjnYl5mbT+ZZypHNSBbzp+kOAPW0Kby6t0DALxE7Ff9cvy2Z0drJdIn/eByUh753t5p8E7Q== X-Received: by 2002:a05:6a00:230e:b0:44c:4f2d:9b00 with SMTP id h14-20020a056a00230e00b0044c4f2d9b00mr23213756pfh.24.1633923921548; Sun, 10 Oct 2021 20:45:21 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id d138sm5840290pfd.74.2021.10.10.20.45.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Oct 2021 20:45:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH 1/2] mm/mprotect: use mmu_gather From: Nadav Amit In-Reply-To: <20210925205423.168858-2-namit@vmware.com> Date: Sun, 10 Oct 2021 20:45:17 -0700 Cc: LKML , Linux-MM , Peter Xu , Andrew Cooper , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Gleixner , Will Deacon , Yu Zhao , Nick Piggin , X86 ML , Andrew Morton , David Hildenbrand Content-Transfer-Encoding: 7bit Message-Id: References: <20210925205423.168858-1-namit@vmware.com> <20210925205423.168858-2-namit@vmware.com> To: Jerome Glisse , Andrea Arcangeli X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F3FC6D001F23 X-Stat-Signature: ui6kdn6rtpqtfoj4mtht8spdgcht918h Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GOmKg7vg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-HE-Tag: 1633923922-844157 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 Sep 25, 2021, at 1:54 PM, Nadav Amit wrote: > > From: Nadav Amit > > change_pXX_range() currently does not use mmu_gather, but instead > implements its own deferred TLB flushes scheme. This both complicates > the code, as developers need to be aware of different invalidation > schemes, and prevents opportunities to avoid TLB flushes or perform them > in finer granularity. > > Use mmu_gather in change_pXX_range(). As the pages are not released, > only record the flushed range using tlb_flush_pXX_range(). Andrea pointed out that I do not take care of THP. Actually, there is indeed a missing TLB flush on THP, but it is not required due to the pmdp_invalidate(). Anyhow, the patch needs to address it cleanly, and to try to avoid the flush on pmdp_invalidate(), which at least on x86 does not appear to be necessary. There is an additional bug, as tlb_change_page_size() needs to be called. -- Jerome, While I am reviewing my (bad) code, I wanted to understand whether update of migration entries requires a TLB flush, because I do not think I got that right either. I thought they should not, but I now am not very sure. I am very confused by the following code in migrate_vma_collect_pmd(): pte_unmap_unlock(ptep - 1, ptl); /* Only flush the TLB if we actually modified any entries */ if (unmapped) flush_tlb_range(walk->vma, start, end); According to this code flush_tlb_range() is called without the ptl. So theoretically there is a possible race: CPU0 CPU1 ---- ---- migrate_vma_collect_pmd() set_pte_at() [ present-> non-present] pte_unmap_unlock() madvise(MADV_DONTNEED) zap_pte_range() [ PTE non-present => no flush ] So my questions: 1. Is there a reason the above scenario is invalid? 2. Does one need to flush a migration entry he updates it? Thanks, Nadav