Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp1565550ybc; Wed, 13 Nov 2019 00:24:19 -0800 (PST) X-Google-Smtp-Source: APXvYqywkv6rCw7DY2/f80ektoB/Y/qLrFXAlp/r3k3dku2hNztKH86B2E+pJZz9wE/A9dAP7aMM X-Received: by 2002:aa7:c5d3:: with SMTP id h19mr2302487eds.120.1573633459293; Wed, 13 Nov 2019 00:24:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573633459; cv=none; d=google.com; s=arc-20160816; b=jp+/bn6NkgECQ0qbiFisMeCO2me/iKaOUNo5j8k2vQGW/pIZnevhabBOUiyLViHZaU 8EoZnNyNDzo5F+0t60lbuT7VB/Dv4dVUk/6uCXddLMCkche6AsMA3lV3he4jWGocMHHz uqxPZ+4AnOKqN0+utkWyBTv3SYr+KHiRbnQN9WWQ1VOK5OUekyV4TWqNpay+SU5uzZbv rO1rIrchK6DyyzbPcMnWbMCkjOlLLLqIMYfHnVvw55GPyddU7gyrijLitZD7qwE/B9C6 8rFLTOUYMqzOvTqPZweSKijfFORYXEKixfGKBwrM+GMTm4mnAw3LZb6ddyVBX7FcBbdI R03g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9ayY6gCXrrA3VgRAyrp2bK0EyrP0ektptyzgRBWzw5I=; b=yAko+l5RsUt3KUzhki0Z7V6uDm0Qka//mdSNnY6+JKIBHUcMDGoTQzMdSB2FI1/0+Q hLbD0fBw2AiOv9ecGuoRuA9HbtfSfK5g4Mm4yQncJqJJ5dLfa2CIDquPFC3aRjR6rhx2 UOnpUtK6lnj6IKAQc+9S2FZtuhcakfXsBykJlPrkxyYh0dEl06VEPRitixOo9mdZiivl j5PtdCW2Fon4Mk/GSI4SiUikZRMWV9NWoTE13j8YHvjHH2VSlItljASkkMDAxeHOuQ7K mOob2/OL2f1aCE3afFhunWBAmion+XZPT/puCUiicroExshnkJZMIVtKz3/VZUvvUDhe llsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=A+5ZDAwm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x1si730702ejd.109.2019.11.13.00.23.54; Wed, 13 Nov 2019 00:24:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=A+5ZDAwm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727291AbfKMIW6 (ORCPT + 99 others); Wed, 13 Nov 2019 03:22:58 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:37638 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727312AbfKMIWs (ORCPT ); Wed, 13 Nov 2019 03:22:48 -0500 Received: by mail-oi1-f195.google.com with SMTP id y194so1028606oie.4 for ; Wed, 13 Nov 2019 00:22:48 -0800 (PST) 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=9ayY6gCXrrA3VgRAyrp2bK0EyrP0ektptyzgRBWzw5I=; b=A+5ZDAwm0sisXEXV26bplYhx0LMI9tSEqcz5XKqugaaiNBsieQDhWSu2ezHIxsk3ok PapqJ40EqXbuXexGXvb3dctMfbGHjaFuYDAai4pvCrk3ttwW8fkWJFMlnWK5Sh3WDfzP au9tTKQUHDCal3qSVw21r18Mu3ZTlLggTEjdE= 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=9ayY6gCXrrA3VgRAyrp2bK0EyrP0ektptyzgRBWzw5I=; b=hMTG8dcjpwyIb+EzXfaPk/a6hZKSOhoWb7AvKBI/KMXrjjGzCOdNnl043uH8/Uitrv vrf+a8u2MN23omLyvYBEl1qxSl4hAO791BIFmH0kgiblre2xmN0ShpDfm5qI2VK2PMYQ 3A8+CuOePyrLLG0P1DOKHHI5lkmHA2euy6WRdaKv2T4AYt6xa9K0lAGhikQzvgAfBH6S 4JE0vnoZojQYE3NGE9D40pd3B5mACcsEnYKVZFXu/dxPKOKCjrBtnA8H8PShH663z8TX 0Lht+zRL3FclXPIWN4Ms9Jc6zu3NiBjA75i9ePvXiznRA/Njo6xPo8KPKGRP8WKQOIcL JuYQ== X-Gm-Message-State: APjAAAW+BPpPkcgXWgnW3g0HP2KJKDYC4XL6A3rbBaGpSZCBdpP06Ioe cwsst8I3Fxza0y0usaGrBGvfAjbgk0VX6D4FzNAWMw== X-Received: by 2002:a05:6808:4cf:: with SMTP id a15mr1806257oie.132.1573633368138; Wed, 13 Nov 2019 00:22:48 -0800 (PST) MIME-Version: 1.0 References: <20191112000700.3455038-1-jhubbard@nvidia.com> <20191112203802.GD5584@ziepe.ca> <02fa935c-3469-b766-b691-5660084b60b9@nvidia.com> In-Reply-To: <02fa935c-3469-b766-b691-5660084b60b9@nvidia.com> From: Daniel Vetter Date: Wed, 13 Nov 2019 09:22:36 +0100 Message-ID: Subject: Re: [PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM To: John Hubbard Cc: Jason Gunthorpe , Andrew Morton , Al Viro , Alex Williamson , Benjamin Herrenschmidt , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Christoph Hellwig , Dan Williams , Dave Chinner , David Airlie , "David S . Miller" , Ira Weiny , Jan Kara , Jens Axboe , Jonathan Corbet , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Magnus Karlsson , Mauro Carvalho Chehab , Michael Ellerman , Michal Hocko , Mike Kravetz , Paul Mackerras , Shuah Khan , Vlastimil Babka , bpf , dri-devel , kvm@vger.kernel.org, linux-block@vger.kernel.org, Linux Doc Mailing List , linux-fsdevel@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-rdma@vger.kernel.org, linuxppc-dev , netdev , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 12, 2019 at 10:10 PM John Hubbard wrote: > > On 11/12/19 12:38 PM, Jason Gunthorpe wrote: > > On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote: > >> Hi, > >> > >> The cover letter is long, so the more important stuff is first: > >> > >> * Jason, if you or someone could look at the the VFIO cleanup (patch 8) > >> and conversion to FOLL_PIN (patch 18), to make sure it's use of > >> remote and longterm gup matches what we discussed during the review > >> of v2, I'd appreciate it. > >> > >> * Also for Jason and IB: as noted below, in patch 11, I am (too?) boldly > >> converting from put_user_pages() to release_pages(). > > > > Why are we doing this? I think things got confused here someplace, as > > > Because: > > a) These need put_page() calls, and > > b) there is no put_pages() call, but there is a release_pages() call that > is, arguably, what put_pages() would be. > > > > the comment still says: > > > > /** > > * put_user_page() - release a gup-pinned page > > * @page: pointer to page to be released > > * > > * Pages that were pinned via get_user_pages*() must be released via > > * either put_user_page(), or one of the put_user_pages*() routines > > * below. > > > Ohhh, I missed those comments. They need to all be changed over to > say "pages that were pinned via pin_user_pages*() or > pin_longterm_pages*() must be released via put_user_page*()." > > The get_user_pages*() pages must still be released via put_page. > > The churn is due to a fairly significant change in strategy, whis > is: instead of changing all get_user_pages*() sites to call > put_user_page(), change selected sites to call pin_user_pages*() or > pin_longterm_pages*(), plus put_user_page(). Can't we call this unpin_user_page then, for some symmetry? Or is that even more churn? Looking from afar the naming here seems really confusing. -Daniel > That allows incrementally converting the kernel over to using the > new pin APIs, without taking on the huge risk of a big one-shot > conversion. > > So, I've ended up with one place that actually needs to get reverted > back to get_user_pages(), and that's the IB ODP code. > > > > > I feel like if put_user_pages() is not the correct way to undo > > get_user_pages() then it needs to be deleted. > > > > Yes, you're right. I'll fix the put_user_page comments() as described. > > > thanks, > > John Hubbard > NVIDIA -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch