Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3617449pxb; Mon, 24 Jan 2022 13:37:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNQImIqFhax1BBi81l5O6+v7aPCIu/zMPKF8aLWsR2RWnjnl3iUFvngdkYrrv/yYY8J4yV X-Received: by 2002:a63:a10a:: with SMTP id b10mr12993430pgf.403.1643060240991; Mon, 24 Jan 2022 13:37:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643060240; cv=none; d=google.com; s=arc-20160816; b=sPImDTgPw8Q/FIpeUejVj7c2ME5VkvnQoKIn9W0MiOQIj1PscccF3vo3iaLuB/t5BD 2JDjWg31NCehJ7QOq80y6VnGTouQlvz8KtXZ2ausspV8qAbbkjYyZw2uuf9fMX2arFaZ /3oj2QHVmYr6195WdJDNum/qad1+yybGcEockbKrczhcxrVmnvTfQxmVSFbcN5jhBDdS flN5cSq3a1zHUK9gq6rqF+5007SbYdyWY+YgVgiGfjNtV9NCiVgDZILVW+J2RE4Djg6K gNmAzbhkD/Vk0CR9XfGMwSVDRoP0d2hZHkhGJf8fNGH/E7GccIYTjuZwsngrM9CIRApL kTTw== 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=+uF083HAi4K2cft5QMDQ0PvVgwsilxYTthldBVNA5ls=; b=Y5Eh7GlZFIXh1E/4T/UAF7N2AyPCyTzsmr4oTvROuP5pJIInwgZ27FrRE+eU8RORro //AH8Xm99oy6lpNOC7V1VzfZviDUfHRXUwBB4vp3h7u0C2BuEGPPXhIiKxNUiAeHSmWl k2otpcxe7Yf06xZXegVSpdxplDdST9SZNeh7Fpk4Tp8Cj9k0VhCCFs2BwuSzDCXq7/Im l9xKZXZrdzTEQjJincDAxMb/uACqb2ryri4K6av3Yc3LM1KY/wID/G0pTV7vU4d9sF9W tlo04Mu3b4rRULqe+Q+htBP1GCGEckBf9z46sLEmeEzp6c4iWVltBTB2opKPLRpWFgoJ oPWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=huD8dDlT; 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 v64si8607721pgd.505.2022.01.24.13.37.09; Mon, 24 Jan 2022 13:37:20 -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=huD8dDlT; 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 S1447879AbiAXVLh (ORCPT + 99 others); Mon, 24 Jan 2022 16:11:37 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:37962 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1389973AbiAXUpD (ORCPT ); Mon, 24 Jan 2022 15:45:03 -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 220EE60916; Mon, 24 Jan 2022 20:44:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBEF1C340E5; Mon, 24 Jan 2022 20:44:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643057081; bh=wxZq9oTaGqilA11OlATDIroEGM8Are41LNXDV3VNAsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=huD8dDlTbUo4LPzWtj/yx1SU/IDx++AgT642n2YejURadDRN9JPkpIMeAB8Hw9RjX 4IR68kcnb9wVtMoBQSsdl8N45YWyCl+485+oVOlQ0h93IEQQFuVuj7jcz2+FKUNKXV 2vp3y/bSBYppO7x8MpHLNKwMzsG11IdmpNYk23W0= 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.15 696/846] powerpc/64s/radix: Fix huge vmap false positive Date: Mon, 24 Jan 2022 19:43:33 +0100 Message-Id: <20220124184125.068440562@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184100.867127425@linuxfoundation.org> References: <20220124184100.867127425@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 @@ -1093,7 +1093,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; } @@ -1140,7 +1140,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));