linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yaohui Wang <yaohuiwang@linux.alibaba.com>
To: dave.hansen@linux.intel.com, tglx@linutronix.de
Cc: luto@kernel.org, peterz@infradead.org, mingo@redhat.com,
	bp@alien8.de, x86@kernel.org, linux-kernel@vger.kernel.org,
	luoben@linux.alibaba.com, yaohuiwang@linux.alibaba.com
Subject: [PATCH v3 0/2] x86/ioremap: fix boundary calculation and boundary judgment issues for ioremap()
Date: Mon, 21 Jun 2021 20:34:17 +0800	[thread overview]
Message-ID: <20210621123419.2976-1-yaohuiwang@linux.alibaba.com> (raw)

ioremap_xxx() functions should fail if the memory address range contains
normal RAM. But due to some boundary calculation and boundary judgment
issues, the RAM check may be omitted for the very start or the very end
page in the memory range. As a consequence, ioremap_xxx() can be applied
to normal RAM pages by mistake. This raises the risk of misusing
ioremap_xxx() functions on normal RAM ranges, and may incur terrible
performance issues.

For example, suppose [phys_addr ~ phys_addr + PAGE_SIZE - 1] is a normal
RAM page. 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 workarounds are applied (by invoking 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.

These two patches aim to address this issue. 

Yahui Wang (2):
  x86/ioremap: fix the pfn calculation mistake in __ioremap_check_ram()
  kernel/resource: fix boundary judgment issues in find_next_iomem_res()
    and __walk_iomem_res_desc()

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


base-commit: 13311e74253fe64329390df80bed3f07314ddd61
-- 
2.25.1


             reply	other threads:[~2021-06-21 12:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 12:34 Yaohui Wang [this message]
2021-06-21 12:34 ` [PATCH v3 1/2] x86/ioremap: fix the pfn calculation mistake in __ioremap_check_ram() Yaohui Wang
2021-07-01 14:41   ` Dave Hansen
2021-07-02 10:05     ` Yaohui Wang
2021-07-02 14:49       ` Dave Hansen
2021-07-05  2:11         ` Yaohui Wang
2021-06-21 12:34 ` [PATCH v3 2/2] kernel/resource: fix boundary judgment issues in find_next_iomem_res() and __walk_iomem_res_desc() Yaohui Wang
2021-07-01 16:29   ` Dave Hansen
2021-07-01  2:44 ` [PATCH v3 0/2] x86/ioremap: fix boundary calculation and boundary judgment issues for ioremap() Yaohui Wang

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=20210621123419.2976-1-yaohuiwang@linux.alibaba.com \
    --to=yaohuiwang@linux.alibaba.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luoben@linux.alibaba.com \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).