Messages in this thread | | | Subject | Re: [PATCH] uio: Fix bus error that access memory mapped by physical | From | wubian <> | Date | Thu, 24 Jun 2021 17:48:20 +0800 |
| |
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
| |