Messages in this thread | | | Date | Fri, 29 May 1998 18:03:48 -0400 | From | Natarajan Krishnaswami <> | Subject | Re: mmap bug? |
| |
>>>>> "Dean" == Dean Gaudet <dgaudet-list-linux-kernel@arctic.org> writes:
Dean> (I can't find a reference which claims that 0 is not Dean> a valid response.)
From the S.U.S. ver. 2: When the implementation selects a value for pa, it never places a mapping at address 0, nor does it replace any extant mapping.
>>>>> "Chris" == Chris Evans <chris@ferret.lmh.ox.ac.uk> writes:
Chris> On Fri, 29 May 1998, Dean Gaudet wrote:
Chris> I'm surprised you've failed to read the thread properly. As Chris> mentioned, the problem is in glibc. It stat()'s a file then Chris> mmap()'s it with the length returned by stat. I think it Chris> assumes a certain length on the file...
I don't think he has misread the thread. Mr. Gaudet's question was not 'why are you requesting a zero-length map?' but 'why are you dereferencing a pointer in a zero-length map?'. Any program that dereferences an address in (of?) a 0-length map is broken. Glibc should check the length of the map. That Linux is broken in returning 0 does not make glibc less broken for not checking the size of the map.
After looking at the do_mmap source: making zero length a special case is kind of broken: the map must increase the reference-count of the file associated with the descriptor, so to support properly mmap semantics for zero-length maps, they should be unique. (Unfortunately, this is potentially ugly.)
If it will not be supported , I think ENXIO should be used.
(Also, the "offset overflow" case should probably return EOVERFLOW (or perhaps ENXIO) rather than EINVAL.)
TTYL, N.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |