Re: [PATCH v3 2/3] mm: replace vma_start_write() with vma_start_write_killable()

[Matthew Wilcox <willy@infradead.org>]

On Tue, Mar 03, 2026 at 04:02:50PM -0800, Suren Baghdasaryan wrote:
> On Tue, Mar 3, 2026 at 2:18 PM Matthew Wilcox <willy@infradead.org> 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
> > > <lorenzo.stoakes@oracle.com> 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.