From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 26 Sep 2006 21:44:09 +0100 (BST) From: Hugh Dickins Subject: Re: [RFC/PATCH mmap2: better determine overflow In-Reply-To: <20060926120834.df719e85.rdunlap@xenotime.net> Message-ID: References: <20060926103504.82bd9409.rdunlap@xenotime.net> <20060926120834.df719e85.rdunlap@xenotime.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Randy Dunlap Cc: linux-mm@kvack.org, akpm List-ID: On Tue, 26 Sep 2006, Randy Dunlap wrote: > > It was an interpretation. Perhaps a mis-interpretation. > This comes after: > > if (!len) > return -EINVAL; > ...then > > len = PAGE_ALIGN(len); > b: > - if (!len || len > TASK_SIZE) > - return -ENOMEM; > + if (!len) > + return -EOVERFLOW; > > so if len is 0 at b:, then it was a very large unsigned long number > (larger than 0 - PAGE_SIZE, i.e., >= 0xfffff001 on 32-bit or > >= 0xffffffff_fffff001 on 64-bit), and PAGE_ALIGN() rounded it "up" > to 0. That seems more like an overflow than a NOMEM to me. > That's all. I agree that len 0 at that point arises from an extremely big len specified by the user: it's just another case of len > TASK_SIZE that the preceding PAGE_ALIGN has now disguised as len 0. And the errno for "there is insufficient room in the address space to effect the mapping" is said to be ENOMEM. That should stay. > > So, I'm interested in the EOVERFLOW case(s). > Would you attempt to translate this return value case for me? > (from http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html:) > > [EOVERFLOW] > The file is a regular file and the value of off plus len exceeds the offset maximum established in the open file description associated with fildes. > > I'm not concerned about the "off plus len" since I am looking at > mmap2() [using pgoff's instead]. I'm more concerned about the > "offset maximum established in the open file description associated > with fildes." I suspect it means that on a 32-bit system, if the file was not opened with O_LARGEFILE, off-plus-len needs to stay within 2GB. Whereas on a 64-bit system, or when opened with O_LARGEFILE, off-plus-len needs to stay within the max the filesystem and VFS can support. We're enforcing the latter, without regard to whether or not it was opened with O_LARGEFILE. Change that? I doubt it's worth the possibility of now breaking userspace. > > Does mmap2() on Linux use the actual filesize as a limit for the > mmap() area [not that I can see] That's right, it does not (and would be wrong to do so: the file can be extended or truncated while it's mapped). > or does it just use (effectively) > ULONG_MAX, without regard file actual filesize? I'd say that limit is TASK_SIZE rather than ULONG_MAX. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org