From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F2A6A262A6 for ; Sat, 11 Apr 2026 12:28:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775910504; cv=none; b=lpdnL2Ox8fXOxaeyqUNFSo3si0d2vMwP5UYe63ppXPKJMMygOKiAdlID9iuMUJ7rooevZRhEm3Ut89qTDEcYJy0JWsnLSypqqv02GS2cw7cp5Sr7inXboPV/Df92F4OOIwbvE2GmoXDBNjKN3NlShTzCE73DWGOQXHiQgRhaZss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775910504; c=relaxed/simple; bh=nozOev9WHbDiVo/T2vbw8ZAch3zN5+b2SfQTDC0Bj+g=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eyro6lU23XBxGdNd5KA9kuTrgqUkDPUWGq0jAS9ImZB1YMPAdjUZCfORG3xhJrfl8XRTuJd5hnp48v6rMxj/fEPy+0XVyNa7OJEXCqhxZ/Kb/qY1D+qEQ/ZYfoe56dCpyu36U4uk6nFLzkcQQlGwzltg21hnMXnxgsmdH1LcHvs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=q+jIRwqu; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q+jIRwqu" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2b2dca513c3so6485015ad.0 for ; Sat, 11 Apr 2026 05:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775910502; x=1776515302; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=mbqt5Qpb1Da8WzrSORfQC8GDoEFqa1MXloGMeTyaA0w=; b=q+jIRwqurB0cV1IDsi/6zluQUTaUz4vXVjAbMiUGvVjHhj953xJsxxaITfGPd2G88d f3kv06PzEw8I0Z8GZFBeNTNaQ+59eSDbmWxB79Y2V5+EYCCWZuv6zIgc4bYDOjcwW2OF bXBfKEJNaPWOie67gfQlRSIoFT5/RMr1HubfJ+HA00TN5QWEowbCUGJdldrBGn9E4mkv IpwicFbZ3VyIOQqB5+Cr8JBHO+RZyqGlKkgJCN71d+w/E9xsLHDyZfsRKbQQ7hnnnL+q LTmtYtowEjkyw+KdKipIQx7GmHuUsBQWywZ0CdLuJQePAl2RA/tMth8PyhU7rCUxxGiW QEHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775910502; x=1776515302; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mbqt5Qpb1Da8WzrSORfQC8GDoEFqa1MXloGMeTyaA0w=; b=WMPkxsEd3Yc997Dj/863mNNnBIUfZBd2fCpMWlggciuBRcS/QM4iw9Se/EvJkXIaXd iQxmzVV3TbN66Eh81Ppqt341XVc27h9he89x7HDmxUFIMv49wySaXY2oah2l+/wOU05d PM86DhIinjN7WDRw4r4T1dKWArALhju1Yo9W+B4fhzrV0WwwhbzSTRjWS036p009idrp eWciApXvKYWBalbkOOZrnJHCmI3A9xUGhY2kMLx6+O94DEXSoIn7nAvi5j3hKdJ3qhqM X89bC9MpkJlrRGYvmzXEXfiQu2uEHGATTQeKHeTHwhvTeJXevogfTIR1eHQwnJJUol/w SUWg== X-Forwarded-Encrypted: i=1; AJvYcCXmhneYMzk2eYKh4Iz0mCjbmJhIOMX1542jUQsr/PA4POskXcMMa5yiKRLeknodWeKgi+0qqebQV6Snq4U=@vger.kernel.org X-Gm-Message-State: AOJu0YwqzdQg1sTXfemwdxUEzl/ScVIrrxtyJknIwSMZYzABUpZ4uPw5 J7J/1DBdBKFmjIFuI9aBkSC/0VeGLf1fGY5ZRMZpifqJks9Y56fFLMZGad7zDS3T36o= X-Gm-Gg: AeBDieucwClfGNXgI02My52P2vCueO3yOYIdNFq8T3cBUYJy33dj1xtLcZDNiH2v/PJ //Xfp3GLxu2Y5D6wHONoAX7aB7VEouzQXSxB8WiWtIx6VGQq/dVqVTeXD06ag2IqvlFYXReetKV b739AeAxzgvINfwdAT8hCH1jC+Ce8qOhPJ6hY8NRwExVa9PEOOU5CgYNHWc2fFD8L3Ly7TogoR2 0S96rb/aufkCQahY/+a+FnOvQAToUKrVwH9iJFYiKQoismIWb33WpoKbtYO1iARlITw5gDkebWh 2rWrKQgFya0iIQTW2yEY0RWkjcIB6b1Ae0xmdCNrS8GPqzMc/ZEZ3dCBpbCvs7z892K9+9N31TI mOb9hNvu9Urhb0ZS8b0F77hJ/Xl7QQG6LvPxXhkdFs2F5BG5VN94V3ljseMJlUxWdCO2nfwd56V TAThujO8o+TOAHnY4VYMukqDCjh+yCM39EhHWnnTkhNQ3DPhruynWJ X-Received: by 2002:a17:902:d2c7:b0:2b0:5770:d484 with SMTP id d9443c01a7336-2b2d5a67389mr70973825ad.41.1775910502214; Sat, 11 Apr 2026 05:28:22 -0700 (PDT) Received: from udknight.localhost ([240e:379:1ea4:201:1d74:bf36:51db:2590]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b2d4f0ada5sm62470315ad.42.2026.04.11.05.28.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Apr 2026 05:28:21 -0700 (PDT) Received: from udknight.localhost (localhost [127.0.0.1]) by udknight.localhost (8.14.9/8.14.4) with ESMTP id 63BCS4Va011166; Sat, 11 Apr 2026 20:28:05 +0800 Received: (from root@localhost) by udknight.localhost (8.14.9/8.14.9/Submit) id 63BCRtY1011157; Sat, 11 Apr 2026 20:27:55 +0800 Date: Sat, 11 Apr 2026 20:27:55 +0800 From: Wang YanQing To: "Russell King (Oracle)" , akpm@linux-foundation.org, willy@infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] arm: lpae: fix non-atomic page table entry update issue Message-ID: <20260411122755.GA3274@udknight> Mail-Followup-To: Wang YanQing , "Russell King (Oracle)" , akpm@linux-foundation.org, willy@infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260315004746.GA32062@udknight> <20260315032950.GA5618@udknight> 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: <20260315032950.GA5618@udknight> User-Agent: Mutt/1.7.1 (2016-10-04) On Sun, Mar 15, 2026 at 11:29:50AM +0800, Wang YanQing wrote: > On Sun, Mar 15, 2026 at 01:12:28AM +0000, Russell King (Oracle) wrote: > > On Sun, Mar 15, 2026 at 08:47:46AM +0800, Wang YanQing wrote: > > Thanks. Now, please locate where the need for the updates to the page > > tables needs to be done atomically, bearing in mind that we program > > SCTLR.AFE=1 and SCTLR.HA=0, meaning the hardware won't write-back to > > the page tables to e.g. update the access flag. > > When LPAE is enabled and in the 3G/1G userspace & kernel space config, we > use ttbr0 for address space 0-3G, and use ttbr1 for top 1G kernel space, > but wait a moment, the module space is in ttbr0 instead of ttbr1, because > module space is belong to 0-3G. > > Then we don't switch ttbr0 to the same value as ttbr1 in task switch, so > when we switch from normal userspace thread to kernel thread, we use the > do_translation_fault() to fault in the module space for the kernel thread > when it accesses the module space. Now please think a situation that > userspace repeats create new short-lived processes (run shell cmds, etc), > we will use do_translation_fault() to fault in the PMD entries repeatly > when switch from new created process to running kernel thread, we need > to update pmd entry automatically here, hw is allowed to do data/instruction > preload and trigger page table walker to see the partial update pmd entry, > page table walker will cache it, and it will cause translation fault, > because it doesn't see the upper 32-bit. > > When the userspace process is a multi-threads process, in smp environment, > other cpus could use the same pgd for their according kernel thread, all > the page table walker of the smp cpus have the chance to cache the partial > update entry. > Hi Russell King, what is the status about this patch? On some SoC, Texas Instruments Keystone etc, it will run arm32 linux kernel on high address (KEYSTONE_HIGH_PHYS_START = 0x800000000ULL), then all the physical address of page table will be 64-bit and will meet the issue described in the patch Thanks