From: wubian <wubian@uniontech.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uio: Fix bus error that access memory mapped by physical
Date: Wed, 23 Jun 2021 16:49:16 +0800 [thread overview]
Message-ID: <5a2737e1-2a77-98b0-eea7-eae04d7a9fba@uniontech.com> (raw)
In-Reply-To: <YNLfVX5YVWouP1qD@kroah.com>
First,thanks for your reply
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.
Regarding the bugfix issue, this is my first kernel patch submission, I
may not be too clear about the boundary of the kernel bugfix. I think
this issue is a bug, so I classify this submission as a bugfix. At last
hope to get your suggestion.
thanks,
wubian
On 2021/6/23 下午3:14, Greg KH wrote:
> On Wed, Jun 23, 2021 at 02:52:14PM +0800, wubian wrote:
>> On the arm64, register the uio driver and map a physical space
>> on the pci device to user space, then use memset write data to
>> the address space, a bus error will occur. This error is due to
>> the dc instruction(cache operation) used in the assembly of memset,
>> uio mapping physical memory will call pgprot_noncached() to set
>> non-cached and non-buffered, while pgprot_writecombine() has fewer
>> restrictions. It does not prohibit write buffer, so replacing
>> pgprot_noncached() with pgprot_writecombine() can solve this problem.
>>
>> Signed-off-by: wubian <wubian@uniontech.com>
>> ---
>> drivers/uio/uio.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index ea96e319c8a0..09b04b20fa30 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -739,7 +739,11 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
>>
>> vma->vm_ops = &uio_physical_vm_ops;
>> if (idev->info->mem[mi].memtype == UIO_MEM_PHYS)
>> +#if defined(CONFIG_ARM64)
>> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
>> +#else
>> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> +#endif
> This feels really wrong, shouldn't stuff like this be handled in the
> platform itself and not in the driver?
>
> And why is ARM64 special here? Why not other arches? What is odd about
> this platform? We almost never want to use #if in .c files, why is it
> ok to do that here?
>
> And is this a bugfix? If so, what commit does it fix? Should it go to
> stable kernels, and if so, how far back?
>
> I need more information here :)
>
> thanks,
>
> greg k-h
>
>
next prev parent reply other threads:[~2021-06-23 8:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 6:52 [PATCH] uio: Fix bus error that access memory mapped by physical wubian
2021-06-23 7:14 ` Greg KH
2021-06-23 8:49 ` wubian [this message]
2021-06-23 9:25 ` Greg KH
2021-06-23 12:32 ` wubian
2021-06-24 8:26 ` Will Deacon
2021-06-24 9:48 ` wubian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5a2737e1-2a77-98b0-eea7-eae04d7a9fba@uniontech.com \
--to=wubian@uniontech.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox