Re: [RFC PATCH] arm: i.MX6 Cortex-A9: Fix memory ordering inconsistency by disabling prefetch instructions

[Arnd Bergmann]

On Mon, Jul 18, 2022 at 4:51 PM Mathieu Desnoyers
<mathieu.desnoyers@xxxxxxxxxxxx> wrote:

> Request for Feedback
> ====================
>
> This fix targets all i.MX configurations, but it is likely too broad (or
> too narrow). It would be great if people with access to different
> Freescale i.MX test boards, and test boards from other vendors, could try
> to reproduce the issue to figure out what would be the right scope for
> this fix.
>
> It would also be great if people with knowledge of the ARM CPU internals
> could help understanding whether this fix really fixes an issue between
> prefetch and memory barriers, or just happens to hide the issue. It
> would be good to understand whether this issue only affects PLDW or if
> it also affects the PLD instruction.

I don't have any relevant hardware at hand, but looked at this for a few
hours today, unfortunately without any notable success. Just documenting
what I did here:

- looked at the errata lists for cortex-a9 r2, for pl310 and for
imxq6q to see if
  anything stuck out. I assume you've already done the same, but I can confirm
  that the errata that would match the symptom are listed as fixed in r2p10
  or earlier.

- looked at objdump output from
  linux-image-5.18.0-0.bpo.1-armmp_5.18.2-1~bpo11+1_armhf.deb
  (not the same version, but hopefully be close enough), and compared that
  to v5.18.2 built with the same config using gcc-7.5 and gcc-10.3 to
  see if I could tell what is different. The output looks very similar, though
  my own gcc-10 apparently fails to inline arch_futex_atomic_op_inuser()
  and futex_atomic_op_inuser(). This looks like something we may want
  to force-inline in principle, but it seems unrelated to the bug you found
  since the debian vmlinux has these functions inlined and I don't think
  they are actually part of the broken code path.

- looked for other quad-core Cortex-A9 SoCs to find someone with a
  similar revision to check if they have the same bug. The closest I
  can  think of is the OMAP4 that uses an A9 r1p2.

- Looked at the disabled errata handling in arch/arm/Kconfig.
  Unfortunately a couple of the workarounds we have there are
  now always disabled because of a dependency on
  ARCH_MULTIPLATFORM. It's a long shot, but you could try
  removing the dependencies and enabling all the Cortex-A9
  fixes like ARM_ERRATA_742230, ARM_ERRATA_742231,
  ARM_ERRATA_743622, ARM_ERRATA_751472, and
  ARM_ERRATA_754327.

        Arnd