Messages in this thread | | | Date | Tue, 29 Sep 2020 04:40:26 +0100 | From | Matthew Wilcox <> | Subject | Re: [PATCH v2] page_alloc: Fix freeing non-compound pages |
| |
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 * 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. */
| |