From: DervishD <raul@pleyades.net>
To: Linus Torvalds <torvalds@transmeta.com>
Subject: [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note
Date: Mon, 21 Apr 2003 13:04:27 +0200 [thread overview]
Message-ID: <20030421110427.GA127@DervishD> (raw)
[-- 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;
next reply other threads:[~2003-05-27 9:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-21 11:04 DervishD [this message]
[not found] ` <20030615102039.GA1063@wohnheim.fh-wedel.de>
2003-06-16 9:49 ` [RESEND][PATCH] against mmap.c (do_mmap_pgoff) and a note DervishD
2003-06-16 11:33 ` Jörn Engel
2003-06-16 12:58 ` DervishD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030421110427.GA127@DervishD \
--to=raul@pleyades.net \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox