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
next prev 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.