lkml.org 
[lkml]   [2019]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] sched/x86: Save [ER]FLAGS on context switch
    On Fri, Feb 15, 2019 at 08:06:56PM -0800, hpa@zytor.com wrote:
    > This implies we invoke schedule -- a restricted operation (consider
    > may_sleep) during execution of STAC-enabled code, but *not* as an
    > exception or interrupt, since those preserve the flags.

    Meet preempt_enable().

    > I have serious concerns about this. This is more or less saying that
    > we have left an unlimited gap and have had AC escape.

    Yes; by allowing normal C in between STAC and CLAC this is so.

    > Does *anyone* see a need to allow this? I got a question at LPC from
    > someone about this, and what they were trying to do once all the
    > layers had been unwound was so far down the wrong track for a root
    > problem that actually has a very simple solution.

    Have you read the rest of the thread?

    All it takes for this to explode is a call to a C function that has
    tracing on it in between the user_access_begin() and user_access_end()
    things. That is a _very_ easy thing to do.

    Heck, GCC is allowed to generate that broken code compiling
    lib/strnlen_user.c; it doesn't _have_ to inline do_strnlen_user (esp.
    with CONFIG_OPTIMIZE_INLINING), and making that a function call would
    get us fentry hooks and ftrace and *BOOM*.

    (Now, of course, its a static function with a single caller, and GCC
    isn't _THAT_ stupid, but it could, if it wanted to)

    Since the bar is _that_ low for mistakes, I figure we'd better fix it.

    \
     
     \ /
      Last update: 2019-02-16 11:31    [W:2.521 / U:0.904 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site