Hi Oleg, Thanks a lot for the patches. I did corresponding changes [1] for arch_uretprobe_is_alive on top of my ARM64 RFC V2 [2] + these patches and found that longjump tests are working.
So for the series's common code Tested-by: Pratyush Anand <pan...@redhat.com> ~Pratyush [1] https://github.com/pratyushanand/linux/commit/880df93e2dac48f620069fffb16d551e96681774 [2] http://thread.gmane.org/gmane.linux.kernel/1979016 On 07/07/2015:03:22:10 AM, Oleg Nesterov wrote: > Sorry for delay, > > Currently ret-probes can't work (the application will likely crash) > if the probed function does not return, and this is even documented > in handle_trampoline(). > > This series tries to make the first step to fix the problem, assuming > that the probed functions use the same stack. > > TODO: sigaltstack() can obviously break this assumption. > > NOTE: I don't think it is possible to make this logic 100% correct, > the user-space can do everything with its stack. For example, the > application can do longjmp-like tricks to implement the coroutines, > the kernel can do nothing in this case. The application (or debugger) > should cooperate somehow to let the kernel know whats going on. > > v2, based on disccsussion with Srikar and Pratyush: > > 1-5: Unchanged, I preserved the acks from Srikar. > > 6-11: The only essential change is that we do not add the > (ugly) arch_uretprobe, we just export return_instance > to arch/. > > This means that we do not need to touch the !x86 code, > and return_instance->stack can be initialized by the > generic code. > > Srikar, I hope you can ack v2 too. > > 10/11: New. As Pratyush pointed out "bool on_call" is too > limited. > > Plus v2 fixes the problem mentioned in "self nack" email, we must > not do cleanup_return_instances() after prepare_uretprobe() checks > chained && utask->return_instances != NULL. > > Oleg. > > arch/x86/kernel/uprobes.c | 9 ++ > include/linux/uprobes.h | 17 ++++ > kernel/events/uprobes.c | 184 > +++++++++++++++++++++++++-------------------- > 3 files changed, 128 insertions(+), 82 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
