On Tue, Jul 21, 2026 at 05:42:53PM +0200, David Hildenbrand (Arm) wrote: > 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? > > [...] >
You are right. Ideally, the timeout should account for the time needed to acquire the lock. However, this timeout is not strict, especially with userfaultfd. It is more of a sentinel to make sure the kernel does not get stuck for too long and that progress is being made. The default value used by most callers is 1000 ms, so accounting for the time needed to acquire the mmap_lock does not really make much sense to me yet, given the sentinel goal. Thanks, Stanislav > > Nothing else jumped at me. > > -- > Cheers, > > David
