question about potential integer truncation in default_erasesize

[Brian Norris]

On Sat, Sep 26, 2015 at 03:18:08PM +0200, PaX Team wrote:
> hi all,
> 
> drivers/mtd/chips/map_rom.c:default_erasesize can truncate map_info.size
> from unsigned long to unsigned int on 64 bit archs and i'm wondering if
> this is intentional or should/could map_info.size be turned into an unsigned
> int field? FTR, this issue was detected with the upcoming version of the
> size overflow plugin we have in PaX/grsecurity and there're a handful of
> similar cases in the tree where potentially unwanted or unnecessary integer
> truncations occur, this being one of these. any opinion/help is welcome!

This is being assigned to the erasesize, which is 32-bit already, and
all of MTD expects a 32-bit erasesize, so it'd be a pretty big job to
"fix" the truncation. But really, we can't handle (and shouldn't;
there's really no need) >32-bit eraseblocks. That would be an
un-manageable flash geometry.

Regards,
Brian