Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   =?utf-8?Q?Krzysztof_Ha=C5=82asa?= <khalasa@piap.pl>
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc:     linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: Data corruption on i.MX6 IPU in arm_copy_from_user()
References: <m3y2c1uchh.fsf@t19.piap.pl>
        <20210526100843.GD30436@shell.armlinux.org.uk>
        <m3r1htu19o.fsf@t19.piap.pl>
        <20210526131853.GE30436@shell.armlinux.org.uk>
        <m3h7intbub.fsf@t19.piap.pl>
        <20210528143544.GQ30436@shell.armlinux.org.uk>
Sender: khalasa@piap.pl
Date:   Mon, 31 May 2021 06:30:10 +0200
In-Reply-To: <20210528143544.GQ30436@shell.armlinux.org.uk> (Russell King's
        message of "Fri, 28 May 2021 15:35:44 +0100")
Message-ID: <m35yyzttil.fsf@t19.piap.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

"Russell King (Oracle)" <linux@armlinux.org.uk> writes:

>> LDM12: 1 3 4 5 6 7 8 9 A B C D
>
> That's rather sad, and does look very much like a hardware bug.
>
> The question is what to do about it... there's Linus' "do not break
> userspace" edict and that's exactly what this change has done. So I
> suppose we're going to have to revert the change and put up with
> everything being slightly slower on arm32 than it otherwise would
> have been. That probably means we'll end up with almost every kernel
> tree out there carrying a revert of the revert to work around the
> fact that seemingly NXP broke their hardware - which itself is not
> a good idea. I guess we're just going to have to put up with that.

For userspace, it's quite a corner case, basically development-only -
and I guess there are very few people who will do things like this.

The same problem can manifest itself without any kernel involvement -
it's enough to mmap /dev/mem and use LDM on in completely in userspace.
This can't be fixed - unless we disallow IPU mmap.

Perhaps making sure the bug is clearly documented is better than doing
a partial fix. Ideally NXP should document it in their papers, and we
should add notes to IPU driver code.

The last one - I guess I can do.
--=20
Krzysztof Ha=C5=82asa

Sie=C4=87 Badawcza =C5=81ukasiewicz
Przemys=C5=82owy Instytut Automatyki i Pomiar=C3=B3w PIAP
Al. Jerozolimskie 202, 02-486 Warszawa