Re: [PATCH 2/2] x86/kmsan: Don't call instrumented code from kmsan_virt_addr_valid()

[Alexander Potapenko]

On Tue, Oct 6, 2026 at 8:10 PM Viorel Cernateanu via B4 Relay
<devnull+vrilutza.gmail.com@xxxxxxxxxx> wrote:
>
> From: Viorel Cernateanu <vrilutza@xxxxxxxxx>

CC Ilya, as s390 has a similar problem.

> With CONFIG_DEBUG_PREEMPT, a KMSAN kernel hangs silently right after
> KMSAN is enabled during boot.
>
> kmsan_virt_addr_valid() calls preempt_disable() and pfn_valid(), and
> pfn_valid() calls rcu_read_lock_sched(). With CONFIG_DEBUG_PREEMPT both
> end up in preempt_count_add(), which is instrumented. Its instrumentation
> looks up metadata, which calls kmsan_virt_addr_valid() again, and so on
> until the boot stack overflows.
>
> Use a copy of pfn_valid() that disables preemption with the notrace
> helpers instead. It is still an RCU-sched read-side critical section,
> and it avoids the instrumented preemption and RCU/lockdep helpers on
> this path.

Instead of forking pfn_valid(), can we factor out the non-locking part
from the original function?

        /* Caller must be in an RCU-sched read-side critical section. */
        static inline int __pfn_valid(unsigned long pfn) { ...body
minus RCU... }
        static inline int pfn_valid(unsigned long pfn)
        {
                int ret;
                rcu_read_lock_sched();
                ret = __pfn_valid(pfn);
                rcu_read_unlock_sched();
                return ret;
        }

Then we'll be able to call __pfn_valid() from KMSAN.