All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Anand <panand@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ananth Mavinakayanahalli <ananth@in.ibm.com>,
	Anton Arapov <arapov@gmail.com>,
	David Long <dave.long@linaro.org>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Ingo Molnar <mingo@kernel.org>, Jan Willeke <willeke@de.ibm.com>,
	Jim Keniston <jkenisto@us.ibm.com>,
	Mark Wielaard <mjw@redhat.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/11] uprobes: longjmp fixes
Date: Fri, 10 Jul 2015 17:31:04 +0530	[thread overview]
Message-ID: <20150710120104.GA8855@dhcppc13.redhat.com> (raw)
In-Reply-To: <20150707012210.GA7466@redhat.com>

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 <panand@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(-)

      parent reply	other threads:[~2015-07-10 12:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07  1:22 [PATCH v2 00/11] uprobes: longjmp fixes Oleg Nesterov
2015-07-07  1:22 ` [PATCH v2 01/11] uprobes: Introduce get_uprobe() Oleg Nesterov
2015-07-07 12:44   ` Anton Arapov
2015-07-07  1:22 ` [PATCH v2 02/11] uprobes: Introduce free_ret_instance() Oleg Nesterov
2015-07-07 12:46   ` Anton Arapov
2015-07-07  1:22 ` [PATCH v2 03/11] uprobes: Send SIGILL if handle_trampoline() fails Oleg Nesterov
2015-07-07 12:51   ` Anton Arapov
2015-07-07  1:22 ` [PATCH v2 04/11] uprobes: Change prepare_uretprobe() to use uprobe_warn() Oleg Nesterov
2015-07-07 12:52   ` Anton Arapov
2015-07-07  1:22 ` [PATCH v2 05/11] uprobes: Change handle_trampoline() to find the next chain beforehand Oleg Nesterov
2015-07-07 12:54   ` Anton Arapov
2015-07-07  1:22 ` [PATCH v2 06/11] uprobes: Export struct return_instance, introduce arch_uretprobe_is_alive() Oleg Nesterov
2015-07-07 12:58   ` Anton Arapov
2015-07-10 11:52   ` Srikar Dronamraju
2015-07-07  1:22 ` [PATCH v2 07/11] uprobes/x86: Reimplement arch_uretprobe_is_alive() Oleg Nesterov
2015-07-07 13:02   ` Anton Arapov
2015-07-10 11:53   ` Srikar Dronamraju
2015-07-07  1:23 ` [PATCH v2 08/11] uprobes: Change handle_trampoline() to flush the frames invalidated by longjmp() Oleg Nesterov
2015-07-07 13:05   ` Anton Arapov
2015-07-10 11:55   ` Srikar Dronamraju
2015-07-07  1:23 ` [PATCH v2 09/11] uprobes: Change prepare_uretprobe() to (try to) flush the dead frames Oleg Nesterov
2015-07-07 13:07   ` Anton Arapov
2015-07-10 11:57   ` Srikar Dronamraju
2015-07-07  1:23 ` [PATCH v2 10/11] uprobes: Add the "enum rp_check ctx" arg to arch_uretprobe_is_alive() Oleg Nesterov
2015-07-07 13:08   ` Anton Arapov
2015-07-10 12:06   ` Srikar Dronamraju
2015-07-07  1:23 ` [PATCH v2 11/11] uprobes/x86: Make arch_uretprobe_is_alive(RP_CHECK_CALL) more clever Oleg Nesterov
2015-07-07 13:11   ` Anton Arapov
2015-07-10 12:07   ` Srikar Dronamraju
2015-07-10 12:01 ` Pratyush Anand [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150710120104.GA8855@dhcppc13.redhat.com \
    --to=panand@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=arapov@gmail.com \
    --cc=dave.long@linaro.org \
    --cc=dvlasenk@redhat.com \
    --cc=fche@redhat.com \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mjw@redhat.com \
    --cc=oleg@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=willeke@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.