lkml.org 
[lkml]   [2020]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: objtool clac/stac handling change..
    On Wed, Jul 01, 2020 at 11:22:01AM -0700, Linus Torvalds wrote:
    > 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);
    > user_access_end();
    > return 0;
    >
    > label:
    > user_access_end();
    > efaulr:
    > 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
    > user_access_end().
    >
    > That would end up cleaning up the flow for a number of cases.
    >
    > Nasty? Trivial?

    Rather nasty for ppc; they have separate user_read_access_end() and
    user_write_access_end().

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