On 7/15/26 20:16, Stanislav Kinsburskii wrote: > hmm_range_fault() requires the caller to hold the mmap read lock for the > duration of the call. This is incompatible with mappings whose fault > handler may release the mmap lock, notably userfaultfd-managed regions, > where handle_mm_fault() can return VM_FAULT_RETRY or VM_FAULT_COMPLETED > after dropping the lock. Drivers that need to populate device page tables > for such mappings have no way to do so today. > > Add hmm_range_fault_unlocked_timeout() for callers that do not need to hold > mmap_lock across any work outside the HMM fault itself. The helper takes > mmap_read_lock_killable() internally, calls the common HMM fault > implementation, and releases the lock before returning if it is still held. > The timeout is specified in jiffies; passing 0 retries indefinitely, while > a non-zero timeout makes the helper return -EBUSY when the retry budget > expires.
The timeout does not / cannot affect how long we might be stuck without the mmap lock in e.g., the userfaultfd handler. And also not how long it would take to actually grab the mmap lock. That's expected with the timeout, right? [...] Nothing else jumped at me. -- Cheers, David
