Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Mon, Jul 22, 2019 at 08:15:14PM +1000, Michael Ellerman wrote: >> Segher Boessenkool <seg...@kernel.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?
AFAIK clang 8 is the first version that we could build with, without hacks. >> 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. Zero is small, but I guess some things are smaller? :P >> 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. Yeah fair enough, will wait and see what their diagnosis is. cheers