From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B0203D8919 for ; Thu, 9 Apr 2026 14:15:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775744164; cv=none; b=eOfaw0v0ws6buaxB1YpVPfvMJpbixuqhkY6wZRF5fxyoYVJGFXxyXaOD39q4Y3ngVRaqwaszhAJOAkIOQg/4CQyIjESxRl7accnO6MxX60iLRctg7zIOtt2mvUjLMv9nnjhCC5FfpYPOEOuzeK6lr/Bu0meQzWU58iK9pQ0/8Oc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775744164; c=relaxed/simple; bh=MQg5bywKNpPb6VNZ/metq27TWY1Lp6tuU6OCUodC17g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JMBksHjfqSdYuvA5XvZGsLEwqS5qsKmsEAi9tK7JUlB8MGPQaD47lbebJTO0iCpjwlJok2Y7zgLfoSFpE24bor6FEzE6uY5TvbhJaJJaR3DyNShI6LXRLsZVoRtu/cs91BuVAR/w+GjJz4xuKDBG43fipnUEhmmjjxj42NfhmBY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=quN3kbC2; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="quN3kbC2" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u6rzWnss5mwBycv3niUfS6P/CpxzahiWocWAW0Ks5ck=; b=quN3kbC2aNXq9A4MZ2/8PJT9l9 bWybZToi8uNhnkYP1tTsdZRfg0fwjYmRvSzX4bMudwuKquG4k2eFTgNxK3X3rLSOi6Jz8NLAJG8F+ LCV0YC1p2jiSsWg7TL+Hy95c96IquDh1wimq1cbVh6mS9qkrCZtvQvM5yuBOCU5a3zAQ5xQGww/bu 2cBaN9NO829b8qabQQCA8p4LQiM0tlIEWI263Ifqpe9edUiq26jWbsMvzV8emLhs0yMxIHC2U+tEk Y3MvDDHS90/6r//g/gpuYUYBEn9M/iw4KOe4jAYllxAnrPVv/j0ucqsCIgJx2jIKn5aYYkmAGo5zQ QP8muUyQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:50022) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wAqAh-000000003h0-1so4; Thu, 09 Apr 2026 15:15:51 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1wAqAf-000000004Se-3nw1; Thu, 09 Apr 2026 15:15:49 +0100 Date: Thu, 9 Apr 2026 15:15:49 +0100 From: "Russell King (Oracle)" To: Brian Ruley Cc: Steve Capper , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user Message-ID: References: <20260409125446.981747-1-brian.ruley@gehealthcare.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260409125446.981747-1-brian.ruley@gehealthcare.com> Sender: Russell King (Oracle) On Thu, Apr 09, 2026 at 03:54:45PM +0300, Brian Ruley wrote: > Fixes cache desync, which can cause undefined instruction, > translation and permission faults under heavy memory use. > > This is an old bug introduced in commit 1971188aa196 ("ARM: 7985/1: mm: > implement pte_accessible for faulting mappings"), which included a check > for the young bit of a PTE. The underlying assumption was that old pages > are not cached, therefore, `__sync_icache_dcache' could be skipped > entirely. > > However, under extreme memory pressure, page migrations happen > frequently and the assumption of uncached "old" pages does not hold. The first thing to point out is that PTEs that are marked as "old" are not mapped into userspace. They need to take a fault to be marked young, which will involve another call to set_pte(), at which point pte_valid_user() should return true. Your assumption that this is about "old" pages being uncached is totally incorrect - there has never been such an assumption. > Especially for systems that do not have swap, the migrated pages are > unequivocally marked old. This presents a problem, as it is possible > for the original page to be immediately mapped to another VA that > happens to share the same cache index in VIPT I-cache (we found this > bug on Cortex-A9). Without cache invalidation, the CPU will see the > old mapping whose physical page can now be used for a different > purpose, as illustrated below: > > Core Physical Memory > +-------------------------------+ +------------------+ > | TLB | | | > | VA_A 0xb6e6f -> pfn_q | | pfn_q: code | > +-------------------------------+ +------------------+ > | I-cache | > | set[VA_A bits] | tag=pfn_q | > +-------------------------------+ > > migrate (kcompactd): > 1. copy pfn_q --> pfn_r > 2. free pfn_q > 3. pte: VA_a -> pfn_r > 4. pte_mkold(pte) --> !young > 5. ICIALLUIS skipped (because !young) At this point, the hardware PTE will be set to zero and the TLB invalidated. This _should_ mean that any future access should result in a page permission fault being raised. That will then provoke the MM to mark the PTE young, which will then result in set_ptes() being called, and thus __sync_icache_dcache() will be called for the _neew_ pte (which will be for pfn_r.) > > pfn_src reused (OOM pressure): > pte: VA_B -> pfn_q (different code) > > bug: > Core Physical Memory > +-------------------------------+ +------------------+ > | TLB (empty) | | pfn_r: old code | > +-------------------------------+ | pfn_q: new code | > | I-cache | +------------------+ > | set[VA_A bits] | tag=pfn_q |<--- wrong instructions > +-------------------------------+ > > This was verified on ba16-based board (i.MX6Quad/Dual, Cortex-A9) by > instrumenting the migration code to track recently migrated pages in a > ring buffer and then dumping them in the undefined instruction fault > handler. The bug can be triggered with `stress-ng': > > stress-ng --vm 4 --vm-bytes 2G --vm-method zero-one --verify > > Note that the system we tested on has only 2G of memory, so the test > triggered the OOM-killer in our case. So you're saying that stress-ng doesn't reproduce this bug but triggers the OOM-killer... confused. Cortex-A9 has been around for a long time - I have systems that still use Cortex-A9 every day without swap, and they have been rock solid. If there was a bug like this, I would've expected to see problems, but I'm not... so, I'm not convinced there's a problem here. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!