[lkml]   [2020]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectobjtool clac/stac handling change..
Josh / PeterZ,
it turns out that clang seems to now have fixed the last known
nagging details with "asm goto" with outputs, so I'm looking at
actually trying to merge the support for that in the kernel.

The main annoyance isn't actually using "asm goto" at all, the main
annoyance is just that it will all have to be conditional on whether
the compiler supports it or not. We have the config option for that
already, but it will just end up with two copies of the code depending
on that option.

It's not a huge deal: the recent cleanups wrt the x86 uaccess code
have made the code _much_ more straightforward and legible, and I'm
not so worried about it all.

Except that when I looked at this, I realized that I really had picked
the wrong model for how exceptions are handled wrt stac/clac. In
particular user access exceptions return with stac set, so we end up
having a code pattern where the error case will also have to do the
user_access_end() to finish the STAC region.

Adding a user_access_end() to the user exception fault handler is trivial.

But the thing I'm asking you for is how nasty it would be to change
objtool to have those rules?

IOW, right now we have

if (!user_acces_begin(...))
goto efault;
unsafe_get/put_user(ptr, val, label);
return 0;

return -EFAULT;

and I'd like to make the "label" case just go to "efault", with
objtool knowing that the exception handling already did the

That would end up cleaning up the flow for a number of cases.

Nasty? Trivial?


 \ /
  Last update: 2020-07-01 20:22    [W:0.068 / U:2.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site