Re: [PATCH v8 4/8] mshv: Use hmm_range_fault_unlocked_timeout() for region faults
Andrew Morton <[email protected]> Fri, 10 Jul 2026 22:46:06 -0700
| Newsgroups | org.kernel.vger.linux-hyperv,org.freedesktop.lists.dri-devel,org.freedesktop.lists.nouveau,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-rdma,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 10 Jul 2026 20:14:47 -0700 Stanislav Kinsburskii <[email protected]> wrote: > > > + mutex_lock(®ion->mreg_mutex); > > > + > > > + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) { > > > + mutex_unlock(®ion->mreg_mutex); > > > + cond_resched(); > > > + goto again; > > > + } > > > + > > > > If the calling process has realtime scheduling policy and either a) > > we're uniprocessor or b) this process and the holder of > > interval_sub->invalidate_seq are both pinned to the same CPU then > > cond_resched() won't do anything, and this might be an infinite loop? > > Yes, looks like it might. > What can be done to prevent this? Well the best way is remove the polling loop and use a proper sleep/wakeup mechanism - mutex_lock()/prepare_to_wait()/etc. If the polling loop is to be retained then maybe msleep(1) or usleep_range()?