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.8 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 8A223C43457 for ; Fri, 16 Oct 2020 08:03:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EE08D2063A for ; Fri, 16 Oct 2020 08:03:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PYscHGEN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE08D2063A 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 6D8C8900002; Fri, 16 Oct 2020 04:03:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66231940008; Fri, 16 Oct 2020 04:03:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5513A900003; Fri, 16 Oct 2020 04:03:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 3E923900002 for ; Fri, 16 Oct 2020 04:03:53 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 03A72180AD806 for ; Fri, 16 Oct 2020 08:03:53 +0000 (UTC) X-FDA: 77377049946.21.sink99_28123d42721b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id DAD07180442C2 for ; Fri, 16 Oct 2020 08:03:52 +0000 (UTC) X-HE-Tag: sink99_28123d42721b X-Filterd-Recvd-Size: 5485 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Fri, 16 Oct 2020 08:03:52 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id w204so1510891oiw.1 for ; Fri, 16 Oct 2020 01:03:51 -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=INEWr2CP3X204G2+3BdRku1fQyrBAx5gcE6UKT3OyOY=; b=PYscHGENn896fSGfivBibPnplvLtnL/b2OJMTMD4dpMHQHxNw+64iWRis9sD2nvJ3L GOV/hMMVbuuc/Dh9AKUrk63GN8LOY99ye984UM1brrmBjSpje4c9K1cdtapwwULr3uYK 5a7sZUI60W2i8WwwI8UzzVDb5t1NNMYrEKGHc= 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=INEWr2CP3X204G2+3BdRku1fQyrBAx5gcE6UKT3OyOY=; b=c/bc/p4W/EWLoEeU6DkMbhPXqF97z69Lr2bQhEmlvIi504KhOsxJBy3udvLMBqXzAH s6H+iQhXsZaOA35ssek0XQCyWyh9jQfNXXrreIHgRxmey6SBtBMbb/JjgbpVl5Z1WPyW T8Cwdglcv+TyqE6kGQmaDDMJrr2AkaJ19EU6KYfZw93l2cmLw+N1j3/H2YsFdMZrxcA1 uPDXbASm1+vKSaLyqfZ8sExLgUwP+cyPo22+BOPQBU5sL+5sXITMTHxMnfseh1gTtWOi nL+D2U8HfQxLwW9oGVaDTgNAMEhAlRtP3gsUsjKuZ++e8niUWnJcEwdMlEkSRqI35+bM dx1Q== X-Gm-Message-State: AOAM532gcyH950mbJtGlDGSdtHxXNW+XHfedJmi9PPoPiHk0dxzmTIjB jnfDMWgLeJzoWMgLEA3RyLlUfB2TSu2JK/TPzqkETQ== X-Google-Smtp-Source: ABdhPJyggtVpJqRzRZN6iIJJ0+C7Hddh3AOv25V3h7tJwuwrOe4WsT5egHelZJkzdhhjjawKTJeCGzwdsP8tFNIJ4dY= X-Received: by 2002:aca:cc01:: with SMTP id c1mr1679690oig.128.1602835431410; Fri, 16 Oct 2020 01:03:51 -0700 (PDT) MIME-Version: 1.0 References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-6-daniel.vetter@ffwll.ch> <4685181e-8306-0d96-8be6-592b3c563cbf@nvidia.com> In-Reply-To: <4685181e-8306-0d96-8be6-592b3c563cbf@nvidia.com> From: Daniel Vetter Date: Fri, 16 Oct 2020 10:03:40 +0200 Message-ID: Subject: Re: [PATCH v2 05/17] mm/frame-vector: Use FOLL_LONGTERM To: John Hubbard Cc: DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-s390 , Daniel Vetter , Jason Gunthorpe , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Tomasz Figa , Mauro Carvalho Chehab , Andrew Morton , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Dan Williams 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 Fri, Oct 16, 2020 at 9:54 AM John Hubbard wrote: > > On 10/9/20 12:59 AM, Daniel Vetter wrote: > ... > > @@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > > > > start = untagged_addr(start); > > > > - mmap_read_lock(mm); > > - locked = 1; > > - vma = find_vma_intersection(mm, start, start + 1); > > - if (!vma) { > > - ret = -EFAULT; > > - goto out; > > - } > > - > > - /* > > - * While get_vaddr_frames() could be used for transient (kernel > > - * controlled lifetime) pinning of memory pages all current > > - * users establish long term (userspace controlled lifetime) > > - * page pinning. Treat get_vaddr_frames() like > > - * get_user_pages_longterm() and disallow it for filesystem-dax > > - * mappings. > > - */ > > - if (vma_is_fsdax(vma)) { > > - ret = -EOPNOTSUPP; > > - goto out; > > - } > > - > > - if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) { > > + ret = pin_user_pages_fast(start, nr_frames, > > + FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, > > + (struct page **)(vec->ptrs)); > > + if (ret > 0) { > > None of the callers that we have today will accept anything less than > ret == nr_frames. And the whole partially pinned region idea turns out > to be just not useful for almost everyone, from what I recall of the gup/pup > call sites. So I wonder if we should just have get_vaddr_frames do the > cleanup here and return -EFAULT, if ret != nr_frames ? Yeah I noticed that the calling convention here is a bit funny. But I with these frame-vector helpers now being part of drivers/media it's up to media folks if they want to clean that up, or leave it as is. If this would be in drm I'd say we'll have the loud warning and tainting due to CONFIG_STRICT_FOLLOW_PFN=n for 2-3 years. Then assuming no big complaints showed up, rip it all out and just directly call pup in each place that wants it (like I've done for habanalabs and exynos). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch