Re: [PATCH] uio: Fix bus error that access memory mapped by physical

[wubian]

On 2021/6/24 下午4:26, Will Deacon wrote:
> [FYI: this landed in my spam]
>
> On Wed, Jun 23, 2021 at 08:32:55PM +0800, wubian wrote:
> > On 2021/6/23 下午5:25, Greg KH wrote:
> > > On Wed, Jun 23, 2021 at 04:49:16PM +0800, wubian wrote:
> > > > I haven’t found this problem on the x86 platform. I only found it on arm64.
> > > > I used gdb to track memset and found that the bus error in
> > > > glibc/sysdeps/aarch64/memset.S: dc zva, dst; reference "Architecture
> > > > Reference ManualArmv8, for Armv8-A architecture profile" manual found that
> > > > the dc assembly instruction（performance optimization） is related to the
> > > > operation of the cache, that is to say, there is a bus error in the
> > > > operation of the cache, and then check the "ARM Cortex-A Series Programmer's
> > > > Guide for ARMv8-A " manual, found that the armv8 architecture cache has data
> > > > cache and write buffer, and there are two operation modes write-back and
> > > > write-through, write operations in these two modes, the data flow will pass
> > > > through the write buffer, and pgprot_noncached will prohibit data Cache and
> > > > write buffer, this causes the dc command in memset to fail (bus error), and
> > > > pgprot_writecombine does not prohibit write buffer, so the dc command in
> > > > memset is successfully operated when pgprot_writecombine is used.
> > >
> > > Are you sure this is not just a specific hardware platform issue?  Are
> > > you sure this is going to be correct for _ALL_ arm64 systems?
> > >
> > > Perhaps get the arm64 developers to agree with what is happening here as
> > > this is the first time anyone has reported this problem.
> > >
> > > What specific platform are you using that this issue happens on?
> > I apologize for the kernel mail reply format problem, I will pay attention
> > to it in the future.
> >
> > I only found this problem on Huawei Kunpeng 920 cpu at present, and found
> > that some people
> > have raised similar problems on the Internet.
> > link：https://github.com/ikwzm/udmabuf/issues/31
> >
> > @Catalin Marinas @Will Deacon Has anyone reported a similar problem on the
> > arm64 platform?
>
> The fundamental issue here (which seems related to [1]) is that you're
> mapping MMIO into userspace and then expecting to be able to use standard
> string routines such as memset and memcpy on them. This won't work, as the
> architecture (and likely the MMIO endpoint) has restrictions on things like
> unaligned accesses, access size and atomicity for MMIO that do not apply to
> normal memory.
>
> Returning non-cacheable rather than device mappings from UIO is likely to
> cause more problems than it solves, as it permits the CPU to make
> speculative accesses to the region. If the mapped device has side-effects,
> then this will end in disaster.
>
> So I don't think this patch is correct, and I think that if you're exposing
> MMIO to userspace then you need to be very careful about what you do with
> it rather than blindly pass MMIO pointers into standard routines that expect
> to operate on normal memory. There's a reason drivers usually live in the
> kernel :)
>
> Thanks,
>
> Will
>
> [1] https://lore.kernel.org/r/da9c2fa9-a545-0c48-4490-d6134cc31425@xxxxxxxxxx

Thank you very much for your reply,It gave me a deeper understanding of 
this problem.

--
Best regards,

wubian