All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: objtool clac/stac handling change..
Date: Wed, 1 Jul 2020 13:51:11 -0700	[thread overview]
Message-ID: <CAHk-=wh0X1YBQm8b6dqu=FpE8jgHriisXDeqJ7jai41Ob+sJDA@mail.gmail.com> (raw)
In-Reply-To: <5F1767D0-416A-4BA4-9DFF-E82D1EA3F5EE@amacapital.net>

On Wed, Jul 1, 2020 at 1:36 PM Andy Lutomirski <luto@amacapital.net> wrote:
>
> We ought to be able to do it the way I described and get decent code generation too.

No, we really can't.

Each access really needs to jump to an exception label. Otherwise any
time you have multiple operations (think "strncpy()" and friends) you
have to test in between each access.

That is why *fundamnetally* the interface to "unsafe_get/put_user()"
takes a label for the error case. There is absolutely no way to make
any other interface work efficiently.

(Unless, of course, you make the exception handling something that the
compiler does entirely on its own. But that has never been a good idea
for the kernel, and I wouldn't trust a compiler to do what the kernel
needs).

Side note: the labels can be hidden. I did (long ago) send out
something that did a

    uaccess_try {
         val1 = unsafe_get_user(addr);
         val2 = unsafe_get_user(addr2);
    } uaccess_catch {
         error handling here
     };

kind of thing, but that was just syntactic wrapper around that label
model. And honestly, it doesn't really change anything fundamental, it
really ends up with exactly the same issues just with a slightly
different syntax.

(I did that because we had the nasty "put_user_ex()" interfaces, which
were horrible horrible crap, and if one access took an exception, then
all the other ones did too).

The "label for error case" is actually simpler to follow both for the
user and for a compiler. Yes, it's a bit odd, but once you get used to
it, it's really quite regular. But having a different error handler
for the "user_access_begin()" failure and the actual access failure
really does end up generating duplicate code and confusion.

              Linus

              Linus

  parent reply	other threads:[~2020-07-01 20:51 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 18:22 objtool clac/stac handling change Linus Torvalds
2020-07-01 18:29 ` Andy Lutomirski
2020-07-01 19:35   ` Linus Torvalds
2020-07-01 20:36     ` Andy Lutomirski
2020-07-01 20:51       ` Josh Poimboeuf
2020-07-01 21:02         ` Linus Torvalds
2020-07-02  0:00           ` Josh Poimboeuf
2020-07-02  8:05             ` Peter Zijlstra
2020-07-01 20:51       ` Linus Torvalds [this message]
2020-07-02  0:47         ` Andy Lutomirski
2020-07-02  2:30           ` Linus Torvalds
2020-07-02  2:35             ` Linus Torvalds
2020-07-02  3:08             ` Andy Lutomirski
2020-07-01 18:41 ` Al Viro
2020-07-01 19:04   ` Linus Torvalds
2020-07-01 19:59     ` Al Viro
2020-07-01 20:25       ` Linus Torvalds
2020-07-02 13:34         ` Michael Ellerman
2020-07-02 14:01           ` Al Viro
2020-07-02 14:04             ` Al Viro
2020-07-02 15:13           ` Christophe Leroy
2020-07-02 20:13             ` Linus Torvalds
2020-07-03  3:59               ` Michael Ellerman
2020-07-03  3:17             ` Michael Ellerman
2020-07-03  5:27               ` Christophe Leroy
2020-07-03  5:27                 ` Christophe Leroy
2020-07-02 19:52           ` Linus Torvalds
2020-07-02 20:17             ` Al Viro
2020-07-02 20:32               ` Linus Torvalds
2020-07-02 20:59                 ` Al Viro
2020-07-02 21:55                   ` Linus Torvalds
2020-07-03  1:33                     ` Al Viro
2020-07-03  3:32                       ` Linus Torvalds
2020-07-03 21:02                       ` Al Viro
2020-07-03 21:10                         ` Linus Torvalds
2020-07-03 21:41                           ` Andy Lutomirski
2020-07-03 22:25                             ` Al Viro
2020-07-03 21:59                           ` Al Viro
2020-07-03 22:04                             ` Al Viro
2020-07-03 22:12                           ` Al Viro
2020-07-04  0:49                         ` Al Viro
2020-07-04  1:54                           ` Linus Torvalds
2020-07-04  2:30                             ` Al Viro
2020-07-04  3:06                               ` Linus Torvalds
2020-07-04  2:11                           ` Al Viro
2020-07-07 12:35                             ` David Laight
2020-07-10 22:37                               ` Linus Torvalds
2020-07-13  9:32                                 ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wh0X1YBQm8b6dqu=FpE8jgHriisXDeqJ7jai41Ob+sJDA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.