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 325A1CD1288 for ; Mon, 1 Apr 2024 09:45:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83CB96B0085; Mon, 1 Apr 2024 05:45:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7ECB16B0088; Mon, 1 Apr 2024 05:45:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B5766B0089; Mon, 1 Apr 2024 05:45:14 -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 510266B0085 for ; Mon, 1 Apr 2024 05:45:14 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 027A1402E9 for ; Mon, 1 Apr 2024 09:45:13 +0000 (UTC) X-FDA: 81960479748.25.4868752 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf02.hostedemail.com (Postfix) with ESMTP id F02478000B for ; Mon, 1 Apr 2024 09:45:11 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hLaNb8fx; spf=pass (imf02.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711964712; 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=U82/zKNoj7Un9bj3VUFlAllXXEKzojenj3FXQK42VVY=; b=KXMIfgZHzR58VBn6mP7IFr+qepc2L1xjcsiDSIeaMu+LgpdjCQts9C13PfwvMeLcKZ9sWD XIrJ00AA4c0tztY/mIEHtLCQUVbv38OYU7tZhYy2IUXg7Y+H1V9YeAf4r7snf3AlTlbWfM 9aeaiGNony1yDDzHFlLl4BFeyncnCiQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711964712; a=rsa-sha256; cv=none; b=q1tJp1QZWp1YWnzkxvmjFd5uPEOyM6dp9I5bAMt1SdcQCfBBcVpxMAS0x1f4rC/IGAkadG 4ERlEhGF4nK6U6VAmAqJyxRisRFSD5K/K3vMiXNINK827ijAHAoEMc/NMjj3L6tAJfjPWE eA872/Rb3UPq/dIO34N59FH+1I9PnTE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hLaNb8fx; spf=pass (imf02.hostedemail.com: domain of mingo.kernel.org@gmail.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4156201223bso4381565e9.0 for ; Mon, 01 Apr 2024 02:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711964710; x=1712569510; 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=U82/zKNoj7Un9bj3VUFlAllXXEKzojenj3FXQK42VVY=; b=hLaNb8fxvVwH1NMVfjuRzJzf1cFeZi/IbiAUbZ37r0GIxvavukUGFR7au1R1GxW9jF 3RqsraALjmmTTJGuFLTJRvUmmNEz5N30pokYSEQFcdGRLk0NHuyaQJR5hmkuHTRw8adx uYi8v8VBc26cCe0kzUrZKT0Zlzdj6kWMPs90ms3uXq7F/ntv/NGLx8rmTN58VhFPKer6 sAgGMXO1ATR5UA+6wImSvm/LCXsYkFXeq5EHvq/MGYw14FGqUuQizkMFosmkFZy5EhJn H4Qwanj0e5nlS0/1xgmxRP9fJuYpyOEY3CuDHGNdJdi9BTbE9gq4iDV3kxIpNNyXJmLA kUlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711964710; x=1712569510; 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=U82/zKNoj7Un9bj3VUFlAllXXEKzojenj3FXQK42VVY=; b=KrGavDpd14LgqUc26Jj4Ym23azYQlkb1fhf6/S/2c3VpBK6zsrfALek1Gxm37aXVkn ki77KAFE0swQCQv/mcr7SwY2Lx5jOCjfUHdtMQSKoM4hXJ+hVPy1DF2ELFMH29HHHJ/m bXW0T5pTMIAzdM9cMZOrTOftZnhj+Tc30dIHGDCw2iyqlMDBQmrSQlE5vGzLxLNLR30M hJORccCddFuU8PtfJTO1ML8J21l6Ncj47taPbp6UYs03Dm06m7KFAznOVKAiOod1IgnD 79a8NT4nZXgmRvEraGY+FHOOcBjGs5fUweNw6nspmFTpPmZ7ICSAmUSdLKqRBimU8LEk ThJg== X-Forwarded-Encrypted: i=1; AJvYcCUdqUPNZBXm05myHJ4g6eBj2HOGYBpHctpGaoluXTEHwPG9Oxeb5IHM2KxAXftbLYWteh7I3jMzqQkJqCyF09Y+2h4= X-Gm-Message-State: AOJu0Yws2+psEYaa5iADLJ2Jo2qpagb3rqZc2BhLK4QThtdZG76V2/JM HXd5E87og1VvHysdM0uvo57w4bjGwmQ9n28pZr2+FjnAnRWVN66b X-Google-Smtp-Source: AGHT+IEhC542QHRw2FssFYxmPWyaAlrYdv090z5cJ0v/jmfm7wGlSCr/ORSk0b1JZ0wN6uNB5O3RSg== X-Received: by 2002:a05:600c:5123:b0:414:37f:2798 with SMTP id o35-20020a05600c512300b00414037f2798mr7878513wms.6.1711964710077; Mon, 01 Apr 2024 02:45:10 -0700 (PDT) Received: from gmail.com (84-236-113-97.pool.digikabel.hu. [84.236.113.97]) by smtp.gmail.com with ESMTPSA id g1-20020adfa481000000b00341e7e52802sm11250804wrb.92.2024.04.01.02.45.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Apr 2024 02:45:09 -0700 (PDT) Date: Mon, 1 Apr 2024 11:45:07 +0200 From: Ingo Molnar To: David Hildenbrand , Andrew Morton 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> <2420ca24-b475-45ba-bab9-66c11b8cf484@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2420ca24-b475-45ba-bab9-66c11b8cf484@redhat.com> X-Stat-Signature: 4a3z5u8yhdexbgaq4h1gzuj9k1dqythn X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: F02478000B X-Rspam-User: X-HE-Tag: 1711964711-363076 X-HE-Meta: U2FsdGVkX18F7fWL03ehMLMzQHjtaBOXDikclXi2GQQnzT0j9prl5vAPbZQeu4wfxtqe1geRUsBad3S43SVRGa0XEtJe2CqWgQOrlmhiLZa/FtmYnXg3djhY8j+XHqVCvohoCW9jPP50/YyN40bpnmdmsymlPa/4wJ2N4yCs94dmPgD/FoBkBfLhEXssRBq59ZV4C+bnEVRiedwpHsKdzVO6YlDsTzwnMlCMApnJ8uBq1SVRnUGXm2UBAmxnh2GSy7gHcOm7U/XqqTO1cQTE3yyzXyiBwHRmtQADkVK9yfl+rNUIb5g6HKFvh73Q9N7MyOOBolnuX7WoGjwrWEAqZwgXnMW6zqaazXotrCJLiOQT3Ur5k89LUQJMK56UQSu4kWHmzgX9GQVCVK20nfdePKwlKn7RoI1Y7yp3i1d+9ttuJ79oNTaA9pgGzYgjDB3iedO4sFz0ouWY5vCy/wxlyLuQxOXGn6FpHPI9smRii7pz/Dbyn7h7T3KFQH7vapMmYRp6mem3gyIdIKlRskZDe4J9DNB3uxzPY1a6qXhYGXSOesf/JS4pFYheJ0qJNmNDhmiTzLP3W/943Rjk9t0EJsbYABrobdsoWtPWtBfEvdXRK22FENTwn2L7/4KEU1QsHYeiFZQkPzHnc+82DHopnPAKiKLNpktKvpjz966JeG41OScglKQsAlIzplAm7BcHPE33XLLc3OLCr8Pjdp/78kus6OSoqBno4er8XMli5B/n7P8+t2qPNeVvtPUYZwtKT6yIRxI5zOImxplwqITaixOpnxdbVFpe9nbeZ5rRBT3R8KxHh+zFygs6L7aytzEvM9FmQmEUyyFjACZ+8M7Y335/7oyHsCvLJezS3PG7FOnB1N0k2A9t0B54FMjBTHqmRw2mh7OIQPq36lxXqpqRjewwFOyx1w73Z0y0Ffr33W9H8avxOLVS7AW54EdOYs+XRhMp0vGrQ7JCHf13Nve QiSboxEN VVlY25xauMIj+4ghGqYtLVpjmvlqn8a/IpW+GHKpV7GjdAvmtyuGCYi0MvJU+pcO/VkJCZkXbviZJloP83kDf+4Ff9ZZdUvOPdVmstkkcQdNwY8pztUZT8jiE+w1FO5oosgnOqvzS2E9yEG5ThlSXoYpUAcvH9WIZcsX9QS3NsBFhr+CwYNMNHe+htEOo4il+2xySH/0ZMbU5g8SKaPnOruh93Dnmy5hYrOTsqBmfmVcPKFljyAUheHtRlsxZfldqwISG1BwmScF42z0XKIPfo3SVkno3juL0sZxb+FHWx1lsX21azPl+PY2LuD6+QAt2zI67OCzb/R/k5ecN+B+kJkLJzs2EBUNaQevAnesBfHtWNW11i5obH//qBfsp9VZJFVZMQ59nuwP1xe63ZvUW5oWip0lXpaKDEOZ3zRmOKatcB25P2KW7AspRlSjIg4owkQDzIUqtbd0qCsXeQ+T/e2XFyM7AQIqMoM67ADHfDDqAvMIvdQrxlQO19A1nqctE2LnA7r4/GYLvnW6nSL5/X5qBz41yuKc7d0lczw/vOwTFBLWGcZJ5UEUwUJCoJunqwGXM5eNZ1UCwy5XcLnKOMqzvaHR65v+iJiu8Upg5K8oOPmr42lUskCvqLUvH2LtTE71gaO3klOrmd6x6vsGh/MJyTQ== 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: > > > > 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 ...) > > I think a simple mmap(MAP_PRIVATE) of /dev/mem will unconditionally fail > with 1), while it keeps on working for 2). > > Note that I think we currently set VM_PAT on each and every system if > remap_pfn_range() will cover the whole VMA, even if pat is not actually > enabled. > > It's all a bit of a mess TBH, but I got my hands dirty enough on that. > > So 1) can be rather destructive ... 2) at least somehow keeps it working. > > For that reason I went with the current patch, because it's hard to tell > which use case you will end up breaking ... :/ Yeah, so I think you make valid observations, i.e. your first patch is probably the best one. But since it changes mm/memory.c, I'd like to pass that over to Andrew and the MM folks. The x86 bits: Acked-by: Ingo Molnar Thanks, Ingo