On Thu, Apr 24, 2025 at 05:45:37PM -0400, Peter Xu wrote: > On Thu, Apr 24, 2025 at 08:42:00PM +0100, Matthew Wilcox wrote: > > On Thu, Apr 24, 2025 at 02:26:37PM -0400, Peter Xu wrote: > > > Secondly, userfaultfd is indeed the only consumer of > > > FAULT_FLAG_INTERRUPTIBLE but not necessary always in the future. While > > > this patch resolves it for userfaultfd, it might get caught again later if > > > something else in the kernel starts to respects the _INTERRUPTIBLE flag > > > request. For example, __folio_lock_or_retry() ignores that flag so far, > > > but logically it should obey too (with a folio_wait_locked_interruptible).. > > > > No. Hell, no. We don't want non-fatal signals being able to interrupt > > that. There's a reason we introduced killable as a concept in the first > > place. > > Not really proposing that as I don't have a use caes. Just curious, could > you explain a bit why having it interruptible is against the killable > concept if (IIUC) it is still killable? Because "interruptible" means it can be interrupted by inane stuff like SIGWINCH and SIGALRM. And then we return from a page fault prematurely and can't actually handle the situation, so we end up going back into the page fault handler anyway having accomplished nothing other than burn CPU. At least it's better than interruptible system calls which just gets you short reads, corrupted data and crashing programs.
