From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756101AbdAHX3K (ORCPT ); Sun, 8 Jan 2017 18:29:10 -0500 Received: from mail-wj0-f194.google.com ([209.85.210.194]:34636 "EHLO mail-wj0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754495AbdAHX3I (ORCPT ); Sun, 8 Jan 2017 18:29:08 -0500 Date: Mon, 9 Jan 2017 02:29:04 +0300 From: "Kirill A. Shutemov" To: Hugh Dickins Cc: Linus Torvalds , "Aneesh Kumar K.V" , Andrew Morton , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] mm: stop leaking PageTables Message-ID: <20170108232904.GA17681@node.shutemov.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 07, 2017 at 03:37:31PM -0800, Hugh Dickins wrote: > 4.10-rc loadtest (even on x86, even without THPCache) fails with > "fork: Cannot allocate memory" or some such; and /proc/meminfo > shows PageTables growing. > > rc1 removed the freeing of an unused preallocated pagetable after > do_fault_around() has called map_pages(): which is usually a good > optimization, so that the followup doesn't have to reallocate one; > but it's not sufficient to shift the freeing into alloc_set_pte(), > since there are failure cases (most commonly VM_FAULT_RETRY) which > never reach finish_fault(). > > Check and free it at the outer level in do_fault(), then we don't > need to worry in alloc_set_pte(), and can restore that to how it was > (I cannot find any reason to pte_free() under lock as it was doing). > > And fix a separate pagetable leak, or crash, introduced by the same > change, that could only show up on some ppc64: why does do_set_pmd()'s > failure case attempt to withdraw a pagetable when it never deposited > one, at the same time overwriting (so leaking) the vmf->prealloc_pte? > Residue of an earlier implementation, perhaps? Delete it. > > Fixes: 953c66c2b22a ("mm: THP page cache support for ppc64") > Signed-off-by: Hugh Dickins Sorry, that I missed this initially. Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov