Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 29 Sep 2020 10:26:22 +0300
From:   Mike Rapoport <rppt@linux.ibm.com>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Nick Piggin <npiggin@gmail.com>,
        Hugh Dickins <hughd@google.com>,
        Peter Zijlstra <peterz@infradead.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, hch@lst.de, rdunlap@infradead.org
Subject: Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
Message-ID: <20200929072622.GN2645148@linux.ibm.com>
References: <20200926213919.26642-1-willy@infradead.org>
 <20200928180307.7573f3b6128b5e3007dfc9f0@linux-foundation.org>
 <20200929034026.GA20115@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200929034026.GA20115@casper.infradead.org>
Precedence: bulk

On Tue, Sep 29, 2020 at 04:40:26AM +0100, Matthew Wilcox wrote:
> On Mon, Sep 28, 2020 at 06:03:07PM -0700, Andrew Morton wrote:
> > Well that's weird and scary looking.  `page' has non-zero refcount yet
> > we go and free random followon pages.  Methinks it merits an
> > explanatory comment?
> 
> Here's some kernel-doc.  Opinions?
> 
> /**
>  * __free_pages - Free pages allocated with alloc_pages().
>  * @page: The page pointer returned from alloc_pages().
>  * @order: The order of the allocation.
>  *
>  * This function differs from put_page() in that it can free multi-page

This sentence presumes existing description/prior knowledge about
put_page().

Maybe

  This function can free multi-page allocations that were not allocated
  with %__GFP_COMP, unlike put_page() that would free only the first page
  in such case. __free_pages() does not ...

>  * allocations that were not allocated with %__GFP_COMP.  This function
>  * does not check that the @order passed in matches that of the
>  * allocation, so it is possible to leak memory.  Freeing more memory than
>  * was allocated will probably be warned about by other debugging checks.
>  *
>  * It is only safe to use the page reference count to determine when
>  * to free an allocation if you use %__GFP_COMP (in which case, you may
>  * as well use put_page() to free the page).  Another thread may have a
>  * speculative reference to the first page, but it has no way of knowing
>  * about the rest of the allocation, so we have to free all but the
>  * first page here.
>  *
>  * Context: May be called in interrupt context but not NMI context.
>  */
> 

-- 
Sincerely yours,
Mike.