Re: Rare memory leakage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/22/20 5:12 AM, Matthew Wilcox wrote:
> This is a fun little race.
> 
> Dramatis personae: Pages P0, P1 are consecutive and aligned.
> Threads A, B, C.
> 
> Page P0 is allocated to the page cache.
> Page P1 is free.
> 
> Thread A calls find_get_entry()
> P0 is returned from xas_load()
> 
> Thread B removes the page from the page cache (eg truncate, invalidatepage).
> P0 is buddy-merged with P1.
> 
> Thread C calls alloc_pages, order 1, does not specify GFP_COMP.  P0 now
> has refcount 1.
> 
> Thread A calls page_cache_get_speculative().  P0 has refcount 2.
> 
> Thread C calls __free_page(P0, 1)
> put_page_testzero is _false_.  Do not call free_the_page().
> 
> Thread A calls put_page(P0)
> We free P0 and nobody knows to free P1.
> 
> 
> Weird solution: In __free_page(), if put_page_testzero() fails and page
> is not PageHead, convert it to a compound page.  Then the put_page()
> by Thread A will free P1.

I can imagine doing the conversion in a manner that deals with races properly
will be rather tricky...

> Better ideas?

IMHO, alloc_pages() with order > 0 and without __GFP_COMP is a weird beast. In
that case it would be probably best to refcount each base page separately. I
don't know how many assumptions this would break :/




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux