Messages in this thread | | | Date | Tue, 10 Dec 2002 12:47:40 -0800 (PST) | Subject | Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction | From | "David S. Miller" <> |
| |
From: DervishD <raul@pleyades.net> Date: Tue, 10 Dec 2002 21:45:30 +0100
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |