lkml.org 
[lkml]   [2020]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: objtool clac/stac handling change..
On Fri, Jul 03, 2020 at 02:41:43PM -0700, Andy Lutomirski wrote:

> I still feel like the ex_handler-automatically-does-CLAC thing is an
> optimization that isn't worth it. Once we pull our heads out of the
> giant pile of macros and inlined functions, we're talking about
> changing:

> clac; jmp. But on the flip side, the jump folding pattern looks
> better like this:
>
> unsafe_uaccess_begin();
> if (unsafe_get_user(...))
> goto fail;
> if (unsafe_get_user(...))
> goto fail;
> unsafe_uaccess_end();
>
> fail:
> unsafe_uaccess_end();
>
> than like:
>
> unsafe_uaccess_begin();
> if (unsafe_get_user(...))
> goto fail;
> if (unsafe_get_user(...))
> goto fail;
> unsafe_uaccess_end();
>
> fail:
> /* not unsafe_uaccess_end(); because unsafe_get_user() has
> conditional-CLAC semantics */

First of all, user_access_begin() itself can bloody well fail. So you need
to handle that as well. And then it becomes nowhere near as pretty.

We can pretend that it's normal C; however, that's not true at all - there
are shitloads of things you can't do in such areas, starting with "call anything
other than a very small list of functions". It's not a normal C environment
at all.

My problem is not with having AC turned off in exception handler - it leads
to saner patterns, no arguments here. I'm not happy with doing doing that
on *every* exception, with no way to specify whether it should or should not
be done. It's not like it would've cost us anything to be able to specify
that - we have the third argument of _ASM_EXTABLE_HANDLE(), after all.

\
 
 \ /
  Last update: 2020-07-04 00:26    [W:0.106 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site