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 89136C4363C for ; Sun, 4 Oct 2020 16:11:49 +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 210B52067C for ; Sun, 4 Oct 2020 16:11:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CDtLE4/X"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="RjQVWoci" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 210B52067C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=j0mN42X0KD0iMBjT3wXRzRVq73r/bNaypkzL5D631HI=; b=CDtLE4/XE8ei12qQck3zk4j0g TRHGudB3M7X9zXJDl7401aZd+HewOk0B+cNwVNVuoUOVLWkmU11wxamhNoJaEG7rQFPHH60qbbDXI ahnkKdXAo9cu9HWzYYOsp/IEwwkP7hpsNv30o/6cpltSuE58CFS5UxEblSpn4kaZxDm9iz0uj+9/r Ivqa30nkSJED9ld4nKRXEp0Oo1A3ney96xxDwf3A6OWEMBQkil2fmYRZ7JjgN0bx8ErwpO68c4cgd gLZQ9veiq9hFBWowcZcnaGruMXFTTkwwRsS9BBMXFGgwp/cBtNsj9w+C0QqmcIGfBblmNKtW4ke5n nwWr6UDbA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kP6a2-0001jL-ID; Sun, 04 Oct 2020 16:09:46 +0000 Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kP6a0-0001iM-6N for linux-arm-kernel@lists.infradead.org; Sun, 04 Oct 2020 16:09:45 +0000 Received: by mail-oi1-x243.google.com with SMTP id x14so6328526oic.9 for ; Sun, 04 Oct 2020 09:09:42 -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=GOTUKnVU3itRBVmgEpNxeJsDdURcvTFw9TlNBbu70B8=; b=RjQVWociZc18kuI7qAnBTKARmkT/mLLw8LxYZfs47cFvcduVoCEYDEszZHSm3DILp3 12erHUrCIHd+qofrGC6EBSBsPlSnIsKESM1BNtr+gPSKiX1KznnyLcFV2UQYtqQgcIm/ r78PvYntGqD3isT9Sfhut4qKDFJ3FJ5bs6M4c= 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=GOTUKnVU3itRBVmgEpNxeJsDdURcvTFw9TlNBbu70B8=; b=m9VVC00D0kcWtJVOictdb+9maLpGlr7wMDSBvTVN3/kicmPaMhkIgpqZI2i/V7jnJK A665oNUco1Gia5fcksU66KJt18EB6nCxWpU70D89imIMV6BiQ2QktOjXBmOAJsFgIeYP NtLqgsyqe4DayZHKBSoKgrX7x7egddv47iQQTy/8Lb1xmT5A3/hV2CItJCMAa/mI7+y1 3pstrJg9PiZN9WtOud+Q76GJ4qsu9SZdmJe1YoaMBpE3lQ597z09TWL24VKI1myrJlH/ YzWm+An82gzpTesyIdpFP5rztVDZvI63UVozlXe0ApNYfDFWMcIQOdlDag3qtSviPm2P efwQ== X-Gm-Message-State: AOAM531OFFr/e4Gj8/g9bOJcHsveXsfMKpgr452aL0EtOYWT1VPRHbg4 jzG6/ucrCsoo2f6WzXoR3ia22b4qi+60YJBFy9TnAA== X-Google-Smtp-Source: ABdhPJzdfqkWkuYL7n4fDIIpl1SUMymwaZrdS/bll2UpQKzwL/q1RfjS5bz/mQjsvb0ZsYrSTWSr4/UovkHzDZkrMWw= X-Received: by 2002:a05:6808:206:: with SMTP id l6mr6372776oie.128.1601827780607; Sun, 04 Oct 2020 09:09:40 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20201004125059.GP9916@ziepe.ca> From: Daniel Vetter Date: Sun, 4 Oct 2020 18:09:29 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Jason Gunthorpe X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201004_120944_405612_C2017E5F X-CRM114-Status: GOOD ( 30.87 ) 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?SsOpcsO0bWUgR2xpc3Nl?= , 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 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. > > Yup this should be done with dma_buf instead, and v4l has that. But > > old uapi and all that. This is why I said we might need a new > > VM_DYNAMIC_PFNMAP or so, to make follow_pfn not resolve this in the > > case where the driver manages the underlying iomem range (or whatever > > it is) dynamically and moves buffer objects around, like drm drivers > > do. But I looked, and we've run out of vma->vm_flags :-( > > 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. 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 :-) > > The other problem is that I also have no real working clue about all > > the VM_* flags and what they all mean, and whether drm drivers set the > > right ones in all cases (they probably don't, but oh well). > > Documentation for this stuff in headers is a bit thin at times. > > Yah, I don't really know either :\ > > The comment above vm_normal_page() is a bit helpful. Don't know what > VM_IO/VM_PFNMAP mean in their 3 combinations > > There are very few places that set VM_PFNMAP without VM_IO.. Best I could find is: - mk68 seems to outright reject pagefaults on VM_IO vma - some places set VM_IO together with VM_MIXEDMAP instead of VM_PFNMAP. There's some comments that this makes cow possible, but I guess that's for the old pfn remap vma (remap_file_pages, which is removed now). But really no clue. VM_IO | VM_MIXEDMAP kinda makes me wonder whether follow_pfn gets the page refcounting all right or horribly wrong in some cases ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel