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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 8A48EC432C3 for ; Tue, 19 Nov 2019 11:37:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 557BD20679 for ; Tue, 19 Nov 2019 11:37:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 557BD20679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BDB776B0010; Tue, 19 Nov 2019 06:37:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8BD26B0266; Tue, 19 Nov 2019 06:37:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA2B56B0269; Tue, 19 Nov 2019 06:37:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 95F046B0010 for ; Tue, 19 Nov 2019 06:37:56 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 4E96F5DCE for ; Tue, 19 Nov 2019 11:37:56 +0000 (UTC) X-FDA: 76172827752.05.copy23_453dfe543ff14 X-HE-Tag: copy23_453dfe543ff14 X-Filterd-Recvd-Size: 4400 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Tue, 19 Nov 2019 11:37:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8BC3DBCC5; Tue, 19 Nov 2019 11:37:52 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 1D7961E47E5; Tue, 19 Nov 2019 12:37:46 +0100 (CET) Date: Tue, 19 Nov 2019 12:37:46 +0100 From: Jan Kara To: John Hubbard Cc: Andrew Morton , Al Viro , Alex Williamson , Benjamin Herrenschmidt , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Christoph Hellwig , Dan Williams , Daniel Vetter , Dave Chinner , David Airlie , "David S . Miller" , Ira Weiny , Jan Kara , Jason Gunthorpe , Jens Axboe , Jonathan Corbet , =?iso-8859-1?B?Suly9G1l?= Glisse , Magnus Karlsson , Mauro Carvalho Chehab , Michael Ellerman , Michal Hocko , Mike Kravetz , Paul Mackerras , Shuah Khan , Vlastimil Babka , bpf@vger.kernel.org, dri-devel@lists.freedesktop.org, kvm@vger.kernel.org, linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org, linux-rdma@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org, linux-mm@kvack.org, LKML Subject: Re: [PATCH v6 17/24] mm/gup: track FOLL_PIN pages Message-ID: <20191119113746.GD25605@quack2.suse.cz> References: <20191119081643.1866232-1-jhubbard@nvidia.com> <20191119081643.1866232-18-jhubbard@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191119081643.1866232-18-jhubbard@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 19-11-19 00:16:36, John Hubbard wrote: > @@ -2025,6 +2149,20 @@ static int __record_subpages(struct page *page, unsigned long addr, > return nr; > } > > +static bool __pin_compound_head(struct page *head, int refs, unsigned int flags) > +{ I don't quite like the proliferation of names starting with __. I don't think there's a good reason for that, particularly in this case. Also 'pin' here is somewhat misleading as we already use term "pin" for the particular way of pinning the page. We could have grab_compound_head() or maybe nail_compound_head() :), but you're native speaker so you may come up with better word. > + if (flags & FOLL_PIN) { > + if (unlikely(!try_pin_compound_head(head, refs))) > + return false; > + } else { > + head = try_get_compound_head(head, refs); > + if (!head) > + return false; > + } > + > + return true; > +} > + > static void put_compound_head(struct page *page, int refs) > { > /* Do a get_page() first, in case refs == page->_refcount */ put_compound_head() needs similar treatment as undo_dev_pagemap(), doesn't it? > @@ -968,7 +973,18 @@ struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr, > if (!*pgmap) > return ERR_PTR(-EFAULT); > page = pfn_to_page(pfn); > - get_page(page); > + > + if (flags & FOLL_GET) > + get_page(page); > + else if (flags & FOLL_PIN) { > + /* > + * try_pin_page() is not actually expected to fail here because > + * we hold the pmd lock so no one can unmap the pmd and free the > + * page that it points to. > + */ > + if (unlikely(!try_pin_page(page))) > + page = ERR_PTR(-EFAULT); > + } This pattern is rather common. So maybe I'd add a helper grab_page(page, flags) doing if (flags & FOLL_GET) get_page(page); else if (flags & FOLL_PIN) return try_pin_page(page); return true; Otherwise the patch looks good to me now. Honza -- Jan Kara SUSE Labs, CR