Hi David :)
> + * NOTE: in this function we rely on TASK_SIZE being lower than
> + * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
> This assumption is wrong.
OK, then another way of fixing the corner case that exists in
do_mmap_pgoff is needed. You cannot mmap a chunk of memory whose size
is bigger than SIZE_MAX-PAGE_SIZE, because 'PAGE_ALIGN' will return 0
when page-aligning the size.
And after your patch, we'd use a zero length. That is a bug.
Anyway you cannot use a size larger than SIZE_MAX-PAGE_SIZE even
on sparc64, since mmap will fail when page aligning such a size,
returning 0 :((( Reverting the change is worse (IMHO).
This is wrong.
I said that the address space can be this huge size. I didn't
say that this means such a huge single mmap() could work.
It makes that your assumption that allows for the code change
you made is invalid.
if ((len = PAGE_ALIGN(len)) == 0)
and this returns 0 if the requested size ('len', here) is between
SIZE_MAX-PAGE_SIZE and SIZE_MAX. And this is wrong.
And your change causes us to use a len of "zero" in this case, how is
that more valid?
Look at what happens, you PAGE_ALIGN(len) after all the range checks
then we use a len of '0' for the rest of the function. How is that
supposed to be better?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/