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

On Wed, Aug 26, 2026 at 4:49 AM Oleg Nesterov [off-list ref] wrote:

On 08/25, Andrii Nakryiko wrote:

quoted

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.

Argh, I completely forgot about regs->ip fix up, sorry.

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...

Well, conceptually, I'd like us to try to find correct return_instance
instead of assuming the last one in the list is the one we want.
Whether that's technically sound, is a good question, I haven't done a
very thorough home work on this, sorry.

But we do have all pending return instances, and they record original
stack pointer, maybe we can do something with that? On user function
return, stack pointer should match what we had when we installed
return_instance, isn't that right? So in normal/happy case we'll do
what we do today, but if we find our that return_instance is "not
valid", we keep searching across all pending return instances. That's
going to be slower for sure, but at least it a) won't kill the app and
b) will be immensely useful.

Oleg.