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 577CEC54E58 for ; Tue, 26 Mar 2024 08:54:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9771F6B0089; Tue, 26 Mar 2024 04:54:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 927596B008A; Tue, 26 Mar 2024 04:54:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EF406B0092; Tue, 26 Mar 2024 04:54:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6BDB46B0089 for ; Tue, 26 Mar 2024 04:54:00 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E40D3A087D for ; Tue, 26 Mar 2024 08:53:59 +0000 (UTC) X-FDA: 81938577798.05.9789449 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf05.hostedemail.com (Postfix) with ESMTP id 05CA910000C for ; Tue, 26 Mar 2024 08:53:57 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="S//tHIZB"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf05.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711443238; h=from:from:sender: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=JmVyOPF8Rfshy9JqDqqOaE4ZcsXWwPS/pUZtM8O+dYM=; b=nXS6/dN91uBIw8FPaK6JDM5zpep1G7lwcIEthbhBqeMgGGkOdDGTtLFPAC6R8Pl+tAHoVO 2xBE7zratzL/mamspuPc9ujPP2oOXkby1rR90d8zwLv8+yEN8MIrNYHwApLWLTt1Md8dyK oBXYYndRvm3vKSJJD+d+2yUMkYmdgng= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="S//tHIZB"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf05.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711443238; a=rsa-sha256; cv=none; b=OfBVfdlHCRAu3Sfvvh4TwjE2/hAhlnsWWsNgC9wkfhbZjJieu2vHFX1K60ddOLAE3n72C9 GzQcsv7IUm+shrDrUgyOt1Meu/NKlWQQ6h6VYrMNtzKi4G3TjYedqGEtXRZwiHALs/U/6X vtTOKcoDGimXKBiWHi3ETiX/kWGGSok= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4148e20fb7eso4083195e9.2 for ; Tue, 26 Mar 2024 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711443236; x=1712048036; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=JmVyOPF8Rfshy9JqDqqOaE4ZcsXWwPS/pUZtM8O+dYM=; b=S//tHIZBzYhLz9WkNkPVysYvH83yFOnzUZAT5q/SARsyYvhZ2PZr2y2FyTqa0OuFXm wI04/D3kXmBTFVUEDSVHzuC90FZkIasa3wJtGu1J9LoIFoeBs8snRYkChykofhpgzC0G 97iRrlEF3mX7d3FfgW0M3l9ECrXHThDsZFnhsNJvSPG+Hp82ZzHSvsttoiN5sLrih6QA QHd2C03jAl9hjFs6zKc4aS9V+kZLTkVS/23UxT0rpam+M5LoCiUXq1iS3uGiQzMmJpEh s5KgVCghU72zLCRK5o34ZOqBAkBz08hAr9Kfsw/0VUEUsCxHpCp3zN4YxOCx8ANMOBL/ +7ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711443236; x=1712048036; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JmVyOPF8Rfshy9JqDqqOaE4ZcsXWwPS/pUZtM8O+dYM=; b=azkc0H0o9Wasac6wVC3bw1Zr0M8T8t307/1Dz1CulbnV8ojV2DB0vealsCK5UjqNz7 +OAkVnTLyMvE4cSXmD01Az8M92rLcGRBwvdvgfKU/bd0JQz8i7mL1TIm5e62iPKsnTA4 hoTI++2ktkDzhnnY6GQdNKSmRSt6lPBGRig9VSaUlCE9L/4lFYb6off+zYCYHzvut6hu 5ILVrfY5oa6QIaF/HVnu8Pue/yzy7MxtkQvXgeQPZYcjsELbA4qKNk7dnOiN7v4sMcWW aN+P+xVoaRynJ6eoshHIh0VkovttimNTZsGfAM0tM0m1kOk0MNTvDOyF5sg4SRcKWNfM FAAw== X-Forwarded-Encrypted: i=1; AJvYcCW2w/5DREjulsZXjg16Uw5JDna2sksGPY7eg2jv4ubkwCe4Kxy8Yr4F30ENp4eVifH36OoaYpA4YQsYh86Y6EJ9aXc= X-Gm-Message-State: AOJu0Yx4xIXNF8yOiP0JYZzVT+z7A6xAvNV5eHmNtd4B7ukgXwEeZBlI sk+MOmnVA1MvFshuCwiKCzyZJgiAwyB6b3ELVgy3OgPSy7X2TetW X-Google-Smtp-Source: AGHT+IH0vpA64BXtppF/HSC1865zGAW8kJTw87mVjFaXnWih1sSIO/+nxu0B6FvyejhimqbRzUoQXA== X-Received: by 2002:a05:600c:4445:b0:413:feed:b309 with SMTP id v5-20020a05600c444500b00413feedb309mr7893850wmn.6.1711443236136; Tue, 26 Mar 2024 01:53:56 -0700 (PDT) Received: from gmail.com (1F2EF63C.nat.pool.telekom.hu. [31.46.246.60]) by smtp.gmail.com with ESMTPSA id iv16-20020a05600c549000b0041409cabb39sm10829623wmb.18.2024.03.26.01.53.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Mar 2024 01:53:55 -0700 (PDT) Date: Tue, 26 Mar 2024 09:53:53 +0100 From: Ingo Molnar To: David Hildenbrand Cc: Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, Wupeng Ma , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrew Morton Subject: Re: [PATCH v1] x86/mm/pat: fix VM_PAT handling in COW mappings Message-ID: References: <20240312181118.318701-1-david@redhat.com> <5bc9de2f-c3ba-46e7-a234-3d3a46e53ba1@redhat.com> <922c5f99-1194-4118-9fe2-09b4f4a8cf04@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <922c5f99-1194-4118-9fe2-09b4f4a8cf04@redhat.com> X-Rspamd-Queue-Id: 05CA910000C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: iw7a3yjny6f6hjh36b7mxmso8hk5beyj X-HE-Tag: 1711443237-94583 X-HE-Meta: U2FsdGVkX1+hEOiy+8HcgqzOOHvVuj5wRdMmezU1Ss5M7lFywPx6G5BTIY+ux4cY3RYEX6QTSjnIQn7ReYRsVuwcDOzndMLEuiAvvnJRWc75YC0T2Q67ODrS6JvLcoYVzm13SB7zG1GpEthXgZYBvVnaMAq2EN2n49KtevP9NQ0PAEFYephGO7iEWk4GGviEEqMCzp7kux73RS5ijqrJM2oYqpn3pq4Wpv0unH/KYfE6EuW/u1hox60FELx4v0bb1F0pAGnFgkdwc4Tkrbhywl95KUofcL2kfD3woo5aEhCdlWEzlkwlufM0gIXpwpdUqsQmJCubOo6JvhftOqGxT+4trIhnHsgA3PMidV09tVPbvatJuQe4BHS0vLOcRsRc81g0NRP7GNUBVOZW6ad2ukNVFxd5B3Ogk5jCw3pSAQrZhp4glHaC9DKoB3UjelodOsLOkS3WuOY46+Ak/LCkz7kvopAAKfq4PlTtaLEz57NhRs48+qSJ7CK3Igqwg0g3G8v/+jfuWfdiAYbit8srEXTMzbFxJkARiD1c2cPrVcch8AB4z3OsLUwqb4JBTw9DYWtwQEwYw8YO1b0tJ7xRegeFBQUXW16HgqrJq18c33KSecmOSnWL8ptMg3ZO4XT5dwODuCsxRuVQdrxp8+NtL6WulJvYq9pijP52MlJ/KvHXNluGxMgvEQGjw2LE4M5M+UNDVxNRjvYBxAeBE3rf+S01jVf2RpHMczsCZlOm0/r/vv/DLSux9e4zonOQCEWehrL4w1ETYmYBIPGD0wGKUYzDGbPvqx7/lIHspkCyQw99RGQQINw8ezzL9MYmHWsJMSDS+NgPt7fM5SoOrzMXIsGVEC1l7Q1+IYe26LtzU4hVafpH7N/u/M/gfUkfTYO4jSBmotCjEzlWyVqcm/OFPqLHONgoVqlwBdoeiGnf1ODuG/8hweb/zqyHfN8wCQ5hA9qeoAfN5aY7P/gtF5e zHNdaTDH JsqASBuA+unU3qlFLeMtNJrZViaduMCYPNQ0B65Nvc3dPnqr2U6FRVMFmuqytbXe1OPoPogw90rVURJ4k/a0atK+M5KUmJ2ncrTHamZtzJoOpNfoT9ZKqAFVx0BXJooS08MbWRZf8JUvZdFIhVtr1+WhlU6Y7vvbPfSo1eoWknXR02XOsT/06GThvdi2e4YjA+nHUfdK7trFHfSMuf1+xC4h/QbVtympmHiLV+90K/eU/y4zv0++gdt0PStaOFBNJt6L1eeC20p8YomhrD02H10W/h6EFqG73tOMObVErjP0EEoBr8vqogKKOraAMpzNV5M/JTeixqOBCwUkZI4y4SuNQAGjPQUOKye0kDpcgMrilfEjis6TXhE1YG/CnyOAlDNmPX1kDbBcYWKfjjdNc/UYtI3oR/WJLAHL0o0THW2j8jsS+Bp346yrWjzNCPoLs+m/z9RDVMzEIGA/k7jsq4FO0mGLSMb7uDe/ijl3XcQlR39AxA49cqc7mV0utNF2u4bxq1vox3W6zgtNzSYHhc6A99fk1ANLbHF05Hn+aVkgLdysuZqm4CAFB647QD0oOpG2RRkeAx6qwtuM70ezEwbAq2w== 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: * David Hildenbrand wrote: > On 26.03.24 09:33, Ingo Molnar wrote: > > > > * David Hildenbrand wrote: > > > > > On 12.03.24 20:22, Matthew Wilcox wrote: > > > > On Tue, Mar 12, 2024 at 07:11:18PM +0100, David Hildenbrand wrote: > > > > > PAT handling won't do the right thing in COW mappings: the first PTE > > > > > (or, in fact, all PTEs) can be replaced during write faults to point at > > > > > anon folios. Reliably recovering the correct PFN and cachemode using > > > > > follow_phys() from PTEs will not work in COW mappings. > > > > > > > > I guess the first question is: Why do we want to support COW mappings > > > > of VM_PAT areas? What breaks if we just disallow it? > > > > > > Well, that was my first approach. Then I decided to be less radical (IOW > > > make my life easier by breaking less user space) and "fix it" with > > > minimal effort. > > > > > > Chances of breaking some weird user space is possible, although I believe > > > for most such mappings MAP_PRIVATE doesn't make too much sense sense. > > > > > > Nasty COW support for VM_PFNMAP mappings dates back forever. So does PAT > > > support. > > > > > > I can try finding digging through some possible user space users > > > tomorrow. > > > > I'd much prefer restricting VM_PAT areas than expanding support. Could we > > Note that we're not expanding support, we're fixing what used to be > possible before but mostly broke silently. Yeah - that's de-facto expanding support. :-) > But I agree that we should rather remove these corner cases instead of > fixing them. Yeah, especially if no code is hitting it intentionally. > > try the trivial restriction approach first, and only go with your original > > patch if that fails? > > Which version would you prefer, I had two alternatives (excluding comment > changes, white-space expected to be broken). > > > 1) Disallow when we would have set VM_PAT on is_cow_mapping() > > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c > index 0d72183b5dd0..6979912b1a5d 100644 > --- a/arch/x86/mm/pat/memtype.c > +++ b/arch/x86/mm/pat/memtype.c > @@ -994,6 +994,9 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot, > && size == (vma->vm_end - vma->vm_start))) { > int ret; > + if (is_cow_mapping(vma->vm_flags)) > + return -EINVAL; > + > ret = reserve_pfn_range(paddr, size, prot, 0); > if (ret == 0 && vma) > vm_flags_set(vma, VM_PAT); > > > 2) Fallback to !VM_PAT > > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c > index 0d72183b5dd0..8e97156c9be8 100644 > --- a/arch/x86/mm/pat/memtype.c > +++ b/arch/x86/mm/pat/memtype.c > @@ -990,8 +990,8 @@ int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot, > enum page_cache_mode pcm; > /* reserve the whole chunk starting from paddr */ > - if (!vma || (addr == vma->vm_start > - && size == (vma->vm_end - vma->vm_start))) { > + if (!vma || (!is_cow_mapping(vma->vm_flags) && addr == vma->vm_start && > + size == (vma->vm_end - vma->vm_start))) { > int ret; > ret = reserve_pfn_range(paddr, size, prot, 0); > > > > Personally, I'd go for 2). So what's the advantage of #2? This is clearly something the user didn't really intend or think about much. Isn't explicitly failing that mapping a better option than silently downgrading it to !VM_PAT? (If I'm reading it right ...) Thanks, Ingo