All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Cristian Stoica <cristian.stoica@freescale.com>
Cc: <linuxppc-dev@lists.ozlabs.org>, <linux-kernel@vger.kernel.org>,
	<horia.geanta@freescale.com>
Subject: Re: [PATCH v2] powerpc: support sizes greater than an unsigned long
Date: Thu, 11 Jun 2015 16:27:55 -0500	[thread overview]
Message-ID: <1434058075.2477.178.camel@freescale.com> (raw)
In-Reply-To: <5579B2FC.4010008@freescale.com>

On Thu, 2015-06-11 at 19:10 +0300, Cristian Stoica wrote:
> On 06/11/2015 06:38 PM, Greg KH wrote:
> > On Thu, Jun 11, 2015 at 05:42:00PM +0300, Cristian Stoica wrote:
> > 
> > Why?
> > 
> 
> This patch matches the input argument "size" of ioremap() with the 
> output of request_mem_region() (which is
> resource_size_t).
> Since the latter is used as input to the former, the types should 
> match (even though mapping more than 4G is not usually
> expected). There are a lot of such differences in the code and this 
> is an attempt to reduce that.

Dropping the upper bits of the size harms the ability to detect error 
scenarios where unmappably large -- but not power-of-two -- regions 
are requested to be mapped.

However, this patch doesn't fix that.  It just postpones the loss of 
the upper 32 bits until __ioremap_caller() calls get_vm_area_caller().

There's also no error checking at all for the size of ioremap() done 
during early boot (!slab_is_available()).

Don't just blindly turn static analyzer reports into patches -- and 
why didn't the analyzer complain about the call to 
get_vm_area_caller() after this patch?

-Scott

  parent reply	other threads:[~2015-06-11 21:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 16:24 [PATCH] powerpc: support sizes greater than an unsigned long Cristian Stoica
2015-05-14 16:24 ` Cristian Stoica
2015-05-15  9:44 ` [PATCH v2] " Cristian Stoica
2015-05-15  9:44   ` Cristian Stoica
2015-06-11 14:42   ` Cristian Stoica
2015-06-11 15:38     ` Greg KH
2015-06-11 16:10       ` Cristian Stoica
2015-06-11 16:17         ` Greg KH
2015-06-11 21:27         ` Scott Wood [this message]
2015-06-12  7:53           ` Cristian Stoica

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=1434058075.2477.178.camel@freescale.com \
    --to=scottwood@freescale.com \
    --cc=cristian.stoica@freescale.com \
    --cc=horia.geanta@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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 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.