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 F23C7C46466 for ; Mon, 5 Oct 2020 18:54:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 091E920B80 for ; Mon, 5 Oct 2020 18:54:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="OPEUVmyk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 091E920B80 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 7925490001A; Mon, 5 Oct 2020 14:54:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 742AB90000C; Mon, 5 Oct 2020 14:54:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 609F390001A; Mon, 5 Oct 2020 14:54:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id 31DF890000C for ; Mon, 5 Oct 2020 14:54:29 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B32E28249980 for ; Mon, 5 Oct 2020 18:54:28 +0000 (UTC) X-FDA: 77338772616.18.scent85_620353a271c0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 916411017D43A for ; Mon, 5 Oct 2020 18:54:28 +0000 (UTC) X-HE-Tag: scent85_620353a271c0 X-Filterd-Recvd-Size: 6270 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 18:54:27 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id m12so9689950otr.0 for ; Mon, 05 Oct 2020 11:54:27 -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=riuDo1IoXfibXlfR95ykbMPthEQRl10/UIOttc6DAlc=; b=OPEUVmyk+vRCYMZLowcoJCe66KrXHU7rFzOGuwvpAWzjQt85t26GeiBNJSVlLLjdvw IPvkPM1oH6EvZKjVxvy+zdz/tX3xjNAE+ZPS2bki4mizwYxgbHlbrh2rQasAL+fFyYAY b+JjR1NWVmVC0VwtGmMDFoA2fjzgOz0Zifv98= 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=riuDo1IoXfibXlfR95ykbMPthEQRl10/UIOttc6DAlc=; b=o2gJfN88YEM3B3h+X1NX0YeCsAf0IBYx4jqyoEvd35cGnVH4UvcdF5L2TPZZSx5vxU SlsqHRyUWpslRUwHmy4jbejTGN2CfmQIZ+HjxVJ5J6vFs/VAcuGbtRZvit+2g1ZafNWZ BE/msgP8o1KiJEsoY02f7Och6qRwO6VMAhmugT8kVK0PzwD/C4so21gK6INWF6RexcqM osqo2o6d5ZsbqM6GL8o11e9I1ObWbM9mDs1tZasi/h5kw5TXaNgPj5TK/02PsD+GtZL7 Ho42WEBwWolZFLa4kbZ2w3CxmpkEoPRX1TSZH7MBoCAXqkgP6x0maT1w1b8949GLjc9Y 7RGA== X-Gm-Message-State: AOAM5311uxnp0AVWBVzKUuKAdiS3KFjdAG2xkJM7JLqaNcl66pto5ukL f56YHE8Nc8WWG09MCr/RQ9FIn2TDke2PKiLILE48aQ== X-Google-Smtp-Source: ABdhPJy2iw+CknXeuJOFUrqB9oxUe8+tYDJ+itV1cU93c0kTfuWKEYCQyo751DNTn5DqrD42UQCpOE2tQNA/FTrVskw= X-Received: by 2002:a05:6830:1647:: with SMTP id h7mr493595otr.281.1601924066976; Mon, 05 Oct 2020 11:54:26 -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: <20201005183704.GC5177@ziepe.ca> From: Daniel Vetter Date: Mon, 5 Oct 2020 20:54:15 +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: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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch