[lkml]   [2021]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH v2 0/2] mm: unexpected behavior of __ioremap_caller
Due to some boundary calculation & boundary judgment issues,
__ioremap_caller may not work as expected. This may raise the risk of
misusing ioremap_xxx functions, and further, incur terrible performance

For example, suppose [phys_addr ~ phys_addr + PAGE_SIZE] is normal RAM.
Calling ioremap(phys_addr, PAGE_SIZE-1) will succeed (but it should not).
This will set the cache flag of the phys_addr's directing mapping pte to
be PCD. What's worse, iounmap won't revert this cache flag in the
directing mapping. So the pte in the directing mapping keeps polluted
until we use workarounds (calling ioremap_cache on phys_addr) to fix the
cache bit. If there is important data/code in the polluted page, which is
accessed frequently, then the performance of the machine will drop

Here are two patches addressing this issue. The first address the boundary
calculation issue and the second one addresses the boundary judgment

Yahui Wang (2):
mm: fix pfn calculation mistake in __ioremap_check_ram
mm: fix boundary judgement issues

arch/x86/mm/ioremap.c | 4 ++--
kernel/resource.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)


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