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 F1567C17447 for ; Wed, 13 Nov 2019 08:22:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA0C82245A for ; Wed, 13 Nov 2019 08:22:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="A+5ZDAwm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA0C82245A 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 2A4186B0007; Wed, 13 Nov 2019 03:22:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 22DE36B0008; Wed, 13 Nov 2019 03:22:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F52C6B000A; Wed, 13 Nov 2019 03:22:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id E982A6B0007 for ; Wed, 13 Nov 2019 03:22:49 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 87AD7181AC9CC for ; Wed, 13 Nov 2019 08:22:49 +0000 (UTC) X-FDA: 76150563258.02.juice86_35b655f1f7863 X-HE-Tag: juice86_35b655f1f7863 X-Filterd-Recvd-Size: 6522 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Nov 2019 08:22:48 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id l20so992432oie.10 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=uBjZOGbcdirma8E/6Td7HCyI9T1mDkCa2xA7HSTHcgXFlrcvwxmR2Mv36CDdyU0eKq o2G9Fd5X/cDUnEFLsCwZnTwV3pDbDvlhhmkE91fGqTvA2gjb9iOO5gdzwcMCyTeQlBLK nT8ESbQ7Qpm4Qea2XiqqwWDlXOJjsfGlq0NBD24W+zKcP56Wp25eAH5hzfB77fzcHK/o chDTPLQ7l8KEp6JuxBQ/vh5/I8N+MltizOZ9tfN5qsRMp/h+fWJgz4iRa7oDFSuh+9dl G470d8nn3TWaGrYc4mkcFz9H9NCbh02Zl4gXE8lyceQRMhalGv2TqEzjt66V9EKf5p9s dUww== X-Gm-Message-State: APjAAAWLskN/x4WCe1evODAREumen6niH2VQqVqdD0KVPqhZ3L7JYzih 3ctAd6anRaWNZf4kDs794UzLgjwIEy2QpW8+W9w+cA== 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" 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 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