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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 4F29FC43331 for ; Wed, 13 Nov 2019 08:22:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2697C2245C for ; Wed, 13 Nov 2019 08:22:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="A+5ZDAwm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727176AbfKMIWy (ORCPT ); Wed, 13 Nov 2019 03:22:54 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:35782 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727302AbfKMIWt (ORCPT ); Wed, 13 Nov 2019 03:22:49 -0500 Received: by mail-oi1-f196.google.com with SMTP id n16so1032430oig.2 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=tp+3R0YxFuTVbhWVyxKI78ua4BCN81hHLeFuT3sWtrnbpEm8odToklFes5iDSGMGGW g+Gkc1vnbcXeJZ0G/O0j+o3gkCPn8C7XG6/AJX4dWvssDgzu/1g3DXtg3y09WK4twodR Gt4NxztaNo/GJYAX/avpyxa15FBlwuahJ2y8cZ+Wmq8Ou7hj5QP0mqEdlufvcL4aOFt5 XKW5ReDDdCaiqjXsuhSnbDBhgCNRDWMLTIhlXNsdOoDtcpmWw8OVYCMY3hCwlnaKCrAE lJzF+3AUFKj5A8bIL3gwa6Ss6StA/xfB5HjhFZtuZFdicpp1JHgC8fKvtDllGhonZg3Q 0u7A== X-Gm-Message-State: APjAAAXPWoH0S7y/reig+CdLXd0LHFQ9USyNyiXWnqf472Gx5wrH6AcB Nd+HsGLcffQgSBjQ76C4D6T4Lm/AIzy1ARs24OkYrg== X-Google-Smtp-Source: APXvYqxfSdLpxppf1Yvj8Pnz7e2iZsxyqjYKBICjfkF8MEX8zkGbqRRzZo57EW2FfCAXfyKFCc6JsAljOesoFoCv0a8= 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: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@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