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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DA03FC4332F for ; Wed, 23 Nov 2022 15:09:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7630610E20E; Wed, 23 Nov 2022 15:09:05 +0000 (UTC) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by gabe.freedesktop.org (Postfix) with ESMTPS id AC04510E20E for ; Wed, 23 Nov 2022 15:09:01 +0000 (UTC) Received: by mail-qv1-xf2e.google.com with SMTP id e15so12302319qvo.4 for ; Wed, 23 Nov 2022 07:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yl5EWh2LPGXKg4ZX+0uMGR+SP4+5g4wansDQ2racGIw=; b=UZ90yvpYHpAD2wJFcceeqxHp5n/1J/IMdboyjPLp9xSvgX7lhd9bIH3J7mYPJrCrgH tIUHI5mfCyqHqL/FPnEKA2O3D4UL7ejl7s4SZWtCiLkQMQ0C9Vp59OLuPUd9l9rtsP/H 5KMfSJskvLx0jvavXd2BcujWMJkK2mF1Y/bBE2Auf5ZuOkr+OEzP+TYvNGzpLDMh1E/b /tk+XGOAsg1BHi8GoUKfhHIo0iTmbkce9zo9I7xuGjeffWnbCQMDz+hFZmGT49zCWuvX 8So0XmT6Euoi53OroYVLDNKa4yZxbJs5xlXojPLsNHKLC7aadu52zmFmfAidIVRVxdfh /nVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yl5EWh2LPGXKg4ZX+0uMGR+SP4+5g4wansDQ2racGIw=; b=SY8q5IJv1VVefGBeCNOtJzI6ozCJqRiP1ogoMZOc/3nhaITCuatR9YvssKGUTke62C WknU4v+8aX42pOVw3sdlgSGgi5Zet9vJ08xjZf9Ybrg1IuYZtYLnhgZGV2yHUOau9RnV VayqSLME+nGEZ7+Zfnd1kqj+KHxufaSm/zlOODBbXP6CDOA3Ykh6KiDlOLbqWWsUaJDx vHE0HMC/40AvgrA65wPCsMMHpQjjUSz9xRJZt85BGBwN8ef+h2iRI8/bXrAHvixgfdrb WsotVSg+EgP0p9/naJCrvcAwi3Up7NF3hzVbL00RjIgKUpwF29WqQJCaqDmmUuaUbcR0 cLfQ== X-Gm-Message-State: ANoB5pkWLm6fH9a6VguikBNEmTBOrs1BuDl62Z+F74Q1tmEDhaLyew79 pQi2Min3i/lVmcCkcTrfnOmOmw== X-Google-Smtp-Source: AA0mqf7e8Ogh/ZJOSZP+2cSLpyEbwDySY9r7p8UtFKlyBZNWj/XPJyjVbU2TWKfbCouXJyhbUXJI9w== X-Received: by 2002:a0c:b405:0:b0:4bb:666c:384d with SMTP id u5-20020a0cb405000000b004bb666c384dmr27071486qve.91.1669216140695; Wed, 23 Nov 2022 07:09:00 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-122-23.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.122.23]) by smtp.gmail.com with ESMTPSA id ca9-20020a05622a1f0900b00398a7c860c2sm10023130qtb.4.2022.11.23.07.08.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 07:08:59 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1oxrMw-00AMdR-Vh; Wed, 23 Nov 2022 11:08:58 -0400 Date: Wed, 23 Nov 2022 11:08:58 -0400 From: Jason Gunthorpe To: Daniel Vetter Subject: Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: Require VM_PFNMAP vma for mmap Message-ID: References: <3d8607b4-973d-945d-c184-260157ade7c3@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Christian =?utf-8?B?S8O2bmln?= , Intel Graphics Development , DRI Development , Sumit Semwal , linaro-mm-sig@lists.linaro.org, John Stultz , Matthew Wilcox , Thomas Zimmermann , Daniel Vetter , Suren Baghdasaryan , Christian =?utf-8?B?S8O2bmln?= , linux-media@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Nov 23, 2022 at 03:34:54PM +0100, Daniel Vetter wrote: > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 1376a47fedeedb..4161241fc3228c 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -2598,6 +2598,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, > > return r; > > } > > > > + /* > > + * Special PTEs are never convertible into a struct page, even if the > > + * driver that owns them might have put a PFN with a struct page into > > + * the PFNMAP. If the arch doesn't support special then we cannot > > + * safely process these pages. > > + */ > > +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL > > + if (pte_special(*ptep)) > > + return -EINVAL; > > On second thought this wont work, because it completely defeats the > point of why this code here exists. remap_pfn_range() (which is what > the various dma_mmap functions and the ioremap functions are built on > top of too) sets VM_PFNMAP too, so this check would even catch the > static mappings. The problem with the way this code is designed is how it allows returning the pfn without taking any reference based on things like !pfn_valid or page_reserved. This allows it to then conditionally put back the reference based on the same reasoning. It is impossible to thread pte special into that since it is a PTE flag, not a property of the PFN. I don't entirely understand why it needs the page reference at all, even if it is available - so I can't guess why it is OK to ignore the page reference in other cases, or why it is OK to be racy.. Eg hmm_range_fault() does not obtain page references and implements a very similar algorithm to kvm. > Plus these static mappings aren't all that static either, e.g. pci > access also can revoke bar mappings nowadays. And there are already mmu notifiers to handle that, AFAIK. Jason 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C05DC433FE for ; Wed, 23 Nov 2022 15:10:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238282AbiKWPJ5 (ORCPT ); Wed, 23 Nov 2022 10:09:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238404AbiKWPJg (ORCPT ); Wed, 23 Nov 2022 10:09:36 -0500 Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 322EE6154 for ; Wed, 23 Nov 2022 07:09:01 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id df6so10085216qvb.0 for ; Wed, 23 Nov 2022 07:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yl5EWh2LPGXKg4ZX+0uMGR+SP4+5g4wansDQ2racGIw=; b=UZ90yvpYHpAD2wJFcceeqxHp5n/1J/IMdboyjPLp9xSvgX7lhd9bIH3J7mYPJrCrgH tIUHI5mfCyqHqL/FPnEKA2O3D4UL7ejl7s4SZWtCiLkQMQ0C9Vp59OLuPUd9l9rtsP/H 5KMfSJskvLx0jvavXd2BcujWMJkK2mF1Y/bBE2Auf5ZuOkr+OEzP+TYvNGzpLDMh1E/b /tk+XGOAsg1BHi8GoUKfhHIo0iTmbkce9zo9I7xuGjeffWnbCQMDz+hFZmGT49zCWuvX 8So0XmT6Euoi53OroYVLDNKa4yZxbJs5xlXojPLsNHKLC7aadu52zmFmfAidIVRVxdfh /nVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yl5EWh2LPGXKg4ZX+0uMGR+SP4+5g4wansDQ2racGIw=; b=YmlFmCP6wb3XYkGPU3xTyW0/5CEeRe1zuVO0q4jpTPJlHYYc+t/mpQlBMskPKyZr4Y r5Q8XjaZrAe7swRox793LpxIGqbnZDSO9yu7d9HLCVCiRE+HsOfIFyPluJw9cZ2Ds0UR pJ5+iVwLJg6YjWHVr/VDRT/0Hb+Dyqrdz1SCEJmekCuRkDiAItU0rf3Y4Ae5ujp1ULZ8 UO2TEOkZNN/l6xaL0Yvu8qcbrZEW+gis/NA7Tr+9q6VICABwFGqZ0agHEWErG5/cnSGO jE55W6SBS1FleSMzZbcERuM0eFMd49SP5dqgkAKTBberTet0qP7qb91auTvxE4cN1OkS n2Wg== X-Gm-Message-State: ANoB5pnEP0zm/Nh6It1/tyskAE3da4NeWGGCvqQZ9KCrA+KUI8uvlzgb 6ziJ/hR6f2JMllIOU/NEsI5CBoycMwAu3A== X-Google-Smtp-Source: AA0mqf7e8Ogh/ZJOSZP+2cSLpyEbwDySY9r7p8UtFKlyBZNWj/XPJyjVbU2TWKfbCouXJyhbUXJI9w== X-Received: by 2002:a0c:b405:0:b0:4bb:666c:384d with SMTP id u5-20020a0cb405000000b004bb666c384dmr27071486qve.91.1669216140695; Wed, 23 Nov 2022 07:09:00 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-122-23.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.122.23]) by smtp.gmail.com with ESMTPSA id ca9-20020a05622a1f0900b00398a7c860c2sm10023130qtb.4.2022.11.23.07.08.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 07:08:59 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1oxrMw-00AMdR-Vh; Wed, 23 Nov 2022 11:08:58 -0400 Date: Wed, 23 Nov 2022 11:08:58 -0400 From: Jason Gunthorpe To: Daniel Vetter Cc: Christian =?utf-8?B?S8O2bmln?= , Christian =?utf-8?B?S8O2bmln?= , DRI Development , Intel Graphics Development , Thomas Zimmermann , Suren Baghdasaryan , Matthew Wilcox , John Stultz , Daniel Vetter , Sumit Semwal , linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: Require VM_PFNMAP vma for mmap Message-ID: References: <3d8607b4-973d-945d-c184-260157ade7c3@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Wed, Nov 23, 2022 at 03:34:54PM +0100, Daniel Vetter wrote: > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 1376a47fedeedb..4161241fc3228c 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -2598,6 +2598,19 @@ static int hva_to_pfn_remapped(struct vm_area_struct *vma, > > return r; > > } > > > > + /* > > + * Special PTEs are never convertible into a struct page, even if the > > + * driver that owns them might have put a PFN with a struct page into > > + * the PFNMAP. If the arch doesn't support special then we cannot > > + * safely process these pages. > > + */ > > +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL > > + if (pte_special(*ptep)) > > + return -EINVAL; > > On second thought this wont work, because it completely defeats the > point of why this code here exists. remap_pfn_range() (which is what > the various dma_mmap functions and the ioremap functions are built on > top of too) sets VM_PFNMAP too, so this check would even catch the > static mappings. The problem with the way this code is designed is how it allows returning the pfn without taking any reference based on things like !pfn_valid or page_reserved. This allows it to then conditionally put back the reference based on the same reasoning. It is impossible to thread pte special into that since it is a PTE flag, not a property of the PFN. I don't entirely understand why it needs the page reference at all, even if it is available - so I can't guess why it is OK to ignore the page reference in other cases, or why it is OK to be racy.. Eg hmm_range_fault() does not obtain page references and implements a very similar algorithm to kvm. > Plus these static mappings aren't all that static either, e.g. pci > access also can revoke bar mappings nowadays. And there are already mmu notifiers to handle that, AFAIK. Jason