Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Yaohui Wang <yaohuiwang@linux.alibaba.com>
To:     dave.hansen@linux.intel.com
Cc:     luto@kernel.org, peterz@infradead.org, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/2] mm: unexpected behavior of __ioremap_caller
Date:   Fri, 11 Jun 2021 12:21:45 +0800
Message-Id: <20210611042147.80744-1-yaohuiwang@linux.alibaba.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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
issues.

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
terribly.

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

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(-)

-- 
2.25.1