Received-SPF: pass (google.com: domain of linux-kernel+bounces-30093-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240118110022.2538350-1-elver@google.com> <CANpmjNPx0j-x_SDu777gaV1oOFuPmHV3xFfru56UzBXHnZhYLg@mail.gmail.com>
 <cd742d1d-70a3-586b-4bf5-fcfc94c75b4a@quicinc.com>
In-Reply-To: <cd742d1d-70a3-586b-4bf5-fcfc94c75b4a@quicinc.com>
From: Marco Elver <elver@google.com>
Date: Thu, 18 Jan 2024 13:22:37 +0100
Message-ID: <CANpmjNNZ6vV7DJ+SBGcSnV6qzkmH_J=WrofrfaAeidvSG2nHbQ@mail.gmail.com>
Subject: Re: [PATCH] mm, kmsan: fix infinite recursion due to RCU critical section
To: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Alexander Potapenko <glider@google.com>, 
	Dmitry Vyukov <dvyukov@google.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, 
	linux-mm@kvack.org, syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com
Content-Type: text/plain; charset="UTF-8"

On Thu, 18 Jan 2024 at 12:28, Charan Teja Kalla
<quic_charante@quicinc.com> wrote:
>
> May I ask if KMSAN also instruments the access to the memory managed as
> ZONE_DEVICE. You know this is not the RAM and also these pages will
> never be onlined thus also not be available in buddy.
>
> Reason for the ask is that this patch is introduced because of a race
> between pfn walker ends up in pfn of zone device memory.
>
> If KMSAN never instruments this, does it look good to you to have the
> KMSAN version of pfn_valid(), as being suggested by Alexander in the
> other mail.

It would be nice to avoid duplicating functions - both options have downsides:
1. Shared pfn_valid(): it might break for KMSAN again in future if new
recursion is introduced.
2. KMSAN-version of pfn_valid(): it might break if pfn_valid() changes
in future.

I suspect #1 is less likely.

What is your main concern by switching to rcu_read_lock_sched()?