lkml.org 
[lkml]   [2021]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] mm: fix pfn calculation mistake in __ioremap_check_ram
Date


On 2021/6/7 21:55, Dave Hansen wrote:
> On 6/7/21 2:19 AM, Yaohui Wang wrote:
>> According to the source code in function
>> arch/x86/mm/ioremap.c:__ioremap_caller, after __ioremap_check_mem, if the
>> mem range is IORES_MAP_SYSTEM_RAM, then __ioremap_caller should fail. But
>> because of the pfn calculation problem, __ioremap_caller can success
>> on IORES_MAP_SYSTEM_RAM region when the @size parameter is less than
>> PAGE_SIZE. This may cause misuse of the ioremap function and raise the
>> risk of performance issues. For example, ioremap(phys, PAGE_SIZE-1) may
>> cause the direct memory mapping of @phys to be uncached, and iounmap won't
>> revert this change. This patch fixes this issue.
>>
>> In arch/x86/mm/ioremap.c:__ioremap_check_ram, start_pfn should wrap down
>> the res->start address, and end_pfn should wrap up the res->end address.
>> This makes the check more strict and should be more reasonable.
>
> Was this found by inspection, or was there a real-world bug which this
> patch addresses?
>

I did a performance test for linux kernel in many aspects. One of my
scripts is to test the performance influence of ioremap. I found that
applying ioremap on normal RAM may cause terrible performance issues.

To avoid memory cache behavior aliasing, ioremap will call
memtype_kernel_map_sync to sync the cache attribute in the directing
mapping, which causes:

1. If the phys addr is in a huge page in the directing mapping, then
ioremap will split the huge page into 4K pages.
2. It will set the PCD bit in the directing mapping pte.

Both the above behaviors will downgrade the performance of the machine,
especially when there is important code/data which is accessed
frequently. What's worse, iounmap won't clear the PCD bit in the
directing mapping pte, and I need to call ioremap_cache to clear the PCD
bit. All these should be avoided.

Another thing also confuses me:

From __ioremap_caller, we can see that __ioremap_caller don't allow us
to remap normal RAM. In my understanding, direct mapping only maps
normal RAM. So if the remap behavior is not allowed on normal RAM, it
should be unnecessary to call memtype_kernel_map_sync. Is this right?

\
 
 \ /
  Last update: 2021-06-08 06:05    [W:0.033 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site