Re: SIGILL and uretprobes, WAS: [PATCH] uprobes: Free utask on dup_return_instance() failure

[Oleg Nesterov <oleg@redhat.com>]

On 08/25, Andrii Nakryiko wrote:
>
> On Tue, Aug 25, 2026 at 9:38 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Tue, Aug 25, 2026 at 5:27 AM Oleg Nesterov <oleg@redhat.com> wrote:
> > >
> > > On 08/24, Andrii Nakryiko wrote:
> > > >
> > > > On Mon, Aug 24, 2026 at 8:57 AM Oleg Nesterov <oleg@redhat.com> wrote:
> > > > >
> > > > > force_exit_sig(SIGILL) can't be ignored too. But I am fine either way.
> > > >
> > > > Current SIGILL sending is already pretty bad behavior that bites us
> > > > periodically, instead of doubling down on killing the user space
> > > > process because something about installing uprobe goes wrong, let's
> > > > think about a bit less destructive way to do this. Mark uprobe for a
> > > > particular process as defunct or "detaching it", or something along
> > > > those lines. But not just kill innocent processes.
> > >
> > > Well. Yes, SIGILL sending acts as BUG_ON(), this is not nice and
> >
> > The problem is that this is actually not a bug but a very real and
> > expected behavior with user-space using fibers or coroutines. Any
> > suggestions how we can make this less violent, as it's actually quite
> > dangerous and kills production applications when someone (unknowingly)
> > tries to uretprobe trace them...
> >
>
> IIUC, this SIGILL and coroutines/fibers issue is due to
> uprobe_handle_trampoline not finding utrask->return_instances, because
> a bit earlier we threw out pending uretprobes due to
> arch_uretprobe_is_alive() returned false due to that `regs->sp <=
> ret->stack` check (for x86-64).

Well, unless I am totally confused this is another thing...

Yes, arch_uretprobe_is_alive() sucks, it assumes the single stack.

And I do not know how to fix this problem... uprobe_handle_trampoline()
must fix regs->ip correctly somehow, otherwise it is pointless to contunue.

Note also that the current instruction_pointer_set(ri->orig_ret_vaddr)
can be wrong if the probed task switches its stack.

And we have the same problems with sigaltstack().

ATM, I don't see any solution, and I don't really understand what do
you propose...

Oleg.