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

On 08/25, Andrii Nakryiko wrote:

On Tue, Aug 25, 2026 at 9:38 AM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Tue, Aug 25, 2026 at 5:27 AM Oleg Nesterov [off-list ref] wrote:

quoted

On 08/24, Andrii Nakryiko wrote:

quoted

On Mon, Aug 24, 2026 at 8:57 AM Oleg Nesterov [off-list ref] wrote:

quoted

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.