Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault

[Al Viro]

On Sun, Aug 21, 2016 at 06:54:02AM +0200, Jakub Jelinek wrote:
> On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:

> If you plan to use setjmp/longjmp a lot, then it is certainly a major
> performance and compile time/memory problem.
> Older versions don't model it properly, and newer gccs emit abnormal edges
> from every longjmp or call that might longjmp to an artificial basic block
> and from there to every setjmp.
> Also note that gcc has/supports two setjmp kind of APIs, normal setjmp and
> slightly more lightweight __builtin_setjmp which saves fewer registers, and
> on some targets is/used to be used for EH instead of DWARF based ones.

It's not exactly setjmp/longjmp; what I had in mind was along the lines of

static inline bool start(void)
{
	asm(
		save enough state into current_thread_info()->something, with
			1f for saved %rip
		stac
		res = true
	2:
	.section .text.fixup
	1:	res = false
		clac
		jmp 2b
	.previous
	)
	if (unlikely(!res))
		asm clobber everything
	return res;
}

and in unsafe_get_user() exception fixup (again, in .text.fixup section,
and invisible to gcc) jumping to common code that would pick saved state
from current_thread_info() and jump to saved location.

	The uses would be along the lines of
	if (!start())
		goto fail;
	unsafe_get_user(foo, &p1->foo);
	unsafe_get_user(bar, &p1->bar);
	...
	asm clac

IOW, a bunch of branches hidden from gcc, with destination (in the same
function) dominating the source of each (via visible branches as well).

Originally I hoped to get away with saving just the %rip; Linus has pointed
out that stack pointer is also needed.  It's obviously much less generic
than setjmp/longjmp is.  Single per-thread jmp_buf rudiment, all "longjmp"
calls in the same function as "setjmp" one, pretty much not giving a damn
about any local variables we might've changed if the "longjmp" is taken,
etc.

The point of the exercise is to have the normal execution path containing
no error checks - just the data copying, with all exception handling happening
out-of-line...