lkml.org 
[lkml]   [2021]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] uio: Fix bus error that access memory mapped by physical
From
Date


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


\
 
 \ /
  Last update: 2021-06-24 11:50    [W:0.064 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site