On Tue, Dec 15, 2015 at 10:29:54AM -0500, Jon Masters wrote:
On 12/15/2015 06:43 AM, Måns Rullgård wrote:
Jon Masters jcm@redhat.com writes:
But the reading of that cpio content into the new table locations is done using the kernel memcpy routine to early_ioremap'd memory (Device memory), which is architecturally sensitive to missaligned accesses.
As others have pointed out, your error is twofold: first using early_ioremap() when early_memremap() would do, then using regular memcpy() and not memcpy_fromio() on that. Seems like your precious ACPI code is to blame here.
So I get that this could be changed. But I still want to understand whether memcpy is behaving correctly. Will it guaranteed /never/ occur that a copy will involve Device memory?
It is guaranteed in the same sense that other problems resulting from misuses of kernel APIs are guaranteed never to occur -- so long as the contract between the API and the programmer is respected.
It is physically possible that a programmer may violate that contract. It is a programming error if that happens.
All other such occurrences in the kernel will be caught and fixed so this will never be an issue?
No-one has the prescience to be able to tell you whether a particular bug will or will not be introduced in future. If the programmer pays attention to their tools (e.g. sparse warnings about address space mismatches), this class of error is fairly easy to avoid.
If you have found another occurrence of this issue, please report it.
Mark.