While writing a test program I used mmap using SIZE_MAX (which isthe maximum value storeable in a size_t variable) as the length, justto see when mmap starts failing with EINVAL or ENOMEM.

Well, mmap() acted quite good and reasonable and gave me thevalues I was searching for... except when a value of SIZE_MAX-4095 orhigher is passed to it.

I've taken a look at the kernel sources and in the filemm/mmap.c, in the function do_mmap_pgoff, the length supplied is pagealigned (thru the macro PAGE_ALIGN). But this macro correctly saysthat when we are at address SIZE_MAX-4095 or higher the next page inthe addressable space is the page at address 0. But we are dealingwith *sizes*, not addresses.

The matter is that mmap() doesn't fail with values ofSIZE_MAX-4095 and higher (as it should do), but succeeds returning'0' as the address... This is due the calculus that PAGE_ALIGN doeswith the enormous length passed (namely 4294963200 or higher, up tothe limit marked by SIZE_MAX: 2^32-1). This macro cannot be used withnumbers near to the limit. mmap() should return -1 and set errno toEINVAL, as properly does when the enormous length is less than2^32-4096.

I know: this lengths are enormous, nobody uses them, etc... but Ithink that mmap shouldn't behave as bad just because nobody will usethe entire domain of the function. If the length domain is [0, 2^32)the function should behave correctly, returning errors asappropriate, not succeeding falsely. So please consider correctingthe problem (should suffice with eliminating the use of PAGE_ALIGN oradding special cases to the test prior to its use).

If this is not a bug, but an intended behaviour please excuse me.Moreover, I can provide a patch (I suppose) against the 2.4.18 tree.