RE: framebuffer corruption due to overlapping stp instructions on arm64

From: Mikulas Patocka <mpatocka@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Catalin Marinas'" <catalin.marinas@arm.com>,
	Matt Sealey <neko@bakuhatsu.net>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	Will Deacon <will.deacon@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: RE: framebuffer corruption due to overlapping stp instructions on arm64
Date: Wed, 8 Aug 2018 14:37:02 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1808081435020.18198@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <19c70d2a0b224db78f72dd316ad006b8@AcuMS.aculab.com>

On Wed, 8 Aug 2018, David Laight wrote:

> From: Mikulas Patocka
> > Sent: 08 August 2018 14:47
> ...
> > The problem on ARM is that I see data corruption when the overlapping
> > unaligned writes are done just by a single core.
> 
> Is this a sequence of unaligned writes (that shouldn't modify the
> same physical locations) or an aligned write followed by an
> unaligned one that updates part of the earlier write.
> (Or the opposite order?)
> 
> It might be that the unaligned writes are bypassing the write-combining
> buffer (without flushing it) - so overtake the aligned write.
> 
> Alternatively the unaligned writes go through the write-combining
> buffer but the byte-enables aren't handled in the expected way.
> 
> It ought to be possible to work out which sequence is actually broken.
> 
> 	David

All the unaligned/or aligned writes inside memcpy write the same value to 
the overlapping bytes. So, the corruption can't be explained just by 
reordering the writes or failing to detect hazard between them.

Mikulas