On Thu, 2015-06-11 at 19:10 +0300, Cristian Stoica wrote:
On 06/11/2015 06:38 PM, Greg KH wrote:
quoted
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