On Tue, Jul 07, 2015 at 03:23:06AM +0200, Oleg Nesterov wrote:
> Change prepare_uretprobe() to flush the !arch_uretprobe_is_alive()
> return_instance's. This is not needed correctness-wise, but can help
> to avoid the failure caused by MAX_URETPROBE_DEPTH.
> 
> Note: in this case arch_uretprobe_is_alive() can be false positive,
> the stack can grow after longjmp(). Unfortunately, the kernel can't
> 100% solve this problem, but see the next patch.
> 
> Signed-off-by: Oleg Nesterov <o...@redhat.com>
Acked-by: Anton Arapov <ara...@gmail.com>

> ---
>  kernel/events/uprobes.c |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 93d939c..7e61c8c 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1511,6 +1511,16 @@ static unsigned long get_trampoline_vaddr(void)
>       return trampoline_vaddr;
>  }
>  
> +static void cleanup_return_instances(struct uprobe_task *utask, struct 
> pt_regs *regs)
> +{
> +     struct return_instance *ri = utask->return_instances;
> +     while (ri && !arch_uretprobe_is_alive(ri, regs)) {
> +             ri = free_ret_instance(ri);
> +             utask->depth--;
> +     }
> +     utask->return_instances = ri;
> +}
> +
>  static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs)
>  {
>       struct return_instance *ri;
> @@ -1541,6 +1551,9 @@ static void prepare_uretprobe(struct uprobe *uprobe, 
> struct pt_regs *regs)
>       if (orig_ret_vaddr == -1)
>               goto fail;
>  
> +     /* drop the entries invalidated by longjmp() */
> +     cleanup_return_instances(utask, regs);
> +
>       /*
>        * We don't want to keep trampoline address in stack, rather keep the
>        * original return address of first caller thru all the consequent
> -- 
> 1.5.5.1
> 
--
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/

Reply via email to