All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com,
	linux-kernel@vger.kernel.org, matthew@wil.cx,
	macro@linux-mips.org, kamezawa.hiroyu@jp.fujitsu.com,
	eike-kernel@sf-tec.de, linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/2] x86: ioremap: fix wrong physical address handling
Date: Fri, 18 Jun 2010 12:07:43 +0100	[thread overview]
Message-ID: <4C1B537F.30300@goop.org> (raw)
In-Reply-To: <4C1AE680.7090408@jp.fujitsu.com>

On 06/18/2010 04:22 AM, Kenji Kaneshige wrote:
> Current x86 ioremap() doesn't handle physical address higher than
> 32-bit properly in X86_32 PAE mode. When physical address higher than
> 32-bit is passed to ioremap(), higher 32-bits in physical address is
> cleared wrongly. Due to this bug, ioremap() can map wrong address to
> linear address space.
>
> In my case, 64-bit MMIO region was assigned to a PCI device (ioat
> device) on my system. Because of the ioremap()'s bug, wrong physical
> address (instead of MMIO region) was mapped to linear address space.
> Because of this, loading ioatdma driver caused unexpected behavior
> (kernel panic, kernel hangup, ...).
>
> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
>
> ---
>  arch/x86/mm/ioremap.c   |   12 +++++-------
>  include/linux/io.h      |    4 ++--
>  include/linux/vmalloc.h |    2 +-
>  lib/ioremap.c           |   10 +++++-----
>  mm/vmalloc.c            |    2 +-
>  5 files changed, 14 insertions(+), 16 deletions(-)
>
> Index: linux-2.6.34/arch/x86/mm/ioremap.c
> ===================================================================
> --- linux-2.6.34.orig/arch/x86/mm/ioremap.c
> +++ linux-2.6.34/arch/x86/mm/ioremap.c
> @@ -62,8 +62,8 @@ int ioremap_change_attr(unsigned long va
>  static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>  		unsigned long size, unsigned long prot_val, void *caller)
>  {
> -	unsigned long pfn, offset, vaddr;
> -	resource_size_t last_addr;
> +	unsigned long offset, vaddr;
> +	resource_size_t pfn, last_pfn, last_addr;
>   

Why is pfn resource_size_t here? Is it to avoid casting, or does it
actually need to hold more than 32 bits? I don't see any use of pfn
aside from the page_is_ram loop, and I don't think that can go beyond 32
bits. If you're worried about boundary conditions at the 2^44 limit,
then you can make last_pfn inclusive, or compute num_pages and use that
for the loop condition.

>  	const resource_size_t unaligned_phys_addr = phys_addr;
>  	const unsigned long unaligned_size = size;
>  	struct vm_struct *area;
> @@ -100,10 +100,8 @@ static void __iomem *__ioremap_caller(re
>  	/*
>  	 * Don't allow anybody to remap normal RAM that we're using..
>  	 */
> -	for (pfn = phys_addr >> PAGE_SHIFT;
> -				(pfn << PAGE_SHIFT) < (last_addr & PAGE_MASK);
> -				pfn++) {
> -
> +	last_pfn = last_addr >> PAGE_SHIFT;
>   

If last_addr can be non-page aligned, should it be rounding up to the
next pfn rather than rounding down? Ah, looks like you fix it in the
second patch.

J

  reply	other threads:[~2010-06-18 11:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18  3:21 [BUG][PATCH 0/2 (v.3)] x86: ioremap() problem in X86_32 PAE Kenji Kaneshige
2010-06-18  3:22 ` [PATCH 1/2] x86: ioremap: fix wrong physical address handling Kenji Kaneshige
2010-06-18 11:07   ` Jeremy Fitzhardinge [this message]
2010-06-21  1:40     ` Kenji Kaneshige
2010-07-09 19:18   ` [tip:x86/mm] x86, ioremap: Fix incorrect physical address handling in PAE mode tip-bot for Kenji Kaneshige
2010-06-18  3:23 ` [PATCH 2/2] x86: ioremap: fix normal ram range check Kenji Kaneshige
2010-07-09 19:19   ` [tip:x86/mm] x86, ioremap: Fix " tip-bot for Kenji Kaneshige
2010-06-18  6:31 ` [BUG][PATCH 0/2 (v.3)] x86: ioremap() problem in X86_32 PAE H. Peter Anvin
2011-02-10 14:11 ` TAKADA Yoshihito
2011-02-11  7:55   ` Kenji Kaneshige
  -- strict thread matches above, loose matches on Subject: below --
2010-06-17  1:28 [BUG][PATCH 0/2 (v.2)] " Kenji Kaneshige
2010-06-17  1:30 ` [PATCH 1/2] x86: ioremap: fix wrong physical address handling Kenji Kaneshige
2010-06-17  2:50   ` Matthew Wilcox
2010-06-17  4:22     ` H. Peter Anvin
2010-06-17  4:55       ` Kenji Kaneshige
2010-06-17  6:03         ` H. Peter Anvin
2010-06-17  6:21           ` Kenji Kaneshige
2010-06-17  9:35           ` Jeremy Fitzhardinge
2010-06-17  9:38             ` Jeremy Fitzhardinge
2010-06-17 13:46             ` H. Peter Anvin
2010-06-18  0:32               ` Kenji Kaneshige
2010-06-18  0:22             ` Kenji Kaneshige
2010-07-09  4:24             ` Simon Horman
2010-07-09  5:33               ` Jeremy Fitzhardinge
2010-07-09  6:10                 ` Simon Horman
2010-06-17  6:28     ` Kenji Kaneshige

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=4C1B537F.30300@goop.org \
    --to=jeremy@goop.org \
    --cc=eike-kernel@sf-tec.de \
    --cc=hpa@zytor.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=matthew@wil.cx \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.