On Tue, Mar 03, 2026 at 04:02:50PM -0800, Suren Baghdasaryan wrote: > On Tue, Mar 3, 2026 at 2:18 PM Matthew Wilcox <[email protected]> wrote: > > > > On Tue, Mar 03, 2026 at 02:11:31PM -0800, Suren Baghdasaryan wrote: > > > On Mon, Mar 2, 2026 at 6:53 AM Lorenzo Stoakes > > > <[email protected]> wrote: > > > > Overall I'm a little concerned about whether callers can handle -EINTR > > > > in all > > > > cases, have you checked? Might we cause some weirdness in userspace if > > > > a syscall > > > > suddenly returns -EINTR when before it didn't? > > > > > > I did check the kernel users and put the patchset through AI reviews. > > > I haven't checked if any of the affected syscalls do not advertise > > > -EINTR as a possible error. Adding that to my todo list for the next > > > respin. > > > > This only allows interruption by *fatal* signals. ie there's no way > > that userspace will see -EINTR because it's dead before the syscall > > returns to userspace. That was the whole point of killable instead of > > interruptible. > > Ah, I see. So, IIUC, that means any syscall can potentially fail with > -EINTR and this failure code doesn't need to be documented. Is that > right?
We could literally return any error code -- it never makes it to userspace. I forget where it is, but if you follow the syscall return to user path, a dying task never makes it to running a single instruction.
