On 06/12/2015 12:27 AM, Scott Wood wrote: > 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()).
Thanks for the explanation. I'll have a another look at the code. > 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? The analysis that lead to this patch was targeted to a specific driver - in hindsight this is probably not the best approach. Cristian S. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
