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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
