Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3970913pxb; Tue, 25 Jan 2022 00:17:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJywYaqqaHxrCrd4A01/512EtRHoEq3Q/4KbBVbEYfFCzopmgbzCULl3xXrnO+5MgESYoNZ9 X-Received: by 2002:a17:902:7290:b0:14b:76f1:b4de with SMTP id d16-20020a170902729000b0014b76f1b4demr1640216pll.42.1643098677486; Tue, 25 Jan 2022 00:17:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643098677; cv=none; d=google.com; s=arc-20160816; b=vhwBnQp600bN20yw0tZQMg92rCEFobeHa5PXDMwq7oYiNCSkPdM94MM4ohzlKAjCuH fj9rafikqoImtDJQpHuDB9rwH93TmFukEP5w1sEYnrL/ch8sZaLiDwIID0+h0qTQWK0V /qkIv4z6YZkI9ar4vKw2+cGXhJMxyB/wHWf8pqj9aHTdneckOUA/irsMyP6AbpHmgccF Z6uFaoSm4j9eW88eyNX1voKZk3I6FOOZAgvAjM+hph5Z5tZBo7mNiJC+OrnImlGtypg/ 5h+jJLPyhRhh63x0z/wbHN/nCJsYvDzPD9mxlgQmNSGRVq+qP9OlimY0qd7Aa+wp2HNI H3mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=keD6p5NlFTCkC81zvyHuiLAX5yNT1dP423S4cQQiQT8=; b=lPMtFSacD+GSQz8SGsTHevA3R87s2oJ2t/hfsKf4dDKY7ddSEBpnTTpUSR9+y49UbE qSIDxq0Sy8XA9/XKBOua26fPX4Y/5qrrvMB0O1EASYbn2QqntZLW36cHai56M0hf4Mtp aAElZGdEn0nlVsXtLfItGoqChhY9BEwTNNtINB4jJ2dpnjVyIWstjoiJNwAUU2qSixur qK3sym/9MUV6epTNxrLAWpK0Ua3+gHLno4pbbmNoXdEbNfep9VI5Pk912kcQLsDN4ON/ axzwQQ+8UzTbHBwaY4J/C7KDURVOt+58PFbKjNaPtSnCU6mM3UY/uFD4mfVXmQgQpl0y fIhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=V2buL2vi; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k27si11587950pgf.723.2022.01.25.00.17.21; Tue, 25 Jan 2022 00:17:57 -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=@linuxfoundation.org header.s=korg header.b=V2buL2vi; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S3411243AbiAYAco (ORCPT + 99 others); Mon, 24 Jan 2022 19:32:44 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:54946 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349082AbiAXVgX (ORCPT ); Mon, 24 Jan 2022 16:36:23 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 48E0961028; Mon, 24 Jan 2022 21:36:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30647C340E4; Mon, 24 Jan 2022 21:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643060181; bh=qBV1D0GmAnp/RCoOC9JnVrd06ImVEIRibKoLoL3oR0I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V2buL2viMQZ9WW593S3rBrG30cDCUgIhC83ZVFaAsDYRgRhL9y8xudYy+AZM1n9Ot VG+uIe4cRWH+NPsBxTLatmzdn+B3Tigbw9BsdSdlJqAVJtqRav0zOyohdKpyp6nMS5 Ft/5vF1V12NFDa6xn8y8Lu9NFXk0TjFdUju9rSOg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicholas Piggin , Michael Ellerman Subject: [PATCH 5.16 0865/1039] powerpc/64s/radix: Fix huge vmap false positive Date: Mon, 24 Jan 2022 19:44:14 +0100 Message-Id: <20220124184154.370583784@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184125.121143506@linuxfoundation.org> References: <20220124184125.121143506@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Nicholas Piggin commit 467ba14e1660b52a2f9338b484704c461bd23019 upstream. pmd_huge() is defined to false when HUGETLB_PAGE is not configured, but the vmap code still installs huge PMDs. This leads to false bad PMD errors when vunmapping because it is not seen as a huge PTE, and the bad PMD check catches it. The end result may not be much more serious than some bad pmd warning messages, because the pmd_none_or_clear_bad() does what we wanted and clears the huge PTE anyway. Fix this by checking pmd_is_leaf(), which checks for a PTE regardless of config options. The whole huge/large/leaf stuff is a tangled mess but that's kernel-wide and not something we can improve much in arch/powerpc code. pmd_page(), pud_page(), etc., called by vmalloc_to_page() on huge vmaps can similarly trigger a false VM_BUG_ON when CONFIG_HUGETLB_PAGE=n, so those checks are adjusted. The checks were added by commit d6eacedd1f0e ("powerpc/book3s: Use config independent helpers for page table walk"), while implementing a similar fix for other page table walking functions. Fixes: d909f9109c30 ("powerpc/64s/radix: Enable HAVE_ARCH_HUGE_VMAP") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211216103342.609192-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++-- arch/powerpc/mm/pgtable_64.c | 14 +++++++++++--- 2 files changed, 13 insertions(+), 5 deletions(-) --- a/arch/powerpc/mm/book3s64/radix_pgtable.c +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c @@ -1100,7 +1100,7 @@ int pud_set_huge(pud_t *pud, phys_addr_t int pud_clear_huge(pud_t *pud) { - if (pud_huge(*pud)) { + if (pud_is_leaf(*pud)) { pud_clear(pud); return 1; } @@ -1147,7 +1147,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t int pmd_clear_huge(pmd_t *pmd) { - if (pmd_huge(*pmd)) { + if (pmd_is_leaf(*pmd)) { pmd_clear(pmd); return 1; } --- a/arch/powerpc/mm/pgtable_64.c +++ b/arch/powerpc/mm/pgtable_64.c @@ -102,7 +102,8 @@ EXPORT_SYMBOL(__pte_frag_size_shift); struct page *p4d_page(p4d_t p4d) { if (p4d_is_leaf(p4d)) { - VM_WARN_ON(!p4d_huge(p4d)); + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP)) + VM_WARN_ON(!p4d_huge(p4d)); return pte_page(p4d_pte(p4d)); } return virt_to_page(p4d_pgtable(p4d)); @@ -112,7 +113,8 @@ struct page *p4d_page(p4d_t p4d) struct page *pud_page(pud_t pud) { if (pud_is_leaf(pud)) { - VM_WARN_ON(!pud_huge(pud)); + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP)) + VM_WARN_ON(!pud_huge(pud)); return pte_page(pud_pte(pud)); } return virt_to_page(pud_pgtable(pud)); @@ -125,7 +127,13 @@ struct page *pud_page(pud_t pud) struct page *pmd_page(pmd_t pmd) { if (pmd_is_leaf(pmd)) { - VM_WARN_ON(!(pmd_large(pmd) || pmd_huge(pmd))); + /* + * vmalloc_to_page may be called on any vmap address (not only + * vmalloc), and it uses pmd_page() etc., when huge vmap is + * enabled so these checks can't be used. + */ + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP)) + VM_WARN_ON(!(pmd_large(pmd) || pmd_huge(pmd))); return pte_page(pmd_pte(pmd)); } return virt_to_page(pmd_page_vaddr(pmd));