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 C59B8C47095 for ; Wed, 7 Oct 2020 12:58:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4CDF8207EA for ; Wed, 7 Oct 2020 12:58:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="HLP5cVy/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CDF8207EA 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 83E846B0068; Wed, 7 Oct 2020 08:58:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EC828E0001; Wed, 7 Oct 2020 08:58:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 702B56B006E; Wed, 7 Oct 2020 08:58:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 4477C6B0068 for ; Wed, 7 Oct 2020 08:58:46 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DC479181AE86B for ; Wed, 7 Oct 2020 12:58:45 +0000 (UTC) X-FDA: 77345133810.22.hole65_4813775271cf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id BA8C318038E67 for ; Wed, 7 Oct 2020 12:58:45 +0000 (UTC) X-HE-Tag: hole65_4813775271cf X-Filterd-Recvd-Size: 5458 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 12:58:45 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id m13so2046084otl.9 for ; Wed, 07 Oct 2020 05:58:44 -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=RqJhQ9wl4HnfFJba5qafgVA83HvKuODOv14/VuzQKBc=; b=HLP5cVy/+ivPAr8S6VW2DODWQvroNZFg7BttjeOcbezz6CNNniUIHSIARYKF8Ijk1T rmy9z7yE9flAapP4YSBu9HIymzY2iBki4HzaALq9rM2UBFkXQlEaW3TvVZzqH2LSayDe 1rPcp7GgFX99YVk0vI8HYbxifKX0pBDMeSfv0= 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=RqJhQ9wl4HnfFJba5qafgVA83HvKuODOv14/VuzQKBc=; b=CRnhuM9xiVk9FPH/zKX7QenVAP0CpJ/cHazfUMAdVpaPbSbnYbH9K1FObhHEuFLKSi XaTK7nTUKke5yiAXaJoLskXGplZm/bzCjXPa1m95+q67489TsxJi+saS3Fq+d5+F7mFB IILZW1bpq9PlA90aHH6YzeHupr7caryAgDIEcnoym12ERvgm88ADeMLAFvODRy0pwbEt HBgVQhhRhB/M8nIHzkbOgjZv2RhwCI8/6aR+pYaoyd9Lz2wu4VCVRd63Xmo3wDut5cGW OfSF2iBOnEz1x9KWj1se7V/UOPe/ClrO6cBtQvv38v2IdpgVDVI6Ne8UWIjDB1dhGIpZ PmAg== X-Gm-Message-State: AOAM5323+xecOqwX1/wv/vx7J+nZ7qa6UU9IQmoV1c87haYkH4ikFzmg 7OSgk2XuALKzrLxBXBW6MUAkrekAFmXf1RyhpegKxA== X-Google-Smtp-Source: ABdhPJwvOqDF0PtNvyjRy9NUPdpqckHeo5Pb4aBKzEFyLCyusu6A+MJ6CRQQIQu70npKdaR3NW8xVD0BDZv4+5HBzkA= X-Received: by 2002:a05:6830:1e56:: with SMTP id e22mr1696603otj.303.1602075524433; Wed, 07 Oct 2020 05:58:44 -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> <725819e9-4f07-3f04-08f8-b6180406b339@samsung.com> <20201007124409.GN5177@ziepe.ca> In-Reply-To: From: Daniel Vetter Date: Wed, 7 Oct 2020 14:58:33 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM To: Tomasz Figa Cc: Jason Gunthorpe , Marek Szyprowski , DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Dan Williams , Linux MM , Linux ARM , Pawel Osciak , Kyungmin Park , 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 Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa wrote: > > On Wed, Oct 7, 2020 at 2:44 PM Jason Gunthorpe wrote: > > > > On Wed, Oct 07, 2020 at 02:33:56PM +0200, Marek Szyprowski wrote: > > > Well, it was in vb2_get_vma() function, but now I see that it has been > > > lost in fb639eb39154 and 6690c8c78c74 some time ago... > > > > There is no guarentee that holding a get on the file says anthing > > about the VMA. This needed to check that the file was some special > > kind of file that promised the VMA layout and file lifetime are > > connected. > > > > Also, cloning a VMA outside the mm world is just really bad. That > > would screw up many assumptions the drivers make. > > > > If it is all obsolete I say we hide it behind a default n config > > symbol and taint the kernel if anything uses it. > > > > Add a big comment above the follow_pfn to warn others away from this > > code. > > Sadly it's just verbally declared as deprecated and not formally noted > anyway. There are a lot of userspace applications relying on user > pointer support. userptr can stay, it's the userptr abuse for zerocpy buffer sharing which doesn't work anymore. At least without major surgery (you'd need an mmu notifier to zap mappings and recreate them, and that pretty much breaks the v4l model of preallocating all buffers to make sure we never underflow the buffer queue). And static mappings are not coming back I think, we'll go ever more into the direction of dynamic mappings and moving stuff around as needed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch