lkml.org 
[lkml]   [1998]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.058 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site