netdev - Re: [PATCH v6 17/24] mm/gup: track FOLL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <92d0385a-90be-e900-e5ec-1eeafd24ff81@nvidia.com>
Date:   Tue, 19 Nov 2019 23:17:16 -0800
From:   John Hubbard <jhubbard@...dia.com>
To:     Jan Kara <jack@...e.cz>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Alex Williamson <alex.williamson@...hat.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Björn Töpel <bjorn.topel@...el.com>,
        Christoph Hellwig <hch@...radead.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Dave Chinner <david@...morbit.com>,
        David Airlie <airlied@...ux.ie>,
        "David S . Miller" <davem@...emloft.net>,
        Ira Weiny <ira.weiny@...el.com>,
        Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>,
        Jonathan Corbet <corbet@....net>,
        Jérôme Glisse <jglisse@...hat.com>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Michal Hocko <mhocko@...e.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Paul Mackerras <paulus@...ba.org>,
        Shuah Khan <shuah@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>, <bpf@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>, <kvm@...r.kernel.org>,
        <linux-block@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-fsdevel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
        <linux-media@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
        <linuxppc-dev@...ts.ozlabs.org>, <netdev@...r.kernel.org>,
        <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 17/24] mm/gup: track FOLL_PIN pages

On 11/19/19 3:37 AM, Jan Kara wrote:
> 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.


Yes, it is ugly naming, I'll change these as follows:

    __pin_compound_head() --> grab_compound_head()    
    __record_subpages()   --> record_subpages()

I loved the "nail_compound_head()" suggestion, it just seems very vivid, but
in the end, I figured I'd better keep it relatively drab and colorless. :)

> 
>> +	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?
> 

Yes, will fix that up.


>> @@ -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;
> 

OK.

> Otherwise the patch looks good to me now.
> 
> 								Honza

Great! I thought I'd have a v7 out today, but fate decided to have me repair
my test machine instead. So, soon. ha. :)

thanks,
-- 
John Hubbard
NVIDIA