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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5070AC55178 for ; Wed, 21 Oct 2020 15:55:09 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 3B6152177B for ; Wed, 21 Oct 2020 15:55:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="bOKxdvhj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B6152177B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3DA9D6E049; Wed, 21 Oct 2020 15:55:07 +0000 (UTC) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3A60A6E049 for ; Wed, 21 Oct 2020 15:55:06 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id s21so2617140oij.0 for ; Wed, 21 Oct 2020 08:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C6DKYnDfudq4L3jq8cgaqwhb0+5UPYI4hKd8ZXy4r2g=; b=bOKxdvhjgEKOtLPpVYj6Ijwh2mKSXVoQ+GQkd6y9om8AOiAaZ5BVOKtRbAIB6TOef6 JViom2WHSbHDxfwbjTICNMKIpnUHoAO8RMBp0R1dGY04OeAqtrO7mA9xr7W57bhgZWkI m7xoz6/cv19qNKpiDTjcgK90UI0cWYA6F2WWM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C6DKYnDfudq4L3jq8cgaqwhb0+5UPYI4hKd8ZXy4r2g=; b=tPhXcOPQyPd3VUl8V5tor/FWOcbgdBAKFXGa/jyERlNaMec0Ze45TuamVkOUxB1bk7 vujj0z4y6fJgLat0TKEx6hKMlXZvI9vfSCihOEFv/Y067Xo9hJYbgH4o1bqxpn/wuw6q yi64tWOdzrGB0K1A3OiC4uuDzm8rK8C0yxyoW8RYiD+OIy2tUxi2fvOUC4jM3pnx2lZD EBrQhYtmdNNUv8BpCVqgA+s5M2RC0QoXarCmYeCdEFVXTl0hXYsu2fYYUQYcbyLdcsBj WoaF8HF9bvPuTgdcKtERhLaO6YAAo2eJUDUijST0ITNALB8UnnBBQoAraP4G9QBASRMr bArw== X-Gm-Message-State: AOAM531XZSKBMvhxHxWwWMLPRLAva/Jj+hP1bIw7L/KNY2iZ1dGy6irg NSfnCn7uzyhuRsmKOZyq+0qbfcqyEW6dwbzhULJeBQ== X-Google-Smtp-Source: ABdhPJzPCgyzodnSmRD9rGONXEuc3qJsREMQopHY6rQLHriRRIWOuQr4ZeQqsR42HntwRWBXJ/bxEHV/oXvYTFC/kGQ= X-Received: by 2002:aca:52c4:: with SMTP id g187mr2521031oib.101.1603295705466; Wed, 21 Oct 2020 08:55:05 -0700 (PDT) MIME-Version: 1.0 References: <20201021085655.1192025-1-daniel.vetter@ffwll.ch> <20201021085655.1192025-13-daniel.vetter@ffwll.ch> <20201021125030.GK36674@ziepe.ca> <20201021151352.GL36674@ziepe.ca> In-Reply-To: <20201021151352.GL36674@ziepe.ca> From: Daniel Vetter Date: Wed, 21 Oct 2020 17:54:54 +0200 Message-ID: Subject: Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap To: Jason Gunthorpe 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: linux-s390 , linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Daniel Vetter , John Hubbard , LKML , DRI Development , Linux MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Linux PCI , Bjorn Helgaas , Daniel Vetter , Dan Williams , Andrew Morton , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Oct 21, 2020 at 5:13 PM Jason Gunthorpe wrote: > > On Wed, Oct 21, 2020 at 04:42:11PM +0200, Daniel Vetter wrote: > > > Uh yes. In drivers/gpu this isn't a problem because we only install > > ptes from the vm_ops->fault handler. So no races. And I don't think > > you can fix this otherwise through holding locks: mmap_sem we can't > > hold because before vma_link we don't even know which mm_struct is > > involved, so can't solve the race. Plus this would be worse that > > mm_take_all_locks used by mmu notifier. And the address_space > > i_mmap_lock is also no good since it's not held during the ->mmap > > callback, when we write the ptes. And the resource locks is even less > > useful, since we're not going to hold that at vma_link() time for > > sure. > > > > Hence delaying the pte writes after the vma_link, which means ->fault > > time, looks like the only way to close this gap. > > > Trouble is I have no idea how to do this cleanly ... > > How about add a vm_ops callback 'install_pages'/'prefault_pages' ? > > Call it after vm_link() - basically just move the remap_pfn, under > some other lock, into there. Yeah, I think that would be useful. This might also be useful for something entirely different: For legacy fbdev emulation on top of drm kernel modesetting drivers we need to track dirty pages of VM_IO mmaps. Right now that's a gross hack, and essentially we just pay the price for entirely separate storage and an additional memcpy when this is needed to emulate fbdev mmap on top of drm. But if we have install_ptes callback or similar we could just wrap the native vm_ops and add a mkwrite callback on top for that dirty tracking. For that the hook would need to be after vm_set_page_prot so that we write-protect the ptes by default, since that's where we compute vma_wants_writenotify(). That's also after vma_link, so one hook for two use-cases. The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to split that. So ideally ->mmap would never set up any ptes. I guess one option would be if remap_pfn_range would steal the vma->vm_ops pointer for itself, then it could set up the correct ->install_ptes hook. But there's tons of callers for that, so not sure that's a bright idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel