Message-ID: <2a57f130-315c-7180-faba-44507cc3817a@uniontech.com>
Date:   Thu, 24 Jun 2021 17:48:20 +0800
From:   wubian <wubian@...ontech.com>
To:     Will Deacon <will@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
        catalin.marinas@....com, mark.rutland@....com,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] uio: Fix bus error that access memory mapped by physical



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@huawei.com
> 
> 

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

-- 
Best regards,

wubian

Powered by blists - more mailing lists