Hi, Jason, On Fri, Jun 24, 2022 at 09:35:54PM -0300, Jason Gunthorpe wrote: > Can you talk abit about what is required to use this new interface > correctly? > > Lots of GUP callers are in simple system call contexts (like ioctl), > can/should they set this flag and if so what else do they need to do? Thanks for taking a look. IMHO the major thing required is the caller can handle the case when GUP returned (1) less page than expected, and (2) -EINTR returns. For the -EINTR case, IIUC ideally in an ioctl context we should better deliver it back to user app this -EINTR (while do cleanups gracefully), rather than returning anything else (e.g. converting it to -EFAULT or something else). But note that FAULT_FLAG_INTERRUPTIBLE is only used in an userfaultfd context (aka, userfaultfd_get_blocking_state()). For example, if we hang at lock_page() (if not go into whether hanging at lock_page makes sense or not at all.. it really sounds like a bug) and we receive a non-fatal signal, we won't be able to be scheduled for that since lock_page() uses TASK_UNINTERRUPTIBLE always. I think it's a separate problem on whether we should extend the usage of FAULT_FLAG_INTERRUPTIBLE to things like lock_page() (and probably not..), and currently it does solve a major issue regarding postcopy hanging on pages for hypervisor use case. Hopefully that still justifies this plumber work to enable the interruptible cap to GUP layer. If to go back to the original question with a shorter answer: if the ioctl context that GUP upon a page that will never be with a uffd context, then it's probably not gonna help at all.. at least not before we use FAULT_FLAG_INTERRUPTIBLE outside uffd page fault handling. Thanks, -- Peter Xu
