All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	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: Sat, 4 Jul 2020 01:49:59 +0100	[thread overview]
Message-ID: <20200704004959.GY2786714@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200703210237.GS2786714@ZenIV.linux.org.uk>

On Fri, Jul 03, 2020 at 10:02:37PM +0100, Al Viro wrote:

> PS: I'm still going through the _ASM_EXTABLE... users on x86, so there
> might be more fun.  Will post when I'm done...

Lovely...  Not directly related to that, but... WTF?

arch/x86/lib/csum-copy_64.S:

        /*
         * No _ASM_EXTABLE_UA; this is used for intentional prefetch on a
         * potentially unmapped kernel address.
         */
        .macro ignore L=.Lignore
30:
        _ASM_EXTABLE(30b, \L)
        .endm

...
        ignore 2f
        prefetcht0 5*64(%rdi)
2:

(and no other users of 'ignore' anywhere).  How could prefetcht0 possibly
raise an exception?  Intel manual says that the only exception is #UD if
LOCK PREFETCHT0 is encountered; not here, obviously.  AMD manual simply
says "no exceptions".  Confused...

Incidentally, in the same file:
SYM_FUNC_START(csum_partial_copy_generic)
        cmpl    $3*64, %edx
        jle     .Lignore

.Lignore:
....

And it had been that way since "[PATCH] Intel x86-64 support merge" back
in 2004, where we had
@@ -59,15 +59,6 @@ csum_partial_copy_generic:
        cmpl     $3*64,%edx
        jle      .Lignore
 
-       ignore
-       prefetch (%rdi)
-       ignore
-       prefetch 1*64(%rdi)
-       ignore
-       prefetchw (%rsi)
-       ignore
-       prefetchw 1*64(%rsi)
-
 .Lignore:
....
@@ -115,7 +106,7 @@ csum_partial_copy_generic:
        movq  56(%rdi),%r13
                
        ignore 2f
-       prefetch 5*64(%rdi)
+       prefetcht0 5*64(%rdi)
 2:                                                     
        adcq  %rbx,%rax
        adcq  %r8,%rax

What's going on in there?  According to AMD manual, prefetch and prefetchw
can raise an exception (#UD), if
PREFETCH/PREFETCHW are not supported, as
   indicated by ECX bit 8 of CPUID function
   8000_0001h
Long Mode is not supported, as indicated by EDX
   bit 29 of CPUID function 8000_0001h
The 3DNow! instructions are not supported, as
   indicated by EDX bit 31 of CPUID function
   8000_0001h.
so these at least used to make some sense, but why leave that thing at
the place where old prefetch became prefetcht0 and what is that comment
in front of 'ignore' definition about?  Exceptions there had never
been about unmapped addresses - that would make no sense for prefetch.

What am I missing here?

  parent reply	other threads:[~2020-07-04  0:50 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
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 [this message]
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=20200704004959.GY2786714@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=christophe.leroy@c-s.fr \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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.