Re: mmap() doesn't like certain value...

[DervishD]

    Hi Denis and Marcelo :)

>>     And is corrected just by inverting the two quoted code snips :)
>You are right

    I've added a couple of comments and one more test. I don't think
that mmap() should return 'addr' when len=0. Moreover, mmap() cannot
return '0' under *any* circumstance (so says the man page).

    I've tested the patch with a little program to test every
possible 'len' value and checking for mmap() returning the correct
value.

    This is the patch:

--- begin ---

--- mm/mmap.c.orig	2002-05-10 10:40:51.000000000 +0200
+++ mm/mmap.c	2002-05-10 10:47:54.000000000 +0200
@@ -389,6 +389,11 @@
 	return 0;
 }
 
+
+/*
+	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.
+*/
 unsigned long do_mmap_pgoff(struct file * file, unsigned long addr, unsigned long len,
 	unsigned long prot, unsigned long flags, unsigned long pgoff)
 {
@@ -402,12 +407,11 @@
 	if (file && (!file->f_op || !file->f_op->mmap))
 		return -ENODEV;
 
-	if ((len = PAGE_ALIGN(len)) == 0)
-		return addr;
-
-	if (len > TASK_SIZE)
+	if (!len || len > TASK_SIZE)
 		return -EINVAL;
 
+	len = PAGE_ALIGN(len);  /* This CANNOT be zero */
+
 	/* offset overflow? */
 	if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
 		return -EINVAL;

--- end ---

>>     I'll give a try to the inversion, that should work. I have
>> written a small stress program for mmap, so in a few hours the patch
>> will be ready. Must I post it here or send it directly to Marcello?
>Post here and to Marcelo. BTW, is 2.5 affected?

    I don't really know, but I'm pretty sure... Anyway I think that
the same patch is valid for both kernels with little or no
modification.

    BTW, the patch is not only mine, David Gómez Espinosa
([e-mail]) has helped me with this issue too.

    Raúl