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 BC18542C516 for ; Wed, 29 Jul 2026 18:46:09 +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=1785350771; cv=none; b=LuFfU5DNxVuu11Ct4hrcSCtDcL6D8Y7DiD0XmEJ/zzg8zSk9Ak316M769GROsLgvk1BL1l+Fl3eSALBgLIPyIyTqyHLALGjfyZ3d/SNb7HGVubLyvBM+ZuwgYAPoS6BUnSBc2/jXWPg/iQfvBdxzcMmVGqUGjnKQfDY7U3XWKHo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785350771; c=relaxed/simple; bh=aNbqk/vPVEu3pgoECVHTRU3Zon45R1z4yZQz2uedKLY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=pCKSfztDuiAcyoDZaausXiNpX+ZEas8TzABYlsaY0/SXP21OF9KKgKytIjAFdbF5+prxupCROzmHW1rIx4k6PZpPsSqM1Yucmzpzmn+wPvYuykrPX1WmB9ZCPJqCrNqTBxA/yG67xH1kOzQai5bW7UImTpmDFqvSZwM+Nd8TSW8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NdnzlgCL; 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="NdnzlgCL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00D621F000E9; Wed, 29 Jul 2026 18:46:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785350768; bh=RhLSk2hQJz5q6KfzvE92gmJg46Byo4xNHsNZgnhqlek=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NdnzlgCLW6FM2+oYQ1nGDvf4auJGW2DlgMkjqdEeaeFaoECQQQ+rUYNNjy3/nRM/I 4QMhmia8S2jnJweuKcf7ap+544s2aNf9wvJMB/qudEu9OZ6MCjPtB0lb/ssmQHHd0i jE7G+W4epskBQVQ1RNUGK7WeRTN6cX25Ug/YBKk9EDX2vhtpNBxEnG/KTK+2Hs58qv pZ1d/5tR9tOVeCCfzvFGGokRpDT6ZH2z1F2b+WDxPaaMVjgDNQPBmA0eADgjLgfIdq 39yRNDT2r6uSSVYxTGszTgThmEVjJ+GARdXB6KSYCKRWnwRUxAe8ynQ7168y7CopsT yr1TYOEBxa0JQ== Date: Wed, 29 Jul 2026 12:46:07 -0600 (MDT) From: Paul Walmsley To: Paul Walmsley cc: Vivian Wang , 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: <38dad5db-e298-fe26-2189-3a67ed156a4a@kernel.org> Message-ID: <5de7e75a-c86c-18e0-b9f4-4d7ff56fe4bd@kernel.org> References: <20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn> <38dad5db-e298-fe26-2189-3a67ed156a4a@kernel.org> 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 Thu, 9 Jul 2026, Paul Walmsley wrote: > 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(). Are you planning to update this one? - Paul