From: Pavel Kozlov pavel.kozlov@synopsys.com
Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *") a memory leakage problem occurs. Memory allocated for page table entries not released during process termination. This issue can be reproduced by a small program that allocates a large amount of memory. After several runs, you'll see that the amount of free memory has reduced and will continue to reduce after each run. All ARC CPUs are effected by this issue. The issue was introduced since the kernel stable release v5.15-rc1.
As described in commit d9820ff after switch pgtable_t back to struct page *, a pointer to "struct page" and appropriate functions are used to allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't changed and returns the direct virtual address from the PMD (PGD) entry. Than this address used as a parameter in the __pte_free() and as a result this function couldn't release memory page allocated for PTEs.
Fix this issue by changing the pmd_pgtable macro and returning pointer to struct page.
Fixes: d9820ff76f95 ("ARC: mm: switch pgtable_t back to struct page *") Signed-off-by: Pavel Kozlov pavel.kozlov@synopsys.com Cc: Vineet Gupta vgupta@kernel.org Cc: Mike Rapoport rppt@kernel.org Cc: stable@vger.kernel.org # 4.15.x --- arch/arc/include/asm/pgtable-levels.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/include/asm/pgtable-levels.h b/arch/arc/include/asm/pgtable-levels.h index 64ca25d199be..ef68758b69f7 100644 --- a/arch/arc/include/asm/pgtable-levels.h +++ b/arch/arc/include/asm/pgtable-levels.h @@ -161,7 +161,7 @@ #define pmd_pfn(pmd) ((pmd_val(pmd) & PAGE_MASK) >> PAGE_SHIFT) #define pmd_page(pmd) virt_to_page(pmd_page_vaddr(pmd)) #define set_pmd(pmdp, pmd) (*(pmdp) = pmd) -#define pmd_pgtable(pmd) ((pgtable_t) pmd_page_vaddr(pmd)) +#define pmd_pgtable(pmd) ((pgtable_t) pmd_page(pmd))
/* * 4th level paging: pte
On 10/17/22 09:11, Pavel.Kozlov@synopsys.com wrote:
From: Pavel Kozlov pavel.kozlov@synopsys.com
Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *") a memory leakage problem occurs. Memory allocated for page table entries not released during process termination. This issue can be reproduced by a small program that allocates a large amount of memory. After several runs, you'll see that the amount of free memory has reduced and will continue to reduce after each run. All ARC CPUs are effected by this issue. The issue was introduced since the kernel stable release v5.15-rc1.
As described in commit d9820ff after switch pgtable_t back to struct page *, a pointer to "struct page" and appropriate functions are used to allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't changed and returns the direct virtual address from the PMD (PGD) entry. Than this address used as a parameter in the __pte_free() and as a result this function couldn't release memory page allocated for PTEs.
Fix this issue by changing the pmd_pgtable macro and returning pointer to struct page.
Good catch. Curious how did you find it. KMEMCHECK or some such or just oom.
Fixes: d9820ff76f95 ("ARC: mm: switch pgtable_t back to struct page *") Signed-off-by: Pavel Kozlov pavel.kozlov@synopsys.com Cc: Vineet Gupta vgupta@kernel.org Cc: Mike Rapoport rppt@kernel.org Cc: stable@vger.kernel.org # 4.15.x
You meant 5.15.x
Added to for-curr.
Thx, -Vineet
arch/arc/include/asm/pgtable-levels.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/include/asm/pgtable-levels.h b/arch/arc/include/asm/pgtable-levels.h index 64ca25d199be..ef68758b69f7 100644 --- a/arch/arc/include/asm/pgtable-levels.h +++ b/arch/arc/include/asm/pgtable-levels.h @@ -161,7 +161,7 @@ #define pmd_pfn(pmd) ((pmd_val(pmd) & PAGE_MASK) >> PAGE_SHIFT) #define pmd_page(pmd) virt_to_page(pmd_page_vaddr(pmd)) #define set_pmd(pmdp, pmd) (*(pmdp) = pmd) -#define pmd_pgtable(pmd) ((pgtable_t) pmd_page_vaddr(pmd)) +#define pmd_pgtable(pmd) ((pgtable_t) pmd_page(pmd)) /*
- 4th level paging: pte
Good catch. Curious how did you find it. KMEMCHECK or some such or just oom.
I've run glibc tests with 5.16 kernel and got many oom-killer messages and even kernel panic because lack of memory. These symptoms pointed to an issue. kmemleak didn't show anything. Didn't try kmemcheck. I prepared a small test and used git bisect to find to the "blame" commit.
Cc: stable@vger.kernel.org # 4.15.x
You meant 5.15.x
Yes, you right, that's my typo.
Added to for-curr.
Thanks!
Regards, Pavel
linux-stable-mirror@lists.linaro.org
-
Pavel Kozlov -
Pavel.Kozlov＠synopsys.com
-
Vineet Gupta