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 8AEF8C5B543 for ; Fri, 30 May 2025 16:27:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 230626B0168; Fri, 30 May 2025 12:27:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E02F6B016A; Fri, 30 May 2025 12:27:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A8846B016B; Fri, 30 May 2025 12:27:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DCFAF6B0168 for ; Fri, 30 May 2025 12:27:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 99A3D1A0FBF for ; Fri, 30 May 2025 16:27:24 +0000 (UTC) X-FDA: 83500104408.27.B86ECFA Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf10.hostedemail.com (Postfix) with ESMTP id A2387C000B for ; Fri, 30 May 2025 16:27:22 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LSo2bfGy; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748622442; 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=Wb7EzNeuZNtT7LoNB6YIvTwNTIj8nYWDYSy4GeuX+MM=; b=wz5EBiZJ45zR2zwzIeQ7ttHiPq0sigh8ku1Xj/khczFUrbDKkiz8XYdamf46F8Ub+4nvx8 3tV1eTHlSRtIv9Qde60X93oV+cGbzj9zpDy7ZeRgeWROaldfD+xpUFWZeHrXhTONAA1DpA kDTSigmAo5r3MAFtOLq9RGquyVU25Ho= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LSo2bfGy; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748622442; a=rsa-sha256; cv=none; b=ES0YNJxqMN/9ugL1AgVegPeR7cu8gkgGUYvQDRHBiZAdJ1zc4TwXG2uo2AziR3RE94pJxr LDUk1jcfdkLOdT2NcZzyWZQtrXt29kRqLCwEnD7FAGkdAm+gW2hiP97t2ESXgzDL4Ldjve Ph5eq4/mQE9sR82eUrxaO7RXR/CbN+s= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-6000791e832so11063a12.1 for ; Fri, 30 May 2025 09:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1748622441; x=1749227241; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Wb7EzNeuZNtT7LoNB6YIvTwNTIj8nYWDYSy4GeuX+MM=; b=LSo2bfGyJ7LK9pZno2QFeWqJXpLZCUIrWU2Okzpgo002DYB3aTA9qaR0hDCH/I6lBX RDMkjd0zt5Kjsudzerku162hWy9JMOWBxgKhJOf4vBBUpvtTDLn0X0hx8TbviEDfu+jb pXgl1u2NW9EVF/a/ZF1lob1So5QxI86CB1qXQUUG/B5vN5/DESoqVrryVmPY7Eru4nNM LCAw1bwL1OsBzQ7KX8VDQbDeIHBMRPvSSQxf/QsSxXD7SEQV0I3UJ7gnX4CrWnDq29MN IQ5d2EPNKEJP2OKIlx0B/AYr+xo3WsJtZMiN+TNBrh32R6T2cpC/a+3y5tTttFA64dhX k+8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748622441; x=1749227241; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Wb7EzNeuZNtT7LoNB6YIvTwNTIj8nYWDYSy4GeuX+MM=; b=uy7kcuBB+q22X2av5zQa82x/9LR72fKdp9xPXurlizyHgYg2GkI3UAlu/eQEFJ1wNu Unb1W3Ih4FTqj86hycsC9sqBnXdSmo9v1Bt01UBUG6SYIdP+9aZ3RATYo8KUIxZhg9zI 0Jm+R2uZQOEfxiT6q1W8w7/dL/e1PXwhmGEDsU3H0oVGWrVgdmFTh+yW8W3LC4HGb0o7 Gogg21FKlQKgLj30fpDMK48d4W1LIcceps8PHwi7rjlSKKeoqfKPh+SfyHy97pE8exR7 bVulUSM0HFXSAZnEQtF2p4JZQ0mgokYgtz+7vB3I2hUerXea6SEjHx2aFhoAnIqKdFSA kgzA== X-Forwarded-Encrypted: i=1; AJvYcCXLW6liDrL+dl7u8kMG4IsXnaX/jtJBJIbJbfUg3J09fAdz55dl32vph58xbAoKwT1hHpXnMpXADw==@kvack.org X-Gm-Message-State: AOJu0YzE9iqolqK7RM1epANqT5TrSWD6QT1cMTDpmW4Sp6l9I0YQT8rU cmb1Y62ePqQwcBbegmEx20H/0LfKxDpOTAbCpHXqRDPPPh8xSvgrUhAGkmoBIbZH9lsMo8QZYIE SI0gYPP6K9qiTI+N8gscmaEl6RmIAIqrvA/ncuQu3 X-Gm-Gg: ASbGncsNF+zudYijvqZ+z5J1w+r+oetmOKbKqhQpQ1bYOL6XSPU854eGjaZhuX53oly eB6GlHM1eXddXtCbAwWEq3RC/VYGQF+hYVx23ExtAq2ABplCZkmjEPO+qsmLT5+Zq1Rjj8nGw08 tlLAZcpQS55gh3HTL/7jIZ1l1ZQ5ebI/JD72h0yc2CHtnauUHjEhpU5xZbzTPt5cJaYxb3DoQ= X-Google-Smtp-Source: AGHT+IFvo4UeYXqvvR6hGpmlYjccx/P9qAgBVyNpakUtwWnk/plyYyjpSLFfr/exrsOHq2DB2NbEp4NJnsA/fPm9vYQ= X-Received: by 2002:a50:f608:0:b0:5e6:15d3:ffe7 with SMTP id 4fb4d7f45d1cf-60577a55f40mr88916a12.7.1748622440589; Fri, 30 May 2025 09:27:20 -0700 (PDT) MIME-Version: 1.0 References: <20250530140446.2387131-1-ryan.roberts@arm.com> <20250530140446.2387131-2-ryan.roberts@arm.com> In-Reply-To: <20250530140446.2387131-2-ryan.roberts@arm.com> From: Jann Horn Date: Fri, 30 May 2025 18:26:44 +0200 X-Gm-Features: AX0GCFt5gaAeg9wlqckCjWiqvoyfvAtwj8XYq0jNIyzkBuWgoy0LcwI3HloBVMo Message-ID: Subject: Re: [RFC PATCH v1 1/6] fs/proc/task_mmu: Fix pte update and tlb maintenance ordering in pagemap_scan_pmd_entry() To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "David S. Miller" , Andreas Larsson , Juergen Gross , Ajay Kaher , Alexey Makhalov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Boris Ostrovsky , "Aneesh Kumar K.V" , Andrew Morton , Peter Zijlstra , Arnd Bergmann , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Alexei Starovoitov , Andrey Ryabinin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, linux-mm@kvack.org, Andy Lutomirski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: A2387C000B X-Rspamd-Server: rspam09 X-Stat-Signature: 6jdcte57udqq9atyozifarrpm97knrqz X-HE-Tag: 1748622442-232478 X-HE-Meta: U2FsdGVkX18Gp+qOYQBiRnyM5qNzoTZw34f3KLN4jxJe8b+PmWNpD/TKgXk5wlMXjJ7GPLfyqw9cROwJcU6723/hop9Riwfd4j3OixTw/PkEq5+XacH8XAwq7E/NTB7wWoMhMJ6znc2b+xrqaujDDJpd1G28E0NkIimB+T3JLVByeIqq2MsB3n0uRaRknbMKEJajsnVBn3tZs5wXSCG1vM5zue+XtnreVRkvNYSmA+pLSzVlS3N9JZfPXOHWmNW0gZK/BOt8OAb5Iihg/HGUgIOMHfz0cd5KkLk8arFi8mRUDmeSoIqzUQi/yBJlJo8YbzD3q79CH/Xf4IUUoiHtuUTBaZOwSW6C/SHOVNEOQ1n2k/Blg3IBafUtChD5FNUE9ztRKmQ6gdlyT/sckKGF1DAVzUawiCpmJXAPRbQ3magaw+bUwr48ieRXDE/BlVulFOJZ8wYypxpesXZcow6c8ClWxH07+pU6L7S8HsiTBuOF4KU8+oMRl9etqlMdtZls1N4bV74DDJ8WH90Mnx7zuszyo9jjDPGSEpdczw4B0ChZbRu/17M+2EAfcrxEJNzSCFX3nSL7KetY9gXuvgT72AWT9WkVK+VO0FxdjG5gVdAKONvLRCsXi1mTVsUcAjqZIh5ffTbNZdvHdtCyPlPLVERcqEZgdyWHcuP2Dm7mHOiFN8ewlOjtY8pTf7F5n22o7+NVAYB2L5mdkhkhnU0q2Pn+0dW0XR8xCeopxC6bn/xjY7EaS9JC9CA4v6U9T7c4cLSK6CcXNo1Ahn8rpUe3bPsrd1fFdzvsLrm1pIgsC6YluF2SHqvUBdRpyAhxc5XCxRvpMX2bTtcsxHcdd/gL+jxW9+3jZMNRle99ZJ0kIBSA+vgB7iTa/zb1+MP5ZTV+fEc/Kh9nP0OS6gSUCfyUjLChVpaR9p4P9vYfGADON5iwEAIvvqEiHS5B8p9Q27coacfUOy7Wdve0H9bxLp5 gvXClAhU loR/3XNsnljHE0vFtL11Q30rlowZ1Af5oouHrTJH4QJv0Y14LMvI3e6QjGiPL2RFGBJMaSBN3JF4fX1paMJXtXgwLFCXeuxVe4h+CMqEyfIP4aMaxrDXSXAwQV9McXOXQNom+9+xPKKvC5Lgbj1+naKRMTjzo6kf1g8YppiS5lYzNnI7yxR1/mlPrpIQ2xpZs7HnI9EE085GFUK5k6oSJQYJGjLE+m5o+810AQ9Gzo3/ifs3EqYeHlZIm3p7JQLlcDoxI/52Ln0XBFS8v6FdXcRUunAZgnSVizVneOZIa6wR+qpDpibRBGTL+TYsI/yXCPxjkH9WV94I6VQWQSEf06xSnjf+HeR15JXV3vzpJNAId2Vz5nKVpnUM47Q== 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: List-Subscribe: List-Unsubscribe: On Fri, May 30, 2025 at 4:04=E2=80=AFPM Ryan Roberts = wrote: > pagemap_scan_pmd_entry() was previously modifying ptes while in lazy mmu > mode, then performing tlb maintenance for the modified ptes, then > leaving lazy mmu mode. But any pte modifications during lazy mmu mode > may be deferred until arch_leave_lazy_mmu_mode(), inverting the required > ordering between pte modificaiton and tlb maintenance. > > Let's fix that by leaving mmu mode, forcing all the pte updates to be > actioned, before doing the tlb maintenance. > > This is a theorectical bug discovered during code review. > > Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and option= ally clear info about PTEs") Hmm... isn't lazy mmu mode supposed to also delay TLB flushes, and preserve the ordering of PTE modifications and TLB flushes? Looking at the existing implementations of lazy MMU: - In Xen PV implementation of lazy MMU, I see that TLB flush hypercalls are delayed as well (xen_flush_tlb(), xen_flush_tlb_one_user() and xen_flush_tlb_multi() all use xen_mc_issue(XEN_LAZY_MMU) which delays issuing if lazymmu is active). - The sparc version also seems to delay TLB flushes, and sparc's arch_leave_lazy_mmu_mode() seems to do TLB flushes via flush_tlb_pending() if necessary. - powerpc's arch_leave_lazy_mmu_mode() also seems to do TLB flushes. Am I missing something? If arm64 requires different semantics compared to all existing implementations and doesn't delay TLB flushes for lazy mmu mode, I think the "Fixes" tag should point to your addition of lazy mmu support for arm64. > Signed-off-by: Ryan Roberts > --- > fs/proc/task_mmu.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 994cde10e3f4..361f3ffd9a0c 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -2557,10 +2557,9 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsi= gned long start, > } > > flush_and_return: > + arch_leave_lazy_mmu_mode(); > if (flush_end) > flush_tlb_range(vma, start, addr); > - > - arch_leave_lazy_mmu_mode(); I think this ordering was probably intentional, because doing it this way around allows Xen PV to avoid one more hypercall, because the TLB flush can be batched together with the page table changes? > pte_unmap_unlock(start_pte, ptl); > > cond_resched(); > -- > 2.43.0 >