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 7500CC636CC for ; Wed, 8 Feb 2023 17:28:42 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pGBfWF9+KhakYDTy7qV1quoBteRB6fhQMgtS2sxckI0=; b=xBdaYo6OjA3dqd 5V1h5e/trJmXltb9nj5cDOZ/t98JrqPUz/7sG60K3Ad8gSuN7FXrv1pbvexS1dY+RfiBiBFGSfT0E n6vIzQcAZyFCmKWpaZl3oVx9nPr7BKw6cxdJbTsLBcEuvR0W3PEIWa9AM5TxIKjPXqhX2jB0S+Uy7 VTO+RLOdHRn5h3SsTX4IzBKe/TrwCTy8uxTAbzunaCcl0WIXe1UQa50RzfQhfmQMsG9vtGy54le7f 8NwzWByQVX9frqEsmfh6UBcYkiUWigRw/f4he2xrVbCE/UtzD6HkKOfjUTo5U92gspnCbJcFm9UPR cYvFsO2pgJQ9Du/EyC4A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPoET-00GRnV-DT; Wed, 08 Feb 2023 17:27:45 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPoEM-00GRjn-BJ for linux-arm-kernel@lists.infradead.org; Wed, 08 Feb 2023 17:27:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 393DA1477; Wed, 8 Feb 2023 09:28:14 -0800 (PST) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.30.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8DF383F8C6; Wed, 8 Feb 2023 09:27:30 -0800 (PST) Date: Wed, 8 Feb 2023 17:27:24 +0000 From: Mark Rutland To: Muchun Song Cc: Will Deacon , Catalin Marinas , Robin Murphy , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, Andrew Morton , linux-kernel@vger.kernel.org, Mark Brown Subject: Re: [PATCH V2] arm64/mm: Intercept pfn changes in set_pte_at() Message-ID: References: <20230131154950.GB2646@willie-the-truck> <20230203101023.GA5597@willie-the-truck> <93461768-791A-45BE-BEF2-344CC5228C92@linux.dev> <20230207143131.GA12475@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230208_092738_456771_C124ACE8 X-CRM114-Status: GOOD ( 19.51 ) 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 Wed, Feb 08, 2023 at 11:13:46AM +0800, Muchun Song wrote: > > On Feb 7, 2023, at 22:31, Will Deacon wrote: > > On Mon, Feb 06, 2023 at 11:28:12AM +0800, Muchun Song wrote: > >> 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)? Yes, that is one possible result. > So it is a bogus physical address? Yes, that is one possible result. > Is there any specifications to describe the rules of how to create a > amalgamated TLB entry? Thanks. Unfortunately, this is not clearly specified in the ARM ARM, and we have to take a pessimistic reading here. We assume that amalgamation is some arbitrary function of the TLB entries which are hit (e.g. they might be OR'd together). This is something that I'd like to have clarified further by Arm's architects. The important thing to note is that amalgamation applies to *TLB entries*, not the translation table entries that they were derived from. Since the TLB format is micro-architecture dependent, and since the manner in which they might be combined is arbitrary, the results of combining could be arbitrary (and consequently, this is difficult to specify). The architecture *does* provide a few restrictions (e.g. Stage-1 entries within a VM can't escape Stage-2, NS entries can't create a secure physical address), but beyond that we cannot make any assumptions. So e.g. if you have 2 read-only entries for addresses A and B, amalgamation could result in read-write-execute for a distinct address C. It's not clear to me whether that could also affect hits for unrelated VAs. So the short answer is that we have to treat this as CONSTRAINED UNPREDICTABLE, and must avoid potential amalgamation by using Break-Before-Make. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel