On Fri, Jul 19, 2019 at 09:04:55AM -0700, Nathan Chancellor wrote:
> On Fri, Jul 19, 2019 at 10:23:03AM -0500, Segher Boessenkool wrote:
> > On Thu, Jul 18, 2019 at 08:24:56PM -0700, Nathan Chancellor wrote:
> > > On Mon, Jul 08, 2019 at 11:49:52PM -0700, Nathan Chancellor wrote:
> > > > On Tue, Jul 09, 2019 at 07:04:43AM +0200, Christophe Leroy wrote:
> > > > > Is that a Clang bug ?
> > > > 
> > > > No idea, it happens with clang-8 and clang-9 though (pretty sure there
> > > > were fixes for PowerPC in clang-8 so something before it probably won't
> > > > work but I haven't tried).
> > > > 
> > > > > 
> > > > > Do you have a disassembly of the code both with and without this patch in
> > > > > order to compare ?
> > > > 
> > > > I can give you whatever disassembly you want (or I can upload the raw
> > > > files if that is easier).
> > > 
> > > What disassembly/files did you need to start taking a look at this? I
> > > can upload/send whatever you need.
> > 
> > A before and after of *only this patch*.  And then look at what changed;
> > it maybe be obvious what is the problem to you, as well, so look at it
> > yourself first?
> > 
> > 
> > Segher

Hi Segher,

Looks like the problematic function is dcbz, as there is no segfault
when only that function is reverted to a
pre-6c5875843b87c3adea2beade9d1b8b3d4523900a state.

I was able to expose a singular problematic callsite using the attached
patch (let me know if that is insufficient).

I have attached the disassembly of arch/powerpc/kernel/mem.o with
clear_page (working) and broken_clear_page (broken), along with the side
by side diff. My assembly knowledge is fairly limited as it stands and
it is certainly not up to snuff on PowerPC so I have no idea what I am
looking for. Please let me know if anything immediately looks off or if
there is anything else I can do to help out.

Cheers,
Nathan