From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1C958C636D6 for ; Wed, 8 Feb 2023 03:16:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:References:Message-Id:Cc:Date: In-Reply-To:From:Subject:MIME-Version:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UXXXiHaw0a1VT8+dvbruzNmkTzjb/ztuiuY889/6RL0=; b=LnMD0010eGI781 REDEFX/N1UwukkqFk+Z3CWeNPWjs6cd9Gw9ca4Bdhvc3G62lCrQ2rbqHlX99DSWeHtwm5bSz/8/eT C0X0MPnDO7NYL4lYiVsgqbQFaEzWL5ec0yATDsulJBUFIA0UaJxU8CpOxbGZCrgoRDAOe3v02iBTM Xs71F6nsFWiUDaRSJj+0L26JIBrdT3gRbHCyG6bGF8DwypmhosZl6Lde9ciVdCz+l6k8vTuJpEHmi Jsd3BrnEexQJV64Ovdt2ILnOkVnosWSdwSAx4eZ6tmEpz7wsqh98MQrNdMDoZSwLOcvwAgg0p1/m8 UrPWsg6fmpUnnu5ONbaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPav5-00DutL-E6; Wed, 08 Feb 2023 03:14:51 +0000 Received: from out-64.mta1.migadu.com ([95.215.58.64]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPauv-00Duqy-FH for linux-arm-kernel@lists.infradead.org; Wed, 08 Feb 2023 03:14:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1675826069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lmNO8ZvQKaTkdERQULbnyw6Hc5sWsKOu9F+mkxB4iyU=; b=H7VyY7chdYq41tFb5E9FnhdqH2dIXn01Sdy8nVqemHCiqtmebqmthIM4N/JiSHjHJ5IZRm thYDaGnM/+zgbpSUEKQI56vYHGfJ7Jpy8yVrF/3FaIlkm8mNnuCbTrlLPM2EHMV/y6+F7c E2Q2uGMAjecM+a6CPyh5P9fnrpqNLaU= MIME-Version: 1.0 Subject: Re: [PATCH V2] arm64/mm: Intercept pfn changes in set_pte_at() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20230207143131.GA12475@willie-the-truck> Date: Wed, 8 Feb 2023 11:13:46 +0800 Cc: Catalin Marinas , Robin Murphy , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, Mark Rutland , Andrew Morton , linux-kernel@vger.kernel.org, Mark Brown Message-Id: References: <20230126133321.GB29148@willie-the-truck> <20230131154950.GB2646@willie-the-truck> <20230203101023.GA5597@willie-the-truck> <93461768-791A-45BE-BEF2-344CC5228C92@linux.dev> <20230207143131.GA12475@willie-the-truck> To: Will Deacon X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230207_191441_831617_2E402674 X-CRM114-Status: GOOD ( 25.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > On Feb 7, 2023, at 22:31, Will Deacon wrote: > > On Mon, Feb 06, 2023 at 11:28:12AM +0800, Muchun Song wrote: >> >> >>> On Feb 3, 2023, at 18:10, Will Deacon wrote: >>> >>> On Fri, Feb 03, 2023 at 10:40:18AM +0800, Muchun Song wrote: >>>> >>>> >>>>> On Feb 2, 2023, at 18:45, Catalin Marinas wrote: >>>>> >>>>> On Thu, Feb 02, 2023 at 05:51:39PM +0800, Muchun Song wrote: >>>>>>> On Feb 1, 2023, at 20:20, Catalin Marinas wrote: >>>>>>>> Bah, sorry! Catalin reckons it may have been him talking about the vmemmap. >>>>>>> >>>>>>> Indeed. The discussion with Anshuman started from this thread: >>>>>>> >>>>>>> https://lore.kernel.org/all/20221025014215.3466904-1-mawupeng1@huawei.com/ >>>>>>> >>>>>>> We already trip over the existing checks even without Anshuman's patch, >>>>>>> though only by chance. We are not setting the software PTE_DIRTY on the >>>>>>> new pte (we don't bother with this bit for kernel mappings). >>>>>>> >>>>>>> Given that the vmemmap ptes are still live when such change happens and >>>>>>> no-one came with a solution to the break-before-make problem, I propose >>>>>>> we revert the arm64 part of commit 47010c040dec ("mm: hugetlb_vmemmap: >>>>>>> cleanup CONFIG_HUGETLB_PAGE_FREE_VMEMMAP*"). We just need this hunk: >>>>>>> >>>>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>>>>>> index 27b2592698b0..5263454a5794 100644 >>>>>>> --- a/arch/arm64/Kconfig >>>>>>> +++ b/arch/arm64/Kconfig >>>>>>> @@ -100,7 +100,6 @@ config ARM64 >>>>>>> select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT >>>>>>> select ARCH_WANT_FRAME_POINTERS >>>>>>> select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36) >>>>>>> - select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP >>>>>> >>>>>> Maybe it is a little overkill for HVO as it can significantly minimize the >>>>>> overhead of vmemmap on ARM64 servers for some workloads (like qemu, DPDK). >>>>>> So I don't think disabling it is a good approach. Indeed, HVO broke BBM, >>>>>> but the waring does not affect anything since the tail vmemmap pages are >>>>>> supposed to be read-only. So, I suggest skipping warnings if it is the >>>>>> vmemmap address in set_pte_at(). What do you think of? >>>>> >>>>> IIUC, vmemmap_remap_pte() not only makes the pte read-only but also >>>>> changes the output address. Architecturally, this needs a BBM sequence. >>>>> We can avoid going through an invalid pte if we first make the pte >>>>> read-only, TLBI but keeping the same pfn, followed by a change of the >>>>> pfn while keeping the pte readonly. This also assumes that the content >>>>> of the page pointed at by the pte is the same at both old and new pfn. >>>> >>>> Right. I think using BBM is to avoid possibly creating multiple TLB entries >>>> for the same address for a extremely short period. But accessing either the >>>> old page or the new page is fine in this case. Is it acceptable for this >>>> special case without using BBM? >>> >>> Sadly, the architecture allows the CPU to conjure up a mapping based on a >>> combination of the old and the new descriptor (a process known as >>> "amalgamation") so we _really_ need the BBM sequence. >> >> I am not familiar with ARM64, what's the user-visible effect if this >> "amalgamation" occurs? > > The user-visible effects would probably be data corruption and instability, > since the amalgamated TLB entry could result in a bogus physical address and > bogus permissions. You mean the output address of amalgamated TLB entry is neither the old address (before updated) nor the new address (after updated)? So it is a bogus physical address? Is there any specifications to describe the rules of how to create a amalgamated TLB entry? Thanks. Muchun > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel