KVM: mmu_notifier: make mn_invalidate_lock non-sleeping for non-blocking invalidations

mmu_notifier_invalidate_range_start() may be invoked via mmu_notifier_invalidate_range_start_nonblock(), e.g. from oom_reaper(), where sleeping is explicitly forbidden.

KVM's mmu_notifier invalidate_range_start currently takes mn_invalidate_lock using spin_lock(). On PREEMPT_RT, spin_lock() maps to rt_mutex and may sleep, triggering:

  BUG: sleeping function called from invalid context

This violates the MMU notifier contract regardless of PREEMPT_RT; RT kernels merely make the issue deterministic.

Fix by converting mn_invalidate_lock to a raw spinlock so that invalidate_range_start() remains non-sleeping while preserving the existing serialization between invalidate_range_start() and invalidate_range_end().

Signed-off-by shaikh.kamal <[email protected]>

virt/kvm/kvm_main.c +1 -1

-	spin_unlock(&kvm->mn_invalidate_lock);
+	raw_spin_unlock(&kvm->mn_invalidate_lock);
 
 	/*
 	 * There can only be one waiter, since the wait happens under

@@ -1129,7 +1129,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)

@@ -1635,17 +1635,17 @@ static void kvm_swap_active_memslots(struct kvm *kvm, int as_id)
 	 * progress, otherwise the locking in invalidate_range_start and

Quoted 4 lines · shaikh.kamal

mmu_notifier_invalidate_range_start() may be invoked via mmu_notifier_invalidate_range_start_nonblock(), e.g. from oom_reaper(), where sleeping is explicitly forbidden.

Quoted 7 lines

KVM's mmu_notifier invalidate_range_start currently takes mn_invalidate_lock using spin_lock(). On PREEMPT_RT, spin_lock() maps to rt_mutex and may sleep, triggering:

  BUG: sleeping function called from invalid context

This violates the MMU notifier contract regardless of PREEMPT_RT;

Quoted 1 line

RT kernels merely make the issue deterministic.

Quoted 4 lines

Fix by converting mn_invalidate_lock to a raw spinlock so that invalidate_range_start() remains non-sleeping while preserving the existing serialization between invalidate_range_start() and invalidate_range_end().

virt/kvm/kvm_main.c static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn, · line 752

Quoted 13 lines

virt/kvm/kvm_main.c +2 -2

index 5fcd401a5897..7a9c33f01a37 100644
@@ -747,9 +747,9 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 	 *
 	 * Pairs with the decrement in range_end().
 	 */
-	spin_lock(&kvm->mn_invalidate_lock);
+	raw_spin_lock(&kvm->mn_invalidate_lock);
 	kvm->mn_active_invalidate_count++;
-	spin_unlock(&kvm->mn_invalidate_lock);
+	raw_spin_unlock(&kvm->mn_invalidate_lock);

atomic_inc(mn_active_invalidate_count)

virt/kvm/kvm_main.c static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn, · line 823

Quoted 12 lines

virt/kvm/kvm_main.c +1 -1

 	/*
 	 * Invalidate pfn caches _before_ invalidating the secondary MMUs, i.e.

@@ -817,11 +817,11 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
 	kvm_handle_hva_range(kvm, &hva_range);
 
 	/* Pairs with the increment in range_start(). */
-	spin_lock(&kvm->mn_invalidate_lock);
+	raw_spin_lock(&kvm->mn_invalidate_lock);
 	if (!WARN_ON_ONCE(!kvm->mn_active_invalidate_count))
 		--kvm->mn_active_invalidate_count;
 	wake = !kvm->mn_active_invalidate_count;

	wake = atomic_dec_return_safe(mn_active_invalidate_count);
	WARN_ON_ONCE(wake < 0);
	wake = !wake;

Quoted 16 lines

virt/kvm/kvm_main.c +2 -3

-	spin_unlock(&kvm->mn_invalidate_lock);
+	raw_spin_unlock(&kvm->mn_invalidate_lock);
 
 	/*
 	 * There can only be one waiter, since the wait happens under

@@ -1129,7 +1129,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)

@@ -1635,17 +1635,17 @@ static void kvm_swap_active_memslots(struct kvm *kvm, int as_id)
 	 * progress, otherwise the locking in invalidate_range_start and
 	 * invalidate_range_end will be unbalanced.
 	 */
-	spin_lock(&kvm->mn_invalidate_lock);
+	raw_spin_lock(&kvm->mn_invalidate_lock);
 	prepare_to_rcuwait(&kvm->mn_memslots_update_rcuwait);
 	while (kvm->mn_active_invalidate_count) {
 		set_current_state(TASK_UNINTERRUPTIBLE);
-		spin_unlock(&kvm->mn_invalidate_lock);

virt/kvm/kvm_main.c static void kvm_swap_active_memslots(struct kvm *kvm, int as_id) · line 1643

Quoted 2 lines

virt/kvm/kvm_main.c +1 -0

+		raw_spin_unlock(&kvm->mn_invalidate_lock);
 		schedule();

And this I don't understand. The lock protects the rcuwait assignment which would be needed if multiple waiters are possible. But this goes away after the unlock and schedule() here. So these things could be moved outside of the locked section which limits it only to the mn_active_invalidate_count value.

Quoted 5 lines · Sebastian Andrzej Siewior

Quoted 4 lines · shaikh.kamal

mmu_notifier_invalidate_range_start() may be invoked via mmu_notifier_invalidate_range_start_nonblock(), e.g. from oom_reaper(), where sleeping is explicitly forbidden.

Quoted 7 lines

Quoted 7 lines

KVM's mmu_notifier invalidate_range_start currently takes mn_invalidate_lock using spin_lock(). On PREEMPT_RT, spin_lock() maps to rt_mutex and may sleep, triggering:

  BUG: sleeping function called from invalid context

This violates the MMU notifier contract regardless of PREEMPT_RT;

I highly doubt that. kvm.mmu_lock is also a spinlock, and KVM has been taking that in invalidate_range_start() since

e930bffe95e1 ("KVM: Synchronize guest physical memory map to host virtual memory map")

which was a full decade before mmu_notifiers even added the blockable concept in

93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")

and even predate the current concept of a "raw" spinlock introduced by

c2f21ce2e312 ("locking: Implement new raw_spinlock")

Quoted 1 line

Quoted 1 line

RT kernels merely make the issue deterministic.

No, RT kernels change the rules, because suddenly a non-sleeping locking becomes sleepable.

Quoted 4 lines

Quoted 4 lines

Fix by converting mn_invalidate_lock to a raw spinlock so that invalidate_range_start() remains non-sleeping while preserving the existing serialization between invalidate_range_start() and invalidate_range_end().

This is insufficient. To actually "fix" this in KVM mmu_lock would need to be turned into a raw lock on all KVM architectures. I suspect the only reason there haven't been bug reports is because no one trips an OOM kill on VM while running with CONFIG_DEBUG_ATOMIC_SLEEP=y.

That combination is required because since commit

8931a454aea0 ("KVM: Take mmu_lock when handling MMU notifier iff the hva hits a memslot")

KVM only acquires mmu_lock if the to-be-invalidated range overlaps a memslot, i.e. affects memory that may be mapped into the guest.

E.g. this hack to simulate a non-blockable invalidation

virt/kvm/kvm_main.c +3 -1

index 7015edce5bd8..7a35a83420ec 100644
@@ -739,7 +739,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
                .handler        = kvm_mmu_unmap_gfn_range,
                .on_lock        = kvm_mmu_invalidate_begin,
                .flush_on_ret   = true,
-               .may_block      = mmu_notifier_range_blockable(range),
+               .may_block      = false,//mmu_notifier_range_blockable(range),
        };
 
        trace_kvm_unmap_hva_range(range->start, range->end);

@@ -768,6 +768,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
         */
        gfn_to_pfn_cache_invalidate_start(kvm, range->start, range->end);
 
+       non_block_start();
        /*
         * If one or more memslots were found and thus zapped, notify arch code
         * that guest memory has been reclaimed.  This needs to be done *after*

@@ -775,6 +776,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
         */
        if (kvm_handle_hva_range(kvm, &hva_range).found_memslot)
                kvm_arch_guest_memory_reclaimed(kvm);
+       non_block_end();
 
        return 0;
 }

immediately triggers

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:241
  in_atomic(): 0, irqs_disabled(): 0, non_block: 1, pid: 4992, name: qemu
  preempt_count: 0, expected: 0
  RCU nest depth: 0, expected: 0
  CPU: 6 UID: 1000 PID: 4992 Comm: qemu Not tainted 6.19.0-rc6-4d0917ffc392-x86_enter_mmio_stack_uaf_no_null-rt #1 PREEMPT_RT 
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   <TASK>
   dump_stack_lvl+0x51/0x60
   __might_resched+0x10e/0x160
   rt_write_lock+0x49/0x310
   kvm_mmu_notifier_invalidate_range_start+0x10b/0x390 [kvm]
   __mmu_notifier_invalidate_range_start+0x9b/0x230
   do_wp_page+0xce1/0xf30
   __handle_mm_fault+0x380/0x3a0
   handle_mm_fault+0xde/0x290
   __get_user_pages+0x20d/0xbe0
   get_user_pages_unlocked+0xf6/0x340
   hva_to_pfn+0x295/0x420 [kvm]
   __kvm_faultin_pfn+0x5d/0x90 [kvm]
   kvm_mmu_faultin_pfn+0x31b/0x6e0 [kvm]
   kvm_tdp_page_fault+0xb6/0x160 [kvm]
   kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]
   kvm_mmu_page_fault+0x8d/0x600 [kvm]
   vmx_handle_exit+0x18c/0x5a0 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0xc70/0x1c90 [kvm]
   kvm_vcpu_ioctl+0x2d7/0x9a0 [kvm]
   __x64_sys_ioctl+0x8a/0xd0
   do_syscall_64+0x5e/0x11b0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   </TASK>
  kvm: emulating exchange as write

It's not at all clear to me that switching mmu_lock to a raw lock would be a net positive for PREEMPT_RT. OOM-killing a KVM guest in a PREEMPT_RT seems like a comically rare scenario. Whereas contending mmu_lock in normal operation is relatively common (assuming there are even use cases for running VMs with a PREEMPT_RT host kernel).

In fact, the only reason the splat happens is because mmu_notifiers somewhat artificially forces an atomic context via non_block_start() since commit

ba170f76b69d ("mm, notifier: Catch sleeping/blocking for !blockable")

Given the massive amount of churn in KVM that would be required to fully eliminate the splat, and that it's not at all obvious that it would be a good change overall, at least for now:

NAK

I'm not fundamentally opposed to such a change, but there needs to be a _lot_ more analysis and justification beyond "fix CONFIG_DEBUG_ATOMIC_SLEEP=y".

Quoted 48 lines

virt/kvm/kvm_main.c static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn, · line 752

Quoted 13 lines

virt/kvm/kvm_main.c +2 -2

index 5fcd401a5897..7a9c33f01a37 100644
@@ -747,9 +747,9 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 	 *
 	 * Pairs with the decrement in range_end().
 	 */
-	spin_lock(&kvm->mn_invalidate_lock);
+	raw_spin_lock(&kvm->mn_invalidate_lock);
 	kvm->mn_active_invalidate_count++;
-	spin_unlock(&kvm->mn_invalidate_lock);
+	raw_spin_unlock(&kvm->mn_invalidate_lock);

atomic_inc(mn_active_invalidate_count)

virt/kvm/kvm_main.c static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn, · line 823

Quoted 12 lines

virt/kvm/kvm_main.c +1 -1

 	/*
 	 * Invalidate pfn caches _before_ invalidating the secondary MMUs, i.e.

@@ -817,11 +817,11 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
 	kvm_handle_hva_range(kvm, &hva_range);
 
 	/* Pairs with the increment in range_start(). */
-	spin_lock(&kvm->mn_invalidate_lock);
+	raw_spin_lock(&kvm->mn_invalidate_lock);
 	if (!WARN_ON_ONCE(!kvm->mn_active_invalidate_count))
 		--kvm->mn_active_invalidate_count;
 	wake = !kvm->mn_active_invalidate_count;

	wake = atomic_dec_return_safe(mn_active_invalidate_count);
	WARN_ON_ONCE(wake < 0);
	wake = !wake;

Quoted 16 lines

virt/kvm/kvm_main.c +2 -3

-	spin_unlock(&kvm->mn_invalidate_lock);
+	raw_spin_unlock(&kvm->mn_invalidate_lock);
 
 	/*
 	 * There can only be one waiter, since the wait happens under

@@ -1129,7 +1129,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)

@@ -1635,17 +1635,17 @@ static void kvm_swap_active_memslots(struct kvm *kvm, int as_id)
 	 * progress, otherwise the locking in invalidate_range_start and
 	 * invalidate_range_end will be unbalanced.
 	 */
-	spin_lock(&kvm->mn_invalidate_lock);
+	raw_spin_lock(&kvm->mn_invalidate_lock);
 	prepare_to_rcuwait(&kvm->mn_memslots_update_rcuwait);
 	while (kvm->mn_active_invalidate_count) {
 		set_current_state(TASK_UNINTERRUPTIBLE);
-		spin_unlock(&kvm->mn_invalidate_lock);

Quoted 8 lines

virt/kvm/kvm_main.c static void kvm_swap_active_memslots(struct kvm *kvm, int as_id) · line 1643

Quoted 2 lines

virt/kvm/kvm_main.c +1 -0

+		raw_spin_unlock(&kvm->mn_invalidate_lock);
 		schedule();

And this I don't understand. The lock protects the rcuwait assignment which would be needed if multiple waiters are possible. But this goes away after the unlock and schedule() here. So these things could be moved outside of the locked section which limits it only to the mn_active_invalidate_count value.

The implementation is essentially a deliberately unfair rwswem. The "write" side in kvm_swap_active_memslots() subtly protect this code:

  rcu_assign_pointer(kvm->memslots[as_id], slots);

and the "read" side protects the kvm->memslot lookups in kvm_handle_hva_range().

KVM optimizes its mmu_notifier invalidation path to only take action if the to-be-invalidated range overlaps one or more memslots, i.e. affects memory that be can be mapped into the guest. The wrinkle with those optimizations is that KVM needs to prevent changes to the memslots between invalidation start() and end(), otherwise the accounting can become imbalanced, e.g. mmu_invalidate_in_progress will underflow or be left elevated and essentially hang the VM (among other bad things).

So simply making mn_active_invalidate_count an atomic won't suffice, because KVM needs to block start() to ensure start()+end() see the exact same set of memslots.

Quoted 12 lines · Sean Christopherson

On Wed, Feb 11, 2026, Sebastian Andrzej Siewior wrote:
It's not at all clear to me that switching mmu_lock to a raw lock would be a net positive for PREEMPT_RT. OOM-killing a KVM guest in a PREEMPT_RT seems like a comically rare scenario. Whereas contending mmu_lock in normal operation is relatively common (assuming there are even use cases for running VMs with a PREEMPT_RT host kernel).

In fact, the only reason the splat happens is because mmu_notifiers somewhat artificially forces an atomic context via non_block_start() since commit

ba170f76b69d ("mm, notifier: Catch sleeping/blocking for !blockable")

Quoted 9 lines

Given the massive amount of churn in KVM that would be required to fully eliminate the splat, and that it's not at all obvious that it would be a good change overall, at least for now:

NAK

I'm not fundamentally opposed to such a change, but there needs to be a _lot_ more analysis and justification beyond "fix CONFIG_DEBUG_ATOMIC_SLEEP=y".

Hi Sean,
Thanks for the detailed explanation and for spelling out the border issue.
Understood on both points:
1. The changelog wording was too strong; PREEMPT_RT changes spin_lock() semantics, and the splat is fundamentally due to spinlocks becoming sleepable there.
2. Converting only mm_invalidate_lock to raw is insufficient since KVM can still take the mmu_lock (and other sleeping locks

RT) in invalidate_range_start() when the invalidation hits a memslot.
Given the above, it shounds like "convert locks to raw" is not the right direction without sinificat rework and justification.
Would an acceptable direction be to handle the !blockable notifier case by deferring the heavyweight invalidation work(anything that take mmu_lock/may sleep on RT) to a context that may block(e.g. queued work), while keeping start()/end() accounting consisting with memslot changes ?

Quoted 128 lines · Sean Christopherson

Quoted 5 lines · Sebastian Andrzej Siewior

Quoted 4 lines · shaikh.kamal

mmu_notifier_invalidate_range_start() may be invoked via mmu_notifier_invalidate_range_start_nonblock(), e.g. from oom_reaper(), where sleeping is explicitly forbidden.

Quoted 7 lines

Quoted 7 lines

KVM's mmu_notifier invalidate_range_start currently takes mn_invalidate_lock using spin_lock(). On PREEMPT_RT, spin_lock() maps to rt_mutex and may sleep, triggering:

   BUG: sleeping function called from invalid context

This violates the MMU notifier contract regardless of PREEMPT_RT;

I highly doubt that. kvm.mmu_lock is also a spinlock, and KVM has been taking that in invalidate_range_start() since

e930bffe95e1 ("KVM: Synchronize guest physical memory map to host virtual memory map")

which was a full decade before mmu_notifiers even added the blockable concept in

93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")

and even predate the current concept of a "raw" spinlock introduced by

c2f21ce2e312 ("locking: Implement new raw_spinlock")

Quoted 1 line

Quoted 1 line

RT kernels merely make the issue deterministic.

No, RT kernels change the rules, because suddenly a non-sleeping locking becomes sleepable.

Quoted 4 lines

Quoted 4 lines

Fix by converting mn_invalidate_lock to a raw spinlock so that invalidate_range_start() remains non-sleeping while preserving the existing serialization between invalidate_range_start() and invalidate_range_end().

This is insufficient. To actually "fix" this in KVM mmu_lock would need to be turned into a raw lock on all KVM architectures. I suspect the only reason there haven't been bug reports is because no one trips an OOM kill on VM while running with CONFIG_DEBUG_ATOMIC_SLEEP=y.

That combination is required because since commit

8931a454aea0 ("KVM: Take mmu_lock when handling MMU notifier iff the hva hits a memslot")

KVM only acquires mmu_lock if the to-be-invalidated range overlaps a memslot, i.e. affects memory that may be mapped into the guest.

E.g. this hack to simulate a non-blockable invalidation

virt/kvm/kvm_main.c +3 -1

index 7015edce5bd8..7a35a83420ec 100644
@@ -739,7 +739,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
                 .handler        = kvm_mmu_unmap_gfn_range,
                 .on_lock        = kvm_mmu_invalidate_begin,
                 .flush_on_ret   = true,
-               .may_block      = mmu_notifier_range_blockable(range),
+               .may_block      = false,//mmu_notifier_range_blockable(range),
         };
 
         trace_kvm_unmap_hva_range(range->start, range->end);

@@ -768,6 +768,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
          */
         gfn_to_pfn_cache_invalidate_start(kvm, range->start, range->end);
 
+       non_block_start();
         /*
          * If one or more memslots were found and thus zapped, notify arch code
          * that guest memory has been reclaimed.  This needs to be done *after*

@@ -775,6 +776,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
          */
         if (kvm_handle_hva_range(kvm, &hva_range).found_memslot)
                 kvm_arch_guest_memory_reclaimed(kvm);
+       non_block_end();
 
         return 0;
  }

immediately triggers

   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:241
   in_atomic(): 0, irqs_disabled(): 0, non_block: 1, pid: 4992, name: qemu
   preempt_count: 0, expected: 0
   RCU nest depth: 0, expected: 0
   CPU: 6 UID: 1000 PID: 4992 Comm: qemu Not tainted 6.19.0-rc6-4d0917ffc392-x86_enter_mmio_stack_uaf_no_null-rt #1 PREEMPT_RT
   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
   Call Trace:
    <TASK>
    dump_stack_lvl+0x51/0x60
    __might_resched+0x10e/0x160
    rt_write_lock+0x49/0x310
    kvm_mmu_notifier_invalidate_range_start+0x10b/0x390 [kvm]
    __mmu_notifier_invalidate_range_start+0x9b/0x230
    do_wp_page+0xce1/0xf30
    __handle_mm_fault+0x380/0x3a0
    handle_mm_fault+0xde/0x290
    __get_user_pages+0x20d/0xbe0
    get_user_pages_unlocked+0xf6/0x340
    hva_to_pfn+0x295/0x420 [kvm]
    __kvm_faultin_pfn+0x5d/0x90 [kvm]
    kvm_mmu_faultin_pfn+0x31b/0x6e0 [kvm]
    kvm_tdp_page_fault+0xb6/0x160 [kvm]
    kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]
    kvm_mmu_page_fault+0x8d/0x600 [kvm]
    vmx_handle_exit+0x18c/0x5a0 [kvm_intel]
    kvm_arch_vcpu_ioctl_run+0xc70/0x1c90 [kvm]
    kvm_vcpu_ioctl+0x2d7/0x9a0 [kvm]
    __x64_sys_ioctl+0x8a/0xd0
    do_syscall_64+0x5e/0x11b0
    entry_SYSCALL_64_after_hwframe+0x4b/0x53
    </TASK>
   kvm: emulating exchange as write

It's not at all clear to me that switching mmu_lock to a raw lock would be a net positive for PREEMPT_RT. OOM-killing a KVM guest in a PREEMPT_RT seems like a comically rare scenario. Whereas contending mmu_lock in normal operation is relatively common (assuming there are even use cases for running VMs with a PREEMPT_RT host kernel).

In fact, the only reason the splat happens is because mmu_notifiers somewhat artificially forces an atomic context via non_block_start() since commit

ba170f76b69d ("mm, notifier: Catch sleeping/blocking for !blockable")

Quoted 9 lines

Given the massive amount of churn in KVM that would be required to fully eliminate the splat, and that it's not at all obvious that it would be a good change overall, at least for now:

NAK

I'm not fundamentally opposed to such a change, but there needs to be a _lot_ more analysis and justification beyond "fix CONFIG_DEBUG_ATOMIC_SLEEP=y".

Hi Sean,
Thanks for the detailed explanation and for spelling out the border issue.
Understood on both points:
1. The changelog wording was too strong; PREEMPT_RT changes spin_lock() semantics, and the splat is fundamentally due to spinlocks becoming sleepable there.
2. Converting only mm_invalidate_lock to raw is insufficient since KVM can still take the mmu_lock (and other sleeping locks RT) in invalidate_range_start() when the invalidation hits a memslot.
Given the above, it shounds like "convert locks to raw" is not the right direction without sinificat rework and justification.
Would an acceptable direction be to handle the !blockable notifier case by deferring the heavyweight invalidation work(anything that take mmu_lock/may sleep on RT) to a context that may block(e.g. queued work), while keeping start()/end() accounting consisting with memslot changes ? if so, I can protoptype a patch along those lines and share for feedback.

Alternatively, if you think this needs to be addressed in mmu_notifiers(eg. how non_block_start() is applied), I'm happy to redirect my efforts there-Please advise.

Quoted 155 lines · shaikh kamaluddin

Quoted 125 lines · Sean Christopherson

Quoted 5 lines · Sebastian Andrzej Siewior

Quoted 4 lines · shaikh.kamal

mmu_notifier_invalidate_range_start() may be invoked via mmu_notifier_invalidate_range_start_nonblock(), e.g. from oom_reaper(), where sleeping is explicitly forbidden.

Quoted 7 lines

Quoted 7 lines

KVM's mmu_notifier invalidate_range_start currently takes mn_invalidate_lock using spin_lock(). On PREEMPT_RT, spin_lock() maps to rt_mutex and may sleep, triggering:

   BUG: sleeping function called from invalid context

This violates the MMU notifier contract regardless of PREEMPT_RT;

I highly doubt that. kvm.mmu_lock is also a spinlock, and KVM has been taking that in invalidate_range_start() since

e930bffe95e1 ("KVM: Synchronize guest physical memory map to host virtual memory map")

which was a full decade before mmu_notifiers even added the blockable concept in

93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")

and even predate the current concept of a "raw" spinlock introduced by

c2f21ce2e312 ("locking: Implement new raw_spinlock")

Quoted 1 line

Quoted 1 line

RT kernels merely make the issue deterministic.

No, RT kernels change the rules, because suddenly a non-sleeping locking becomes sleepable.

Quoted 4 lines

Quoted 4 lines

Fix by converting mn_invalidate_lock to a raw spinlock so that invalidate_range_start() remains non-sleeping while preserving the existing serialization between invalidate_range_start() and invalidate_range_end().

This is insufficient. To actually "fix" this in KVM mmu_lock would need to be turned into a raw lock on all KVM architectures. I suspect the only reason there haven't been bug reports is because no one trips an OOM kill on VM while running with CONFIG_DEBUG_ATOMIC_SLEEP=y.

That combination is required because since commit

8931a454aea0 ("KVM: Take mmu_lock when handling MMU notifier iff the hva hits a memslot")

KVM only acquires mmu_lock if the to-be-invalidated range overlaps a memslot, i.e. affects memory that may be mapped into the guest.

E.g. this hack to simulate a non-blockable invalidation

virt/kvm/kvm_main.c +3 -1

index 7015edce5bd8..7a35a83420ec 100644
@@ -739,7 +739,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
                 .handler        = kvm_mmu_unmap_gfn_range,
                 .on_lock        = kvm_mmu_invalidate_begin,
                 .flush_on_ret   = true,
-               .may_block      = mmu_notifier_range_blockable(range),
+               .may_block      = false,//mmu_notifier_range_blockable(range),
         };
         trace_kvm_unmap_hva_range(range->start, range->end);

@@ -768,6 +768,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
          */
         gfn_to_pfn_cache_invalidate_start(kvm, range->start, range->end);
+       non_block_start();
         /*
          * If one or more memslots were found and thus zapped, notify arch code
          * that guest memory has been reclaimed.  This needs to be done *after*

@@ -775,6 +776,7 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
          */
         if (kvm_handle_hva_range(kvm, &hva_range).found_memslot)
                 kvm_arch_guest_memory_reclaimed(kvm);
+       non_block_end();
         return 0;
  }
 

immediately triggers

   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:241
   in_atomic(): 0, irqs_disabled(): 0, non_block: 1, pid: 4992, name: qemu
   preempt_count: 0, expected: 0
   RCU nest depth: 0, expected: 0
   CPU: 6 UID: 1000 PID: 4992 Comm: qemu Not tainted 6.19.0-rc6-4d0917ffc392-x86_enter_mmio_stack_uaf_no_null-rt #1 PREEMPT_RT
   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
   Call Trace:
    <TASK>
    dump_stack_lvl+0x51/0x60
    __might_resched+0x10e/0x160
    rt_write_lock+0x49/0x310
    kvm_mmu_notifier_invalidate_range_start+0x10b/0x390 [kvm]
    __mmu_notifier_invalidate_range_start+0x9b/0x230
    do_wp_page+0xce1/0xf30
    __handle_mm_fault+0x380/0x3a0
    handle_mm_fault+0xde/0x290
    __get_user_pages+0x20d/0xbe0
    get_user_pages_unlocked+0xf6/0x340
    hva_to_pfn+0x295/0x420 [kvm]
    __kvm_faultin_pfn+0x5d/0x90 [kvm]
    kvm_mmu_faultin_pfn+0x31b/0x6e0 [kvm]
    kvm_tdp_page_fault+0xb6/0x160 [kvm]
    kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]
    kvm_mmu_page_fault+0x8d/0x600 [kvm]
    vmx_handle_exit+0x18c/0x5a0 [kvm_intel]
    kvm_arch_vcpu_ioctl_run+0xc70/0x1c90 [kvm]
    kvm_vcpu_ioctl+0x2d7/0x9a0 [kvm]
    __x64_sys_ioctl+0x8a/0xd0
    do_syscall_64+0x5e/0x11b0
    entry_SYSCALL_64_after_hwframe+0x4b/0x53
    </TASK>
   kvm: emulating exchange as write

It's not at all clear to me that switching mmu_lock to a raw lock would be a net positive for PREEMPT_RT. OOM-killing a KVM guest in a PREEMPT_RT seems like a comically rare scenario. Whereas contending mmu_lock in normal operation is relatively common (assuming there are even use cases for running VMs with a PREEMPT_RT host kernel).

In fact, the only reason the splat happens is because mmu_notifiers somewhat artificially forces an atomic context via non_block_start() since commit

ba170f76b69d ("mm, notifier: Catch sleeping/blocking for !blockable")

Quoted 9 lines

Given the massive amount of churn in KVM that would be required to fully eliminate the splat, and that it's not at all obvious that it would be a good change overall, at least for now:

NAK

I'm not fundamentally opposed to such a change, but there needs to be a _lot_ more analysis and justification beyond "fix CONFIG_DEBUG_ATOMIC_SLEEP=y".

Hi Sean,
Thanks for the detailed explanation and for spelling out the border issue.
Understood on both points:
1. The changelog wording was too strong; PREEMPT_RT changes spin_lock() semantics, and the splat is fundamentally due to spinlocks becoming sleepable there.
2. Converting only mm_invalidate_lock to raw is insufficient since KVM can still take the mmu_lock (and other sleeping locks RT) in invalidate_range_start() when the invalidation hits a memslot.
Given the above, it shounds like "convert locks to raw" is not the right direction without sinificat rework and justification.
Would an acceptable direction be to handle the !blockable notifier case by deferring the heavyweight invalidation work(anything that take mmu_lock/may sleep on RT) to a context that may block(e.g. queued work), while keeping start()/end() accounting consisting with memslot changes ? if so, I can protoptype a patch along those lines and share for feedback.

Quoted 3 lines

Alternatively, if you think this needs to be addressed in mmu_notifiers(eg. how non_block_start() is applied), I'm happy to redirect my efforts there-Please advise.

Have you considered a "OOM entered" callback for MMU notifiers? KVM's MMU notifier can just remove itself for example, in fact there is code in kvm_destroy_vm() to do that even if invalidations are unbalanced.

Paolo

Quoted 8 lines

Quoted 3 lines

Alternatively, if you think this needs to be addressed in mmu_notifiers(eg. how non_block_start() is applied), I'm happy to redirect my efforts there-Please advise.

Have you considered a "OOM entered" callback for MMU notifiers? KVM's MMU notifier can just remove itself for example, in fact there is code in kvm_destroy_vm() to do that even if invalidations are unbalanced.

Quoted 2 lines

Paolo

Thanks for the suggestion! That's a much cleaner approach than what I was considering.

If I understand correctly, the idea would be:
1. Add a new MMU notifier callback (e.g., .oom_entered or .release_on_oom)
2. Have KVM implement it to unregister the notifier when OOM reaper starts
3. Leverage the existing kvm_destroy_vm() logic that already handles unbalanced invalidations

This avoids the whole "convert locks to raw" problem and the complexity of deferring work.

I have questions on Testing part:
------------------------------------
I tried to reproduce the bug scenario using the virtme-ng then running
the stress-ng putting memory pressure on VM, but not able to reproduce
the scenario.
I tried this way ..
vng -v -r ./arch/x86/boot/bzImage
VM is up, then running the stress-ng as below
stress-ng --vm 2 --vm-bytes 95% --timeout 20s & sleep 5 & dmesg | tail -30 | grep "sleeping function" OOM Killer is triggered, but exact bug not able to reproduce, Please
suggest how to reproduce this bug, even we need to verify after code
changes which you have suggested.

Quoted 12 lines · shaikh kamaluddin

Quoted 10 lines

Quoted 3 lines

Alternatively, if you think this needs to be addressed in mmu_notifiers(eg. how non_block_start() is applied), I'm happy to redirect my efforts there-Please advise.

Have you considered a "OOM entered" callback for MMU notifiers? KVM's MMU notifier can just remove itself for example, in fact there is code in kvm_destroy_vm() to do that even if invalidations are unbalanced.

Paolo

Thanks for the suggestion! That's a much cleaner approach than what I was considering.

Quoted 4 lines

If I understand correctly, the idea would be:
1. Add a new MMU notifier callback (e.g., .oom_entered or .release_on_oom)
2. Have KVM implement it to unregister the notifier when OOM reaper starts
3. Leverage the existing kvm_destroy_vm() logic that already handles unbalanced invalidations

Yes pretty much. Essentially, move the existing logic to the new callback and invoke it from kvm_destroy_vm().

Quoted 14 lines

This avoids the whole "convert locks to raw" problem and the complexity of deferring work.

I have questions on Testing part:
------------------------------------
I tried to reproduce the bug scenario using the virtme-ng then running
the stress-ng putting memory pressure on VM, but not able to reproduce
the scenario.
I tried this way ..
vng -v -r ./arch/x86/boot/bzImage
VM is up, then running the stress-ng as below
stress-ng --vm 2 --vm-bytes 95% --timeout 20s & sleep 5 & dmesg | tail -30 | grep "sleeping function" OOM Killer is triggered, but exact bug not able to reproduce, Please
suggest how to reproduce this bug, even we need to verify after code
changes which you have suggested.

I don't know, sorry. But with this new approach there will always be a call to the new callback from the OOM killer, so it's easier to test.

Thanks,

Paolo

1. Added oom_enter callback to struct mmu_notifier_ops in include/linux/mmu_notifier.h
2. Implemented __mmu_notifier_oom_enter() in mm/mmu_notifier.c to invoke registered callbacks
3. Called mmu_notifier_oom_enter(mm) from __oom_kill_process in mm/oom_kill.c before any invalidations
4. As per your suggestion, move existing kvm_destroy_vm() logic that already handles unbalanced invalidation to the new helper function kvm_mmu_notifier_detach() and invoke it from the kvm_destroy_vm()

Key Design Decision:
------------------------------
Implementation point no 4, while testing, Issue I was encountering is a recursive locking problem with the srcu lock, which is being acquired twice in the same context. This happens during the __mmu_notifier_oom_enter() and __synchronize_srcu() calls, leading to a potential deadlock. Please find below log snippet while launching the Guest VM

Il mer 25 mar 2026, 06:19 shaikh kamaluddin
<[email protected]> ha scritto:

Quoted 5 lines

1. Added oom_enter callback to struct mmu_notifier_ops in include/linux/mmu_notifier.h
2. Implemented __mmu_notifier_oom_enter() in mm/mmu_notifier.c to invoke registered callbacks
3. Called mmu_notifier_oom_enter(mm) from __oom_kill_process in mm/oom_kill.c before any invalidations
4. As per your suggestion, move existing kvm_destroy_vm() logic that already handles unbalanced invalidation to the new helper function kvm_mmu_notifier_detach() and invoke it from the kvm_destroy_vm()

This is not fully clear to me... It could be caused by a recursive locking, or also a false positive. It's hard to say without seeing the full backtrace, but seeing "lock(srcu)" is suspicious.

I wouldn't have expected deferral to be necessary; and it seems to me that, if you defer removal to some time after the OOM reaper starts, you'd have the same problem as before with sleeping spinlocks.

Can you post the original patch without deferral?

Paolo

Quoted 5 lines

Key Design Decision:
------------------------------
Implementation point no 4, while testing, Issue I was encountering is a recursive locking problem with the srcu lock, which is being acquired twice in the same context. This happens during the __mmu_notifier_oom_enter() and __synchronize_srcu() calls, leading to a potential deadlock. Please find below log snippet while launching the Guest VM

(quoted diff) +8 -0

+void __mmu_notifier_oom_enter(struct mm_struct *mm)
+{
+       struct mmu_notifier *subscription;
+       int id;
+       pr_info("Entering :func:%s\n", __func__);
+       if (!mm->notifier_subscriptions)
+               return;
+

This series implements the after_oom_unregister callback design proposed by Paolo in v1 review [1].

The current OOM notifier path calls synchronize_srcu() inline from mmu_notifier_oom_enter(), which can deadlock on PREEMPT_RT when locks such as siglock are held. This series moves the cleanup to an asynchronous context using call_srcu(), allowing the OOM path to proceed without waiting for an SRCU grace period.

Subscribers opt in via a new after_oom_unregister callback in struct mmu_notifier_ops.

KVM is the first (and currently only) user.

Changes since v1 [1]:
- Implement after_oom_unregister callback in struct mmu_notifier_ops as proposed by Paolo
- Add mmu_notifier_oom_enter() to detach subscriptions and schedule cleanup via call_srcu()
- Add mmu_notifier_barrier() (srcu_barrier wrapper) so consumers can wait for pending callbacks during teardown
- Move call site from __oom_kill_process() to __oom_reap_task_mm() to fix KASAN vmalloc-out-of-bounds observed in v1
- Use hlist_del_init() to keep hlist_unhashed() correct for the kvm_destroy_vm() detection path, avoiding use-after-free on the stack-allocated oom_list head
- Add KVM after_oom_unregister implementation to clear mn_active_invalidate_count
- Update kvm_destroy_vm() to detect detached subscriptions via hlist_unhashed() and use mmu_notifier_barrier() + mmdrop() instead of mmu_notifier_unregister()
- Remove pr_err() on GFP_ATOMIC failure per checkpatch; the trade-off is documented inline

Testing
-------

Developed and tested under virtme-ng with PREEMPT_RT, KASAN, and lockdep enabled.

Test setup:
- simple_kvm.c: minimal userspace program that opens /dev/kvm, creates a VM, registers memory, creates a vCPU, and sleeps
- CONFIG_DEBUG_VM-only debugfs interface (not part of this submission) at /sys/kernel/debug/oom_reap_task to invoke __oom_reap_task_mm() on a target task

Test sequence:

  $ ./simple_kvm &
  $ echo $! | sudo tee /sys/kernel/debug/oom_reap_task

Observed with patch applied:
- __oom_reap_task_mm() completes
- mmu_notifier_oom_enter() detaches the KVM subscription
- call_srcu() callback runs after (SRCU grace period)
- KVM after_oom_unregister clears mn_active_invalidate_count
- mmu_notifier_barrier() returns cleanly
- No KASAN reports, no kernel BUGs, lockdep clean

Stress runs (20 iterations) showed consistent results.

Reproducing the syzbot-reported issue
-------------------------------------
The issue reported by syzbot is reproducible on an unpatched PREEMPT_RT kernel, triggering a "sleeping function called from invalid context" warning in kvm_mmu_notifier_invalidate_range_start(). With this patch applied, the warning is no longer observed..

Known limitations
-----------------

Failure of GFP_ATOMIC allocation in mmu_notifier_oom_enter() causes the corresponding after_oom_unregister callback to be skipped. The OOM path cannot sleep without reintroducing the deadlock this series fixes, and synchronous execution would require waiting for SRCU readers. Cleanup still occurs later via the normal unregister path. A mempool-backed allocator could address this in the future.

[1] https://lore.kernel.org/all/CABgObfZQM0Eq1=vzm812D+CAcjOaE1f1QAUqGo5rTzXgLnR9cQ@mail.gmail.com

Reported-by [email protected]

Closes https://syzkaller.appspot.com/bug?extid=c3178b6b512446632bac

Tested-by Shaikh Kamaluddin <[email protected]>

shaikh.kamal (1):
mm/mmu_notifier: Add async OOM cleanup via call_srcu()

 include/linux/mmu_notifier.h |  10 +++
 mm/mmu_notifier.c            | 123 +++++++++++++++++++++++++++++++++++
 mm/oom_kill.c                |   3 +
 virt/kvm/kvm_main.c          |  27 +++++++-
 4 files changed, 162 insertions(+), 1 deletion(-)

--
2.43.0