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 A4A9FC4727D for ; Mon, 5 Oct 2020 22:43:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B50DA2078A for ; Mon, 5 Oct 2020 22:43:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="KVtqpLQo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B50DA2078A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CB4326B005C; Mon, 5 Oct 2020 18:43:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C64B76B005D; Mon, 5 Oct 2020 18:43:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2DFD6B0062; Mon, 5 Oct 2020 18:43:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 8373D6B005C for ; Mon, 5 Oct 2020 18:43:44 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0852F180AD804 for ; Mon, 5 Oct 2020 22:43:44 +0000 (UTC) X-FDA: 77339350368.14.body16_080983e271c1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id D43F818229835 for ; Mon, 5 Oct 2020 22:43:43 +0000 (UTC) X-HE-Tag: body16_080983e271c1 X-Filterd-Recvd-Size: 7024 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 22:43:43 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id z26so10469928oih.12 for ; Mon, 05 Oct 2020 15:43: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=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=KVtqpLQoesSPzYMWv+7UD1tFkDy5yyjPi/++9DOuPkCf87SQu/2kTZ3idGVZKfPwCd pibU61WH7YP7EEL4itAZdaANj+S6XlMqVnXbtEak6sUMU90UHCO+zSFAMUExqUb1YOcT JXHEL9SJtjDQ6Ed3u1L2W1biaZ1QQkU7lcDcg= 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=N7Zi+bmxFeTPGGj1PxB9/MLlYHFoog+nnJcFYtwo0O8=; b=eGM2drS90N3s65+rb0k3RLXRzwKXjnaJRvaxcqb15Zx89/b+zzADGH0EIqP2owfAmQ zylCjwavH9BVanT87iZG5/AhoGx4U2BGTPPQbvoMtOj5Tfha7noKcT0X2l9JH93JqRlk 50PudqmtW/KzAX9GN2qI+4kEPB/YDccRARmxMhpnm+hi05qXG5RYIuNrruGW2YGiRzNf Tjyio+IwBZndkFoG4XEa9Vw98oDP6WjdzBfjuE4HsO/SFpgmnqMOJKOToL/tDh84UJ7N KFUTYjiXknoPhiL82KC4yujdwYwPMdHPL8SxBJ2Ku5fBp7cNUmQT6THT9R1c9HlZ9Ok+ y9fQ== X-Gm-Message-State: AOAM532lk+fXQIGMXPncTgv1iS2+DXg95M2zaADKOapIDQ51gpBaG8cn kMgVshcP+eL+1BtqMmxdAT7tIZnkDS6wY/RFFEYQng== X-Google-Smtp-Source: ABdhPJyfoPYCOpkuTCOIXoCW2mDiwodpJmuvAJrKdJ2P/BzfZGqk4dj/BBdhzJ7DBqSgjSfRXX8X8v1vcNJVJjv0Yog= X-Received: by 2002:aca:52c4:: with SMTP id g187mr467717oib.101.1601937822236; Mon, 05 Oct 2020 15:43:42 -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> <20201005172854.GA5177@ziepe.ca> <20201005183704.GC5177@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Tue, 6 Oct 2020 00:43:31 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Jason Gunthorpe Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , 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 Content-Type: text/plain; charset="UTF-8" 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: On Mon, Oct 5, 2020 at 8:54 PM Daniel Vetter wrote: > > On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe wrote: > > > > On Mon, Oct 05, 2020 at 08:16:33PM +0200, Daniel Vetter wrote: > > > > > > kvm is some similar hack added for P2P DMA, see commit > > > > add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by notifiers.. > > > > > > Yeah my thinking is that kvm (and I think also vfio, also seems to > > > have mmu notifier nearby) are ok because of the mmu notiifer. Assuming > > > that one works correctly. > > > > vfio doesn't have a notifier, Alex was looking to add a vfio private > > scheme in the vma->private_data: > > > > https://lore.kernel.org/kvm/159017449210.18853.15037950701494323009.stgit@gimli.home/ > > > > Guess it never happened. > > I was mislead by the mmu notifier in drivers/vfio/vfio.c. But looking > closer, that's only used by some drivers, I guess to make sure their > device pagetables are kept in sync with reality. And not to make sure > the vfio pfn view is kept in sync with reality. > > This could get real nasty I think. > > > > > So, the answer really is that s390 and media need fixing, and this API > > > > should go away (or become kvm specific) > > > > > > I'm still not clear how you want fo fix this, since your vma->dma_buf > > > idea is kinda a decade long plan and so just not going to happen: > > > > Well, it doesn't mean we have to change every part of dma_buf to > > participate in this. Just the bits media cares about. Or maybe it is > > some higher level varient on top of dma_buf. > > > > Or don't use dma_buf for this, add a new object that just provides > > refcounts and P2P DMA connection for IO pfn ranges.. > > So good news is, I dug some layers deeper in v4l, and there's only 2 > users which do actually handle pfn and don't immediately convert to a > pages array: > - videbuf-dma-contig.c. Luckily videobuf 1 is deprecated since > forever, so I think we might get away with either just breaking this, > or at least tainting kernels and hiding it behind a nasty Kconfig. > This only uses follow_pfn, which we need to keep anyway for vfio in > the unsafe variant :-/ > - videbuf2-vmalloc.c Digging through history this was added to support > import of v4l buffers from drivers that needed contig memory. And way > back before CMA, that meant carveout memory not backed by struct page > *. That should now all have struct pages and be managed by CMA (since > videbuf2-dma-contig.c just uses dma_alloc_coherent underneath), so I > think we can just switch to pin_user_pages(FOLL_LONGTERM here too). > > iow I think I can outright delete the frame vector stuff. Ok this doesn't work, because dma_mmap always uses a remap_pfn_range, which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and not a carveout, we can't get the pages. Plus trying to move the cma pages out of cma for FOLL_LONGTERM would be kinda bad when they've been allocated as a contig block by dma_alloc_coherent :-) So this idea of switching over to pup only is going to break zerocopy. I guess I'll need something else for this then. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch