This is the mail archive of the
mailing list for the glibc project.
Re: framebuffer corruption due to overlapping stp instructions on arm64
- From: Mikulas Patocka <mpatocka at redhat dot com>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>, Florian Weimer <fweimer at redhat dot com>, Thomas Petazzoni <thomas dot petazzoni at free-electrons dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andrew Pinski <pinskia at gmail dot com>, Catalin Marinas <catalin dot marinas at arm dot com>, Will Deacon <will dot deacon at arm dot com>, Russell King <linux at armlinux dot org dot uk>, LKML <linux-kernel at vger dot kernel dot org>, linux-arm-kernel <linux-arm-kernel at lists dot infradead dot org>
- Date: Fri, 3 Aug 2018 20:58:18 -0400 (EDT)
- Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
- References: <alpine.LRH.email@example.com> <CA+=Sn1mWkjuwVnjw6OWWUM=UcP76bdFa680FebCseewHfx3NpA@mail.gmail.com> <firstname.lastname@example.org> <CAJA7tRZbmnZq7RfvQeYEy_a1ZObWqpFpVdvgsXgsioQ3RyPMuA@mail.gmail.com> <CAKv+Gu97QvwoLLK_zueiA_gjg_4Q5cqU4YVUyHUVFFfffdyJaw@mail.gmail.com> <email@example.com>
On Fri, 3 Aug 2018, Richard Earnshaw (lists) wrote:
> Whoa, hold on.
> Memcpy should never be used on device memory. Period. Memcpy doesn't
> know anything about what size of access is needed for accessing a device.
> But why is the buffer in device memory rather than some other form of
> uncached memory?
> If you change memcpy to deal with an aspect of the system hardware,
> you'll end up hosing performance EVERYWHERE. DON'T DO IT!
memcpy in glibc uses ifunc selection and it already has optimized variants
for Falkor and Thunder-X. You can add just another variant for Armada-8040
that works around this bug and you won't be harming anyone but users of
Furthermore, you can detect in the kernel that the PCI bus has some device
with prefetchable BAR and activate the workaround only if there is
videocard plugged in the PCIe slot.
> If you must, create a new API with tighter semantics, but don't change
> memcpy to accommodate this.
> Anyway, back to the original report. What memory mapping is being used?
> In detail?
It is PCI prefetchable BAR. It is mapped using pgprot_writecombine, which
results in MT_NORMAL_NC page attributes. (the MT_DEVICE_nGnRE can't be
used because it results in crashes due to unaligned accesses to videoram).