[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d863bcc8-ce96-4095-b4ef-4a0da73e985e@redhat.com>
Date: Tue, 17 Dec 2024 12:56:41 +0100
From: David Hildenbrand <david@...hat.com>
To: Liu Shixin <liushixin2@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Muchun Song <muchun.song@...ux.dev>,
Kenneth W Chen <kenneth.w.chen@...el.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>, Nanyong Sun <sunnanyong@...wei.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: hugetlb: independent PMD page table shared count
On 17.12.24 03:02, Liu Shixin wrote:
>
>
> On 2024/12/16 23:34, David Hildenbrand wrote:
>> On 14.12.24 11:44, Liu Shixin wrote:
>>> The folio refcount may be increased unexpectly through try_get_folio() by
>>> caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to
>>> check whether a pmd page table is shared. The check is incorrect if the
>>> refcount is increased by the above caller, and this can cause the page
>>> table leaked:
>>
>> Are you sure it is "leaked" ?
>>
>> I assume what happens is that we end up freeing a page table without calling its constructor. That's why page freeing code complains about "nonzero mapcount" (overlayed by something else).
>
> 1. The page table itself will be discarded after reporting the "nonzero mapcount".
>
> 2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared
> and a shared page table will not be to unmap.
Ah, the page table still maps something, that makes sense. So we're
leaking that indeed.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists