mmap bug (all archs) w/ fix

Michael Galassi mgalassi at
Wed Jan 31 13:54:43 EST 2007

When we need to update flash on our system we use a utility which opens
/dev/mem, mmaps the region of physical memory which contains flash (top
128meg), and then does all the ugly magic to erase/write/verify.  As we
were implementing this we discovered that it is not possible to mmap a
chunk of physical addresses which ends at the top of the proc's space
(where we (and everyone else on this list) have our boot loader).  I
finally got around to looking at why this might be and found that
whoever implemented mmap got lazy.  The diff which follows is against a
fully patched MontaVista pro 4.0.1 kernel, I just checked and the exact
same fix is applicable to 2.6.20-rc6.

Index: mmap.c
RCS file: /CVSR1/SuperQAM/SW/src/sys/mvl401/mm/mmap.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -w -u -r1.1 -r1.2
--- mmap.c      9 Aug 2006 02:26:09 -0000       1.1
+++ mmap.c      30 Jan 2007 23:42:53 -0000      1.2
@@ -803,7 +803,8 @@
                return -ENOMEM;

        /* offset overflow? */
-       if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
+       if ((pgoff + (len >> PAGE_SHIFT)) < pgoff &&
+           (pgoff + (len >> PAGE_SHIFT)) != 0)
                return -EOVERFLOW;

        /* Too many mappings? */

This clearly applies to all architectures and all versions (at least 2.4
onward), could someone point me at some document which describes how to
submit patches to "the right place" please?  I really do not want to
support any fixes myself so getting fixes to obvious bugs merged into
the mailine code would be a good thing (tm).



More information about the Linuxppc-embedded mailing list