Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp14308946pxu; Mon, 4 Jan 2021 20:21:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/sSUL1nIgWno7pfsYKzESK4yduTetrWepjhJdsqcFusNHv9ivlG5kSXtbEdOBPvR5t5IE X-Received: by 2002:a17:906:174f:: with SMTP id d15mr62462681eje.52.1609820493415; Mon, 04 Jan 2021 20:21:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609820493; cv=none; d=google.com; s=arc-20160816; b=jjVg/MqgO2xVJvK3YUTwIKPiGFBvYz/CuTxHH4JATWOScYrWwp28ntiOjT2S25bRKh EyRE/R5/XrwLz3s0uCNr7TNU3wU/BxW8PZ7OA1NorsaukdnN1eFQmj+UzJluVYJE8r1U AqyiMYVUIJufIDwvXoI0pODJWzkAURSD3jkQG31EVFs3ySIcxjB3TyBjsbCwsswL+fIL XUKNIvRBixml5dmkM4CKlY0rOka54yebnDg6xTN3rWzjL6RQO2myX2L8LT1NuljQ25Al gKPyNvDKgoxVq1JNSqvILf7xAoTxRU7Be0rk+EfHfXotGQLnvWTPpWXhbhkwv9L0Y3pp 9/sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Q8gOUdE50UNp9LhAlhCoddse7EZKmhUhGDFbU73aCc4=; b=V9ffw3sc9CfAb5MIWE+l3JL3UfVmRiZBYwD6bFMd/LBSr2STMWQM4+NDsU+eNuJgYq O8BUy5zPJYCC7sZVCF7lhHvMAt66Os+f/HXSoHspzHC9pArqk2OMjMrOBYgYdIRG/vlA p36hDU2MZ0v9GM40D7oSw+5PuAM6c85ZXAMoGryxc63y5XeGqprQhdiWF5jMAlzHMQO8 V4qJQFY1qXRpq4ebJdcNb/sTfSzU//JrLe0TzJ/eeDOkSG7ZAEr4fHVypz4zUmD/0v+9 DTBp+SrwzaT5mEM4pleSRMChp9hlPmgWaz11b9QdDJPrDrc2oB5JxaUokzknerO/RRnh jvvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=QQAB3r3U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz8si17871143ejb.237.2021.01.04.20.21.10; Mon, 04 Jan 2021 20:21:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=QQAB3r3U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727838AbhAEETl (ORCPT + 99 others); Mon, 4 Jan 2021 23:19:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726749AbhAEETk (ORCPT ); Mon, 4 Jan 2021 23:19:40 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D8BCC061794 for ; Mon, 4 Jan 2021 20:19:00 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id n26so39568536eju.6 for ; Mon, 04 Jan 2021 20:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q8gOUdE50UNp9LhAlhCoddse7EZKmhUhGDFbU73aCc4=; b=QQAB3r3U7V/2S0pr/HlzDsASSQCQL5YI2Yu+LKkp2b3uUmYomjrfg0xQ/kZkvLyJQ6 upccUaRauLNncsDHq4Dan5ZBkaKXTJoCxVNuWo6SVKRMoKr0n82h1XgfvAGBdNfBPM3x tpbv+nMXZ/yauTzmx7BYKMKDtKWHQl+RnsMxuRFL2Jxbf04JYY8nN/uKYxGMJLS/kCyt 15iKGTLQ6np+ytfvUZKLGX8b/FbMtjsr+qXMrCWxWeH2+cjGgV3haAtGTdB0LH492H/g tnFPN+k4sObUPr8XYZaAxDMevIG02HiaO09sA8oN6jeOYaDd9pD9reN7rEjfXdWPhrcE 22fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q8gOUdE50UNp9LhAlhCoddse7EZKmhUhGDFbU73aCc4=; b=n+xSSB2MaZPgW+c828oo+NswKdVU+StEfXNP5ZlpDv3hABWP2t0pHbb3PzE3Ywdv4d bZgKFIMxceG5E32GWCj1FmATykq26WvmtowrB6EBfcM598hXv0ADFk7eX2PD03VWRbKb a7ANcMUatAXDDepP/D9fDa3kk5cfpb/t7tii1bn3PIDUI5Kg7c2TcY9An0j2olSBc8gE 0c2vR/DaoExlHwsHnlIS2+u8zUKb7bhhF7CXf/mu0gkr+fTmPiSmvRzkEenDgkQCQBWR 9Q9FAqAr4ihOZrIffa3FFwFOGbhAVhfxinFnS2/2TcKF2SWrhkLmn7KtkW4BLbQUegZq GYjQ== X-Gm-Message-State: AOAM5328f7luV8O/9i9VP1PzpJC1Yx/iFloR+gO0X/oLx7PReGdhhn+k Pu3LsQjA4AFZ2W6lkOfy0+vlxhbqCgutJlSTmdRoHA== X-Received: by 2002:a17:907:c15:: with SMTP id ga21mr69757557ejc.472.1609820338819; Mon, 04 Jan 2021 20:18:58 -0800 (PST) MIME-Version: 1.0 References: <160697689204.605323.17629854984697045602.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <160697689204.605323.17629854984697045602.stgit@dwillia2-desk3.amr.corp.intel.com> From: Dan Williams Date: Mon, 4 Jan 2021 20:18:52 -0800 Message-ID: Subject: Re: [PATCH] x86/mm: Fix leak of pmd ptlock To: Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: stable , Dave Hansen , Andy Lutomirski , Peter Zijlstra , X86 ML , "H. Peter Anvin" , Yi Zhang , Linux Kernel Mailing List , linux-nvdimm , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ping, this bug is still present on v5.11-rc2, need a resend? On Wed, Dec 2, 2020 at 10:28 PM Dan Williams wrote: > > Commit 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") > introduced a new location where a pmd was released, but neglected to run > the pmd page destructor. In fact, this happened previously for a > different pmd release path and was fixed by commit: > > c283610e44ec ("x86, mm: do not leak page->ptl for pmd page tables"). > > This issue was hidden until recently because the failure mode is silent, > but commit: > > b2b29d6d0119 ("mm: account PMD tables like PTE tables") > > ...turns the failure mode into this signature: > > BUG: Bad page state in process lt-pmem-ns pfn:15943d > page:000000007262ed7b refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x15943d > flags: 0xaffff800000000() > raw: 00affff800000000 dead000000000100 0000000000000000 0000000000000000 > raw: 0000000000000000 ffff913a029bcc08 00000000fffffbff 0000000000000000 > page dumped because: nonzero mapcount > [..] > dump_stack+0x8b/0xb0 > bad_page.cold+0x63/0x94 > free_pcp_prepare+0x224/0x270 > free_unref_page+0x18/0xd0 > pud_free_pmd_page+0x146/0x160 > ioremap_pud_range+0xe3/0x350 > ioremap_page_range+0x108/0x160 > __ioremap_caller.constprop.0+0x174/0x2b0 > ? memremap+0x7a/0x110 > memremap+0x7a/0x110 > devm_memremap+0x53/0xa0 > pmem_attach_disk+0x4ed/0x530 [nd_pmem] > ? __devm_release_region+0x52/0x80 > nvdimm_bus_probe+0x85/0x210 [libnvdimm] > > Given this is a repeat occurrence it seemed prudent to look for other > places where this destructor might be missing and whether a better > helper is needed. try_to_free_pmd_page() looks like a candidate, but > testing with setting up and tearing down pmd mappings via the dax unit > tests is thus far not triggering the failure. As for a better helper > pmd_free() is close, but it is a messy fit due to requiring an @mm arg. > Also, ___pmd_free_tlb() wants to call paravirt_tlb_remove_table() > instead of free_page(), so open-coded pgtable_pmd_page_dtor() seems the > best way forward for now. > > Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") > Cc: > Cc: Dave Hansen > Cc: Andy Lutomirski > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: x86@kernel.org > Cc: "H. Peter Anvin" > Co-debugged-by: Matthew Wilcox > Tested-by: Yi Zhang > Signed-off-by: Dan Williams > --- > arch/x86/mm/pgtable.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c > index dfd82f51ba66..f6a9e2e36642 100644 > --- a/arch/x86/mm/pgtable.c > +++ b/arch/x86/mm/pgtable.c > @@ -829,6 +829,8 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr) > } > > free_page((unsigned long)pmd_sv); > + > + pgtable_pmd_page_dtor(virt_to_page(pmd)); > free_page((unsigned long)pmd); > > return 1; >