* [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note
@ 2003-04-21 11:04 DervishD
[not found] ` <20030615102039.GA1063@wohnheim.fh-wedel.de>
0 siblings, 1 reply; 4+ messages in thread
From: DervishD @ 2003-04-21 11:04 UTC (permalink / raw)
To: Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
Hi Linus :)
I've noticed that in file 'mm/mmap.c', at the comments for
function 'can_vma_merge_before' this can be read:
<quote>
* We don't check here for the merged mmap wrapping around the end of pagecache
* indices (16TB on ia32) because do_mmap_pgoff() does not permit mmap's which
* wrap, nor mmaps which cover the final page at index -1UL.
*/
</quote>
Well, the patch I sent you against 2.5.60 and that I'm resending,
since it's not included at 2.5.68, fixed a mmap() corner case bug,
that made mmap() fail for large sizes (as did a previous patch that
you did apply) and that works even if 'TASK_SIZE' is the entire
address space (as seems the case at sparc64, for example). The
problem is that with the patch you already applied and with the new
patch I send, you cannot do a mmap that wraps, but you can mmap the
final page (not at index -1UL, there is not such index!, -1
unsigned?). In fact, you can mmap your entire address space if you
want.
Without the patch you already applied any such 'big' mmap will
silently fail, and with the new, if the arch doesn't want such a big
mmap it will return EINVAL.
I think the problem in 'can_vma_merge_before' is just the comment
(for me it sounds ambiguous), but the other problem, with archs like
sparc64, still is an issue. Dave Miller pointed this although I made
the patch. Please apply, the semantics of 'do_mmap_pgoff' doesn't
change a bit, is just that the current code will silently fail for
sparc64 and other archs where TASK_SIZE is the entire address space.
Thanks a lot and happy coding :)
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
[-- Attachment #2: mmap.c.2.5.68.diff --]
[-- Type: text/plain, Size: 472 bytes --]
--- linux/mm/mmap.c.orig 2002-12-11 14:27:04.000000000 +0100
+++ linux/mm/mmap.c 2002-12-11 14:28:09.000000000 +0100
@@ -421,14 +421,14 @@
if (file && (!file->f_op || !file->f_op->mmap))
return -ENODEV;
- if (!len)
+ if (len == 0)
return addr;
- if (len > TASK_SIZE)
- return -EINVAL;
-
len = PAGE_ALIGN(len);
+ if (len > TASK_SIZE || len == 0)
+ return -EINVAL;
+
/* offset overflow? */
if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
return -EINVAL;
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <20030615102039.GA1063@wohnheim.fh-wedel.de>]
* Re: [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note [not found] ` <20030615102039.GA1063@wohnheim.fh-wedel.de> @ 2003-06-16 9:49 ` DervishD 2003-06-16 11:33 ` Jörn Engel 0 siblings, 1 reply; 4+ messages in thread From: DervishD @ 2003-06-16 9:49 UTC (permalink / raw) To: Jörn Engel; +Cc: Linus Torvalds, Linux-kernel * Jörn Engel <joern@wohnheim.fh-wedel.de> dixit: > > - if (!len) > > + if (len == 0) > No change. Just cosmethic, ask Dave S. Miller, he is the author of the change, I'm just doing the patch for him. > > return addr; > > > > - if (len > TASK_SIZE) > > - return -EINVAL; > > - > > len = PAGE_ALIGN(len); > > > > + if (len > TASK_SIZE || len == 0) > > + return -EINVAL; > > + > > PAGE_ALIGN(0) = 0 > PAGE_ALIGN(1) = PAGE_SIZE > > Again, no change. There is a change in archs where TASK_SIZE is the entire addressable space (like sparc64). Ask Dave S., again. The problem did arise when TASK_SIZE is ~0. Then semantics change. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note 2003-06-16 9:49 ` DervishD @ 2003-06-16 11:33 ` Jörn Engel 2003-06-16 12:58 ` DervishD 0 siblings, 1 reply; 4+ messages in thread From: Jörn Engel @ 2003-06-16 11:33 UTC (permalink / raw) To: DervishD; +Cc: Linus Torvalds, Linux-kernel On Mon, 16 June 2003 11:49:11 +0200, DervishD wrote: > * Jörn Engel <joern@wohnheim.fh-wedel.de> dixit: > > > > return addr; > > > > > > - if (len > TASK_SIZE) > > > - return -EINVAL; > > > - > > > len = PAGE_ALIGN(len); > > > > > > + if (len > TASK_SIZE || len == 0) > > > + return -EINVAL; > > > + > > > > PAGE_ALIGN(0) = 0 > > PAGE_ALIGN(1) = PAGE_SIZE > > > > Again, no change. > > There is a change in archs where TASK_SIZE is the entire > addressable space (like sparc64). Ask Dave S., again. The problem did > arise when TASK_SIZE is ~0. Then semantics change. True. PAGE_ALIGN(-1) = 0 and that case would not get caught with the old code. Looks good to me. Jörn -- Public Domain - Free as in Beer General Public - Free as in Speech BSD License - Free as in Enterprise Shared Source - Free as in "Work will make you..." ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note 2003-06-16 11:33 ` Jörn Engel @ 2003-06-16 12:58 ` DervishD 0 siblings, 0 replies; 4+ messages in thread From: DervishD @ 2003-06-16 12:58 UTC (permalink / raw) To: Jörn Engel; +Cc: Linus Torvalds, Linux-kernel Hi Jörn :) * Jörn Engel <joern@wohnheim.fh-wedel.de> dixit: > > There is a change in archs where TASK_SIZE is the entire > > addressable space (like sparc64). Ask Dave S., again. The problem did > > arise when TASK_SIZE is ~0. Then semantics change. > True. PAGE_ALIGN(-1) = 0 and that case would not get caught with the > old code. Looks good to me. This was pointed to me by Dave. I prepared a patch time ago just for the case where 'len' was quite large, but I assumed that TASK_SIZE was at least one less page than the entire addressable space, which is not true. My fault O:)) Thanks for pointing, anyway. > Public Domain - Free as in Beer > General Public - Free as in Speech > BSD License - Free as in Enterprise > Shared Source - Free as in "Work will make you..." Good one ;)))) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-06-16 12:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-21 11:04 [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note DervishD
[not found] ` <20030615102039.GA1063@wohnheim.fh-wedel.de>
2003-06-16 9:49 ` DervishD
2003-06-16 11:33 ` Jörn Engel
2003-06-16 12:58 ` DervishD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox