lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 22 Jul 2019 10:18:01 -0500
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Nathan Chancellor <natechancellor@...il.com>,
        Christophe Leroy <christophe.leroy@....fr>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        clang-built-linux@...glegroups.com
Subject: Re: [PATCH v2] powerpc: slightly improve cache helpers

On Mon, Jul 22, 2019 at 08:15:14PM +1000, Michael Ellerman wrote:
> Segher Boessenkool <segher@...nel.crashing.org> writes:
> > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> >> 0000017c clear_user_page:
> >>      17c: 94 21 ff f0                  	stwu 1, -16(1)
> >>      180: 38 80 00 80                  	li 4, 128
> >>      184: 38 63 ff e0                  	addi 3, 3, -32
> >>      188: 7c 89 03 a6                  	mtctr 4
> >>      18c: 38 81 00 0f                  	addi 4, 1, 15
> >>      190: 8c c3 00 20                  	lbzu 6, 32(3)
> >>      194: 98 c1 00 0f                  	stb 6, 15(1)
> >>      198: 7c 00 27 ec                  	dcbz 0, 4
> >>      19c: 42 00 ff f4                  	bdnz .+65524
> >
> > Uh, yeah, well, I have no idea what clang tried here, but that won't
> > work.  It's copying a byte from each target cache line to the stack,
> > and then does clears the cache line containing that byte on the stack.
> 
> So it seems like this is a clang bug.
> 
> None of the distros we support use clang, but we would still like to
> keep it working if we can.

Which version?  Which versions *are* broken?

> Looking at the original patch, the only upside is that the compiler
> can use both RA and RB to compute the address, rather than us forcing RA
> to 0.
> 
> But at least with my compiler here (GCC 8 vintage) I don't actually see
> GCC ever using both GPRs even with the patch. Or at least, there's no
> difference before/after the patch as far as I can see.

The benefit is small, certainly.

> So my inclination is to revert the original patch. We can try again in a
> few years :D
> 
> Thoughts?

I think you should give the clang people time to figure out what is
going on.


Segher

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ