From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Data corruption on i.MX6 IPU in arm_copy_from_user()
Date: Wed, 26 May 2021 10:26:50 +0200 [thread overview]
Message-ID: <m3y2c1uchh.fsf@t19.piap.pl> (raw)
Hello,
I've encountered an interesting case of data corruption while accessing
IPU (Image Processing Unit) on i.MX6 (rev1.2, Cortex A9). What I'm doing
here is basically:
openat(AT_FDCWD, "/dev/mem", O_RDWR|O_SYNC) = 3
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x2630000) = ptr
write(1, ptr, 32) = 32
Normally, the write() should end up with:
04008A00 02FF03FF 02FF03FF 00000000 00000000 00000000 00000000 00000000
However, with current kernels, the first 32 bits (the first IPU
register) are dropped:
02FF03FF 02FF03FF 00000000 00000000 00000000 00000000 00000000 00000000
0x2630000 is IPU1 CSI0 address (i.e., a register block). The same
happens with other IPU regions. Writes shorter than 8 * 32 bits are not
affected.
write() uses arm_copy_from_user() and since commit f441882a5229:
ARM: 8812/1: Optimise copy_{from/to}_user for !CPU_USE_DOMAINS
ARMv6+ processors do not use CONFIG_CPU_USE_DOMAINS and use privileged
ldr/str instructions in copy_{from/to}_user. They are currently
unnecessarily using single ldr/str instructions and can use ldm/stm
instructions instead like memcpy does (but with appropriate fixup
tables).
apparently uses 8 * 32-bit ldmia instruction to copy data:
.macro ldr8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort
USERL(\abort, ldmia \ptr!, {\reg1, \reg2, \reg3, \reg4, \reg5, \reg6, \reg7, \reg8})
.endm
Before this commit it used ldr instruction (single 32-bit value) and the
problem didn't show up (reverting f441882a5229 on v5.11 fixes it as
well). The i.MX6 errata doesn't seem to list this problem.
I wonder what the theory says about this case. Is it at all valid to
read 8 IPU registers at a time using LDM instruction? If so, should
something be done with this problem, or should it be left as is?
--
Krzysztof Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
next reply other threads:[~2021-05-26 8:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 8:26 Krzysztof Hałasa [this message]
2021-05-26 10:08 ` Data corruption on i.MX6 IPU in arm_copy_from_user() Russell King (Oracle)
2021-05-26 12:29 ` Krzysztof Hałasa
2021-05-26 13:18 ` Russell King (Oracle)
2021-05-27 14:06 ` David Laight
2021-05-28 10:02 ` Krzysztof Hałasa
2021-05-28 14:35 ` Russell King (Oracle)
2021-05-31 4:30 ` Krzysztof Hałasa
2021-05-31 6:20 ` Krzysztof Hałasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3y2c1uchh.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox