On Fri, 5 Apr 2024 13:02:30 +0200 Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > On 04/05, Jiri Olsa wrote: > > > > On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote: > > > > > > I think this expects setjmp/longjmp as below > > > > > > foo() { <- retprobe1 > > > setjmp() > > > bar() { <- retprobe2 > > > longjmp() > > > } > > > } <- return to trampoline > > > > > > In this case, we need to skip retprobe2's instance. > > Yes, > > > > My concern is, if we can not find appropriate return instance, what happen? > > > e.g. > > > > > > foo() { <-- retprobe1 > > > bar() { # sp is decremented > > > sys_uretprobe() <-- ?? > > > } > > > } > > > > > > It seems sys_uretprobe() will handle retprobe1 at that point instead of > > > SIGILL. > > > > yes, and I think it's fine, you get the consumer called in wrong place, > > but it's your fault and kernel won't crash > > Agreed. > > With or without this patch userpace can also do > > foo() { <-- retprobe1 > bar() { > jump to xol_area > } > } > > handle_trampoline() will handle retprobe1. This is OK because the execution path has been changed to trampoline, but the above will continue running bar() after sys_uretprobe(). > > > this can be fixed by checking the syscall is called from the trampoline > > and prevent handle_trampoline call if it's not > > Yes, but I still do not think this makes a lot of sense. But I won't argue. > > And what should sys_uretprobe() do if it is not called from the trampoline? > I'd prefer force_sig(SIGILL) to punish the abuser ;) OK, OK, EINVAL. > > I agree very much with Andrii, > > sigreturn() exists only to allow the implementation of signal handlers. It should never be > called directly. Details of the arguments (if any) passed to sigreturn() vary depending on > the architecture. > > this is how sys_uretprobe() should be treated/documented. OK. > > sigreturn() can be "improved" too. Say, it could validate sigcontext->ip > and return -EINVAL if this addr is not valid. But why? Because sigreturn() never returns, but sys_uretprobe() will return. If it changes the regs->ip and directly returns to the original return address, I think it is natural to send SIGILL. Thank you, -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>