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.
