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.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 C8C20C46466 for ; Mon, 5 Oct 2020 17:28:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 684B320796 for ; Mon, 5 Oct 2020 17:28:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="otikT+4/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727981AbgJER25 (ORCPT ); Mon, 5 Oct 2020 13:28:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbgJER24 (ORCPT ); Mon, 5 Oct 2020 13:28:56 -0400 Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1FE6C0613CE for ; Mon, 5 Oct 2020 10:28:56 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id e7so10253647qtj.11 for ; Mon, 05 Oct 2020 10:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=y/b5RyjaEhoxKk2eHP6c3b/AJHv4kgCuakgmCNKfzEo=; b=otikT+4/1kDYRtQPc90pOcUt7CIquAj9yJbI9pGWzLjMgQp15bOu4C8rrRiUvNdnOM aKRgzlI7WytYj3mQeUdETfT2+hzXbe5sJLyntWHbz6yFOLgh0JBERO8IenWVpfWdziWs WCSUErfHWn/N+MdyHji8NEKT89KXjwOzmhehS1HW+4Q+imTf6kNnTLNjWgptms/pujrQ Cs4qofDbviM645imWY6iIc+WskHXh8ZHWNjxAeoh8PP9ubuzeqeWDGwds2B4Zvokpocd kBbjdsyPXICjJaDBzJyAwYhCl0nOW5eOiHuj+ykvdUWUFa45JKkh5b+vj9GDXv+um/B1 H5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=y/b5RyjaEhoxKk2eHP6c3b/AJHv4kgCuakgmCNKfzEo=; b=Pcl4LQJN9jzNPk4jChH7dDwuqNXasya61471SAdi1R/rvv7I+wbqWwq0z/9Lu7mFN3 Yi3sX88qQJXHdhdC7gwQ0LzJEkeFUfVbfM6oi5EYiDUo8P2Gg5IdmWM3ihbwo8bZ5smT eaOwqeDvMrO5Sgvp4mngUppcbDa7We6JcHCDIJBLmCWPx6GeW/pNatlcWCB8dCaDZBp5 f9ETxfmp1R7DWvOMgZ2Bc93G/S0rAHhgBtySfMUkxkl2mnnKD6loknYlTj5iw3O4ukO5 ztirPMeISTRcYgc7q5vOMwsPl7Q4BIeiiSMHfKLVi/GQ3s+sHU7I+4tQzet3I0k7NgiA 2f1A== X-Gm-Message-State: AOAM533E/wLx+3a6mlipSFtWdDr/NhwPECFTuXBaHfRZ7R4a/Ld8GZOM 7fYdar/f112nRtyYD5X1GpFLPQ== X-Google-Smtp-Source: ABdhPJzLYTVlvik+5HWAkt3kwllBS/QK3mi+3CPtiiTll37dAN3y7eDgBNRLLSEhFG2/0i8k53ngjA== X-Received: by 2002:aed:24c9:: with SMTP id u9mr939696qtc.292.1601918935717; Mon, 05 Oct 2020 10:28:55 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id t2sm279676qti.25.2020.10.05.10.28.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 10:28:55 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPUIA-0001gW-6L; Mon, 05 Oct 2020 14:28:54 -0300 Date: Mon, 5 Oct 2020 14:28:54 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Jan Kara , Dan Williams , Linux MM , Linux ARM , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Tomasz Figa , Inki Dae , Joonyoung Shim , Seung-Woo Kim , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , Oded Gabbay Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201005172854.GA5177@ziepe.ca> References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> 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-kernel@vger.kernel.org On Sun, Oct 04, 2020 at 06:09:29PM +0200, Daniel Vetter wrote: > On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote: > > > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > > > > > That leaves the only interesting places as vb2_dc_get_userptr() and > > > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > > > REQUIRED behavior in the function's comment about checking PTEs. It > > > > just DMA maps them. Badly broken. > > > > > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > > > > > Yeah, see also the follow_pfn trickery in > > > videobuf_dma_contig_user_get(), I think this is fully intentional and > > > userspace abi we can't break :-/ > > > > We don't need to break uABI, it just needs to work properly in the > > kernel: > > > > vma = find_vma_intersection() > > dma_buf = dma_buf_get_from_vma(vma) > > sg = dma_buf_p2p_dma_map(dma_buf) > > [.. do dma ..] > > dma_buf_unmap(sg) > > dma_buf_put(dma_buf) > > > > It is as we discussed before, dma buf needs to be discoverable from a > > VMA, at least for users doing this kind of stuff. > > I'm not a big fan of magic behaviour like this, there's more to > dma-buf buffer sharing than just "how do I get at the backing > storage". Thus far we've done everything rather explicitly. Plus with > exynos and habanalabs converted there's only v4l left over, and that > has a proper dma-buf import path already. Well, any VA approach like this has to access some backing refcount via the VMA. Not really any way to avoid something like that > > A VM flag doesn't help - we need to introduce some kind of lifetime, > > and that has to be derived from the VMA. It needs data not just a flag > > I don't want to make it work, I just want to make it fail. Rough idea > I have in mind is to add a follow_pfn_longterm, for all callers which > aren't either synchronized through mmap_sem or an mmu_notifier. follow_pfn() doesn't work outside the pagetable locks or mmu notifier protection. Can't be fixed. We only have a few users: arch/s390/pci/pci_mmio.c: ret = follow_pfn(vma, user_addr, pfn); drivers/media/v4l2-core/videobuf-dma-contig.c: ret = follow_pfn(vma, user_address, &this_pfn); drivers/vfio/vfio_iommu_type1.c: ret = follow_pfn(vma, vaddr, pfn); drivers/vfio/vfio_iommu_type1.c: ret = follow_pfn(vma, vaddr, pfn); mm/frame_vector.c: err = follow_pfn(vma, start, &nums[ret]); virt/kvm/kvm_main.c: r = follow_pfn(vma, addr, &pfn); virt/kvm/kvm_main.c: r = follow_pfn(vma, addr, &pfn); VFIO is broken like media, but I saw patches fixing the vfio cases using the VMA and a vfio specific refcount. media & frame_vector we are talking about here. kvm is some similar hack added for P2P DMA, see commit add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by notifiers.. s390 looks broken too, needs to hold the page table locks. So, the answer really is that s390 and media need fixing, and this API should go away (or become kvm specific) > If this really breaks anyone's use-case we can add a tainting kernel > option which re-enables this (we've done something similar for > phys_addr_t based buffer sharing in fbdev, entirely unfixable since > the other driver has to just blindly trust that what userspace > passes around is legit). This here isn't unfixable, but if v4l > people want to keep it without a big "security hole here" sticker, > they should do the work, not me :-) This seems fairly reasonable.. So after frame_vec is purged and we have the one caller in media, move all this stuff to media and taint the kernel if it goes down the follow_pfn path 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 X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 EB65AC47095 for ; Mon, 5 Oct 2020 17:30:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 7DE822068D for ; Mon, 5 Oct 2020 17:30:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zXcpdWGw"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="otikT+4/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DE822068D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/hLWoU2zdmZnWzjYKJpGHeNhrWH9tpnkUBuRjGkeGkg=; b=zXcpdWGw3UtzFpUpl2lcfJ6LE iHWqh20Y/fHMSTup0GmYar3/H+Jwv83aPGJNw2RStT5QY7eLkskdCC59qHFvYhKUJYzNb3qa6VhH2 Ioto4If7N6ZmHBRGPZTb3O/56h4YPPZHozUrhWpUVTQu3xLf/wEtfbBrM223ddMDWuw7JumdsEVE8 x5ni+zxzdcr3qSLblKQbg8bEr2ZMjOt8LzmSV58KL/+WY1bq4TiFcH7KXrjBH4yhJa31z7Ft8k7c9 MVY6CEaNnYO9Av/22lOTcjech+yehPDHDAFcFgRQo06sQ0GKBv0BdOD3O6xntUBYNa3qzN411ClHI 5PGduvz+w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPUII-0006lx-Ub; Mon, 05 Oct 2020 17:29:03 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPUIF-0006kq-Pe for linux-arm-kernel@lists.infradead.org; Mon, 05 Oct 2020 17:29:00 +0000 Received: by mail-qt1-x842.google.com with SMTP id j22so10284441qtj.8 for ; Mon, 05 Oct 2020 10:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=y/b5RyjaEhoxKk2eHP6c3b/AJHv4kgCuakgmCNKfzEo=; b=otikT+4/1kDYRtQPc90pOcUt7CIquAj9yJbI9pGWzLjMgQp15bOu4C8rrRiUvNdnOM aKRgzlI7WytYj3mQeUdETfT2+hzXbe5sJLyntWHbz6yFOLgh0JBERO8IenWVpfWdziWs WCSUErfHWn/N+MdyHji8NEKT89KXjwOzmhehS1HW+4Q+imTf6kNnTLNjWgptms/pujrQ Cs4qofDbviM645imWY6iIc+WskHXh8ZHWNjxAeoh8PP9ubuzeqeWDGwds2B4Zvokpocd kBbjdsyPXICjJaDBzJyAwYhCl0nOW5eOiHuj+ykvdUWUFa45JKkh5b+vj9GDXv+um/B1 H5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=y/b5RyjaEhoxKk2eHP6c3b/AJHv4kgCuakgmCNKfzEo=; b=sGxE0cjuXngaZ/h30mVH7W91iSentm/gxSTVJZ3mzNG+6yZQ2K4rtuQfFwOHaFU9NL 5PBXw9XM8UIgYF3Aic4m/d8wazGIz6rHeKJOVR0dbV2ISrB47gltFa3vH+/OI9+9hGIA wINSTSbAiPoeHUEtqGGNpiGZMPazldfhnHVPGG3dJFxtBOk2RuRpj4mZzF7vVbZ1RcTW +WvE1lEzoxrOUKIlm61apCScroKshoApRe5CHUFPI5bIPV6ZT41KvEc4qKCMJXTo9oQD J3qrwybZsu9OLxgH3TRjVCS4ekxuaXOgW6QqbQvXTEjm/LfKcfKwKvFm1JAkqXFFLXfL fIaA== X-Gm-Message-State: AOAM5326YZeJkQgM4HZ9dExKO2qC3fbdq8D4T+gcvlBfgLVHSSWDsumU Q0uDrSDaudgIBwCDjE33zoNRVg== X-Google-Smtp-Source: ABdhPJzLYTVlvik+5HWAkt3kwllBS/QK3mi+3CPtiiTll37dAN3y7eDgBNRLLSEhFG2/0i8k53ngjA== X-Received: by 2002:aed:24c9:: with SMTP id u9mr939696qtc.292.1601918935717; Mon, 05 Oct 2020 10:28:55 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id t2sm279676qti.25.2020.10.05.10.28.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 10:28:55 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPUIA-0001gW-6L; Mon, 05 Oct 2020 14:28:54 -0300 Date: Mon, 5 Oct 2020 14:28:54 -0300 From: Jason Gunthorpe To: Daniel Vetter Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201005172854.GA5177@ziepe.ca> References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201005_132859_884292_3BDC5025 X-CRM114-Status: GOOD ( 29.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Oded Gabbay , Inki Dae , linux-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Linux MM , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Oct 04, 2020 at 06:09:29PM +0200, Daniel Vetter wrote: > On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote: > > > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > > > > > That leaves the only interesting places as vb2_dc_get_userptr() and > > > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > > > REQUIRED behavior in the function's comment about checking PTEs. It > > > > just DMA maps them. Badly broken. > > > > > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > > > > > Yeah, see also the follow_pfn trickery in > > > videobuf_dma_contig_user_get(), I think this is fully intentional and > > > userspace abi we can't break :-/ > > > > We don't need to break uABI, it just needs to work properly in the > > kernel: > > > > vma = find_vma_intersection() > > dma_buf = dma_buf_get_from_vma(vma) > > sg = dma_buf_p2p_dma_map(dma_buf) > > [.. do dma ..] > > dma_buf_unmap(sg) > > dma_buf_put(dma_buf) > > > > It is as we discussed before, dma buf needs to be discoverable from a > > VMA, at least for users doing this kind of stuff. > > I'm not a big fan of magic behaviour like this, there's more to > dma-buf buffer sharing than just "how do I get at the backing > storage". Thus far we've done everything rather explicitly. Plus with > exynos and habanalabs converted there's only v4l left over, and that > has a proper dma-buf import path already. Well, any VA approach like this has to access some backing refcount via the VMA. Not really any way to avoid something like that > > A VM flag doesn't help - we need to introduce some kind of lifetime, > > and that has to be derived from the VMA. It needs data not just a flag > > I don't want to make it work, I just want to make it fail. Rough idea > I have in mind is to add a follow_pfn_longterm, for all callers which > aren't either synchronized through mmap_sem or an mmu_notifier. follow_pfn() doesn't work outside the pagetable locks or mmu notifier protection. Can't be fixed. We only have a few users: arch/s390/pci/pci_mmio.c: ret = follow_pfn(vma, user_addr, pfn); drivers/media/v4l2-core/videobuf-dma-contig.c: ret = follow_pfn(vma, user_address, &this_pfn); drivers/vfio/vfio_iommu_type1.c: ret = follow_pfn(vma, vaddr, pfn); drivers/vfio/vfio_iommu_type1.c: ret = follow_pfn(vma, vaddr, pfn); mm/frame_vector.c: err = follow_pfn(vma, start, &nums[ret]); virt/kvm/kvm_main.c: r = follow_pfn(vma, addr, &pfn); virt/kvm/kvm_main.c: r = follow_pfn(vma, addr, &pfn); VFIO is broken like media, but I saw patches fixing the vfio cases using the VMA and a vfio specific refcount. media & frame_vector we are talking about here. kvm is some similar hack added for P2P DMA, see commit add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by notifiers.. s390 looks broken too, needs to hold the page table locks. So, the answer really is that s390 and media need fixing, and this API should go away (or become kvm specific) > If this really breaks anyone's use-case we can add a tainting kernel > option which re-enables this (we've done something similar for > phys_addr_t based buffer sharing in fbdev, entirely unfixable since > the other driver has to just blindly trust that what userspace > passes around is legit). This here isn't unfixable, but if v4l > people want to keep it without a big "security hole here" sticker, > they should do the work, not me :-) This seems fairly reasonable.. So after frame_vec is purged and we have the one caller in media, move all this stuff to media and taint the kernel if it goes down the follow_pfn path Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 9C42DC47095 for ; Tue, 6 Oct 2020 07:32:07 +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 4B8D5212CC for ; Tue, 6 Oct 2020 07:32:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="otikT+4/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B8D5212CC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca 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 37D466E420; Tue, 6 Oct 2020 07:31:11 +0000 (UTC) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by gabe.freedesktop.org (Postfix) with ESMTPS id D97B589D81 for ; Mon, 5 Oct 2020 17:28:56 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id s47so1575036qth.4 for ; Mon, 05 Oct 2020 10:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=y/b5RyjaEhoxKk2eHP6c3b/AJHv4kgCuakgmCNKfzEo=; b=otikT+4/1kDYRtQPc90pOcUt7CIquAj9yJbI9pGWzLjMgQp15bOu4C8rrRiUvNdnOM aKRgzlI7WytYj3mQeUdETfT2+hzXbe5sJLyntWHbz6yFOLgh0JBERO8IenWVpfWdziWs WCSUErfHWn/N+MdyHji8NEKT89KXjwOzmhehS1HW+4Q+imTf6kNnTLNjWgptms/pujrQ Cs4qofDbviM645imWY6iIc+WskHXh8ZHWNjxAeoh8PP9ubuzeqeWDGwds2B4Zvokpocd kBbjdsyPXICjJaDBzJyAwYhCl0nOW5eOiHuj+ykvdUWUFa45JKkh5b+vj9GDXv+um/B1 H5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=y/b5RyjaEhoxKk2eHP6c3b/AJHv4kgCuakgmCNKfzEo=; b=lKiEz4cEJgBNj9b8KUwOmuvIJBGs/L3nMLvxvdEj3xsgPNgkatwGRTwDTKDrfG9fc1 XUeAl+n6r3+QN+bQUY6Y3vYVyKv/iH2tiW2LNu/+bvMI1u3sfVXdDsugoQdhGE97mtWK Sr/pNDTuV2nR+gNRoRhrIJxPtZPnPwIau0ER6hCddlw8vvgzi8u5JhOVMp8arAlwEqin BCcBuqWcYMvrWEwi+0SIAg215tCB3iNfPAaxOYOsDFgVaf1dvGAxOD9xaukZttXHAopr wwASRoar7IkHB/ptJwCLpHG0gg2XgETorXiBrvqJRILazFcguxpRVUkl4hApFHeJoXrA o1DA== X-Gm-Message-State: AOAM532VuD1S2/NcB09o6YeUlCw2tteoEbf80jFr2eVcdtF7pGiFZAQY 59fu0T2D8tVYwVqv2x+/3QXjjA== X-Google-Smtp-Source: ABdhPJzLYTVlvik+5HWAkt3kwllBS/QK3mi+3CPtiiTll37dAN3y7eDgBNRLLSEhFG2/0i8k53ngjA== X-Received: by 2002:aed:24c9:: with SMTP id u9mr939696qtc.292.1601918935717; Mon, 05 Oct 2020 10:28:55 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id t2sm279676qti.25.2020.10.05.10.28.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 10:28:55 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kPUIA-0001gW-6L; Mon, 05 Oct 2020 14:28:54 -0300 Date: Mon, 5 Oct 2020 14:28:54 -0300 From: Jason Gunthorpe To: Daniel Vetter Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201005172854.GA5177@ziepe.ca> References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> <20201002180603.GL9916@ziepe.ca> <20201002233118.GM9916@ziepe.ca> <20201004125059.GP9916@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 06 Oct 2020 07:31:05 +0000 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-samsung-soc , Jan Kara , Joonyoung Shim , Pawel Osciak , John Hubbard , Seung-Woo Kim , LKML , DRI Development , Tomasz Figa , Kyungmin Park , Linux MM , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Daniel Vetter , Andrew Morton , "open list:DMA BUFFER SHARING FRAMEWORK" , Dan Williams , Linux ARM , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Sun, Oct 04, 2020 at 06:09:29PM +0200, Daniel Vetter wrote: > On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote: > > > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > > > > > That leaves the only interesting places as vb2_dc_get_userptr() and > > > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > > > REQUIRED behavior in the function's comment about checking PTEs. It > > > > just DMA maps them. Badly broken. > > > > > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > > > > > Yeah, see also the follow_pfn trickery in > > > videobuf_dma_contig_user_get(), I think this is fully intentional and > > > userspace abi we can't break :-/ > > > > We don't need to break uABI, it just needs to work properly in the > > kernel: > > > > vma = find_vma_intersection() > > dma_buf = dma_buf_get_from_vma(vma) > > sg = dma_buf_p2p_dma_map(dma_buf) > > [.. do dma ..] > > dma_buf_unmap(sg) > > dma_buf_put(dma_buf) > > > > It is as we discussed before, dma buf needs to be discoverable from a > > VMA, at least for users doing this kind of stuff. > > I'm not a big fan of magic behaviour like this, there's more to > dma-buf buffer sharing than just "how do I get at the backing > storage". Thus far we've done everything rather explicitly. Plus with > exynos and habanalabs converted there's only v4l left over, and that > has a proper dma-buf import path already. Well, any VA approach like this has to access some backing refcount via the VMA. Not really any way to avoid something like that > > A VM flag doesn't help - we need to introduce some kind of lifetime, > > and that has to be derived from the VMA. It needs data not just a flag > > I don't want to make it work, I just want to make it fail. Rough idea > I have in mind is to add a follow_pfn_longterm, for all callers which > aren't either synchronized through mmap_sem or an mmu_notifier. follow_pfn() doesn't work outside the pagetable locks or mmu notifier protection. Can't be fixed. We only have a few users: arch/s390/pci/pci_mmio.c: ret = follow_pfn(vma, user_addr, pfn); drivers/media/v4l2-core/videobuf-dma-contig.c: ret = follow_pfn(vma, user_address, &this_pfn); drivers/vfio/vfio_iommu_type1.c: ret = follow_pfn(vma, vaddr, pfn); drivers/vfio/vfio_iommu_type1.c: ret = follow_pfn(vma, vaddr, pfn); mm/frame_vector.c: err = follow_pfn(vma, start, &nums[ret]); virt/kvm/kvm_main.c: r = follow_pfn(vma, addr, &pfn); virt/kvm/kvm_main.c: r = follow_pfn(vma, addr, &pfn); VFIO is broken like media, but I saw patches fixing the vfio cases using the VMA and a vfio specific refcount. media & frame_vector we are talking about here. kvm is some similar hack added for P2P DMA, see commit add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by notifiers.. s390 looks broken too, needs to hold the page table locks. So, the answer really is that s390 and media need fixing, and this API should go away (or become kvm specific) > If this really breaks anyone's use-case we can add a tainting kernel > option which re-enables this (we've done something similar for > phys_addr_t based buffer sharing in fbdev, entirely unfixable since > the other driver has to just blindly trust that what userspace > passes around is legit). This here isn't unfixable, but if v4l > people want to keep it without a big "security hole here" sticker, > they should do the work, not me :-) This seems fairly reasonable.. So after frame_vec is purged and we have the one caller in media, move all this stuff to media and taint the kernel if it goes down the follow_pfn path Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel