Re: Rare memory leakage

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

 



On Mon, Sep 21, 2020 at 08:43:14PM -0700, Ira Weiny wrote:
> On Tue, Sep 22, 2020 at 04:12:15AM +0100, 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,
> 
> I'm not an expert, so I'm probably off here, but if Thread C calls
> __free_page(P0, 1) wouldn't that be on PageHead?  So how would you know to
> convert it to a compound page?

Only compound pages get PageHead set.  A regular multiorder allocation
without GFP_COMP set does not have PageHead.

void prep_compound_page(struct page *page, unsigned int order)
{
...
        __SetPageHead(page);





[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