Files
linux/include/linux
Oleg Nesterov db087ef69a uprobes/x86: Make arch_uretprobe_is_alive(RP_CHECK_CALL) more clever
The previous change documents that cleanup_return_instances()
can't always detect the dead frames, the stack can grow. But
there is one special case which imho worth fixing:
arch_uretprobe_is_alive() can return true when the stack didn't
actually grow, but the next "call" insn uses the already
invalidated frame.

Test-case:

	#include <stdio.h>
	#include <setjmp.h>

	jmp_buf jmp;
	int nr = 1024;

	void func_2(void)
	{
		if (--nr == 0)
			return;
		longjmp(jmp, 1);
	}

	void func_1(void)
	{
		setjmp(jmp);
		func_2();
	}

	int main(void)
	{
		func_1();
		return 0;
	}

If you ret-probe func_1() and func_2() prepare_uretprobe() hits
the MAX_URETPROBE_DEPTH limit and "return" from func_2() is not
reported.

When we know that the new call is not chained, we can do the
more strict check. In this case "sp" points to the new ret-addr,
so every frame which uses the same "sp" must be dead. The only
complication is that arch_uretprobe_is_alive() needs to know was
it chained or not, so we add the new RP_CHECK_CHAIN_CALL enum
and change prepare_uretprobe() to pass RP_CHECK_CALL only if
!chained.

Note: arch_uretprobe_is_alive() could also re-read *sp and check
if this word is still trampoline_vaddr. This could obviously
improve the logic, but I would like to avoid another
copy_from_user() especially in the case when we can't avoid the
false "alive == T" positives.

Tested-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Acked-by: Anton Arapov <arapov@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150721134028.GA4786@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-31 10:38:06 +02:00
..
2015-07-17 16:39:53 -07:00
2015-06-25 11:49:31 +03:00
2014-11-24 17:24:08 -05:00
2015-05-31 13:40:53 +02:00
2015-05-13 12:04:55 -05:00
2015-07-07 22:48:25 +02:00
2015-03-25 20:28:11 -04:00
2015-06-02 08:33:34 -06:00
2015-04-17 09:03:53 -04:00
2015-06-01 14:35:56 -06:00
2015-02-12 18:54:15 -08:00
2014-12-19 22:55:06 +01:00
2015-05-05 13:35:39 -06:00
2015-01-21 19:21:30 +01:00
2014-11-10 09:27:30 -07:00
2014-12-31 13:06:50 -05:00
2014-10-09 11:35:48 +03:00
2015-06-24 17:49:45 -07:00
2014-10-08 16:01:41 -04:00
2014-08-06 18:01:24 -07:00
2015-05-12 10:46:53 +02:00
2015-06-01 14:33:35 +02:00
2015-06-19 15:18:28 +02:00
2015-03-16 21:45:54 +11:00
2015-05-05 13:40:42 -06:00
2015-01-27 11:09:13 +01:00
2015-06-25 12:06:45 +02:00
2015-01-15 10:34:54 +01:00
2015-04-29 17:17:17 -05:00
2015-01-04 23:11:43 -05:00
2015-04-14 16:49:05 -07:00
2015-03-25 11:44:52 +01:00
2015-06-24 17:49:41 -07:00
2014-10-09 22:25:58 -04:00
2015-06-25 04:20:04 -04:00
2015-05-09 22:15:31 -04:00
2015-07-04 14:04:44 -04:00
2015-06-05 10:58:34 -06:00
2015-03-11 17:56:28 -04:00
2014-11-04 13:29:38 +00:00
2015-04-12 21:03:31 +02:00
2015-01-25 23:17:28 -05:00
2015-06-19 01:18:14 +02:00
2015-06-12 11:36:30 +02:00
2015-06-10 19:14:04 +08:00
2015-05-27 12:58:04 -07:00
2015-05-26 15:23:23 +02:00
2015-06-25 01:13:43 +02:00
2015-06-23 18:01:07 -04:00
2014-08-08 15:57:26 -07:00
2014-08-08 15:57:31 -07:00
2015-06-29 10:49:51 -07:00
2015-02-13 21:21:41 -08:00
2015-04-11 15:53:35 -04:00
2015-06-25 17:00:40 -07:00
2015-05-19 09:19:59 -06:00
2015-06-25 17:00:39 -07:00
2015-05-18 14:08:58 -07:00
2015-05-29 17:21:45 -05:00
2015-04-11 22:29:44 -04:00
2014-11-28 16:08:16 +01:00
2015-06-12 17:26:57 -07:00
2015-03-24 09:48:14 -07:00
2015-06-25 17:00:37 -07:00
2015-04-15 16:35:20 -07:00