From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 A4DB31B7910 for ; Fri, 10 Jul 2026 00:59:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783645148; cv=none; b=gshf7rlKLttY33eLQ5qEoAoMsiHenLHB4KSXQSLdCWWapLXcLvzZLChdm43hKGgTWgqbT3zFnsygv+bDSVVsy3zk3Z0KPDF1AN8QC47U/HGpROtt8OmK2H2VBFyG8qDtYbuzMU2plIRPsv/qrsf8OMdexqDDTRzJbTEP1CpGup0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783645148; c=relaxed/simple; bh=Tp7LXlCkq0HZeGXSVsW6Skoyn+M1dcZEQWrNMW3vaM4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=Clhbj8fZ/v4De76kz+/RZiLTeh4rUNGdbegtW+UdcqruNMRmo4TjC5tsh2UWcP9TIe9dZIE3L4uKwm7t+nokIYNSc7W8kOsMfca/tvuOLME0FGBjkWuuJ8kVwStFFvC94UolIO9K4aDdYmW7NFy8VvjVZkCxVOB6Ri9lisbavyQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BffutR+j; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BffutR+j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09D151F00A3A; Fri, 10 Jul 2026 00:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783645147; bh=G+HtOVZhSA/XK6KhiOlTNBigwnMnYqdSliXWSDDRVpw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BffutR+j0EOnrb3k7FsSup/k58GyMGzYn8/7pnQxlvLyiYI79jlcfpjekjwZwpR7u C5VEpreEtCO9b3p8xl97QZHrrj2vFx9trPsBwxN71sdd+KqwTiRZrgGf7yDxWqU5AA RWYeoK13LvGGqz925qO2gQx4eSkA+tDSxvPHTYx4M8vim8NN8ES/bww6RDxttrW8R6 hLfplqCwONArfu+RZZc6P3aX2WP4/s5D6KOykHExjK34T7liXB7a7Uqqm8RCpb6yFs RxdQErtj5ZaFyuKo+QXVmN2dZjjQrRNrw5diKSoNc4nteAdCTb+zbkCWGoxhOVbXPz WbPTY97p1QCwQ== Date: Thu, 9 Jul 2026 18:59:04 -0600 (MDT) From: Paul Walmsley To: Vivian Wang cc: Paul Walmsley , Palmer Dabbelt , Alexandre Ghiti , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Yaxing Guo , "David Hildenbrand (Arm)" Subject: Re: [PATCH] riscv: mm: Fix concurrency in mark_new_valid_map() In-Reply-To: <20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn> Message-ID: <38dad5db-e298-fe26-2189-3a67ed156a4a@kernel.org> References: <20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn> 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 Hi Vivian, On Mon, 29 Jun 2026, Vivian Wang wrote: > Turns out, the concurrency concerns [1] were justified - BOSC reported a > spurious fault in KFENCE that still triggers despite previous fixes, > which KFENCE reports as a false-positive. > > Fix the concurrency problems in mark_new_valid_map(): > > - Add smp_wmb() before filling the bitmap, to make sure page table > writes are "received". Probably this expression should be clarified. I guess the intent here is to ensure that the page table write is visible by other cores either before or simultaneously with the bitmap fill? And the purpose of that is to avoid a situation where another core could execute an sfence.vma before the PTE write is observable by the other core? If so, we should probably write something like this out in the commit message. I wonder if there's still a window where spurious faults could be observed by kfence. If another core "B" faults (due to its local TLB caching an invalid PTE) after the PTE write is observable by B, but before the bitmap write is observable by B, core B won't sfence.vma. If this possibility still exists, we should probably document it. It might be possible to narrow that window further with a smp_mb() after the bitmap fill, but unclear that it's worth trying unless more spurious faults are seen. ... Also, now that we're adding an smp_wmb(), we should probably expand the preemption-disabled section in kfence_protect_page() to cover the entire function, to eliminate any risk that the PTE writes execute on a separate CPU from the smp_wmb(). - Paul