> > + * 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.
With my patch, we don't use a zero length :?? My patch sees if
PAGE_ALIGN will f*ck the length, and if so, it returns EINVAL. This
is better than getting '0' as a valid address when specifying a large
size, don't you think so?
> 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?
Because PAGE_ALIGN won't return 0? I don't see your assumption of
'len' going to zero due to my patch :?? With my patch, if the
requested size is '0', then the hint address is returned, and if the
size is so high that PAGE_ALIGN will barf at it, returning 0 when it
shouldn't, mmap will return EINVAL. The function never uses a 'len'
of 0. Never.
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/