| commit | f81cff0d4067e41fd7383d9c013cc82da7c169d2 | |
| author | Mike Frysinger <vapier@gentoo.org> | |
| Wed, 6 Dec 2006 02:02:59 +0000 (6 12:02 +1000) | ||
| committer | Linus Torvalds <torvalds@woody.osdl.org> | |
| Wed, 6 Dec 2006 15:41:26 +0000 (6 07:41 -0800) | ||
| tree | 92c5c8a647e31be6b3e09dcce42ec261d43ad2f5 | treesnapshot (tar.gz zip) |
| parent | 3363c9b0ed8f6b5a241d63018cad242ae458cdf9 | commitdiff |
[PATCH] uclinux: fix mmap() of directory for nommu case
I was playing with blackfin when i hit a neat bug ... doing an open() on a
directory and then passing that fd to mmap() would cause the kernel to hang
after poking into the code a bit more, i found that
mm/nommu.c:validate_mmap_request() checks the length and if it is 0, just
returns the address ... this is in stark contrast to mmu's
mm/mmap.c:do_mmap_pgoff() where it returns -EINVAL for 0 length requests ...
i then noticed that some other parts of the logic is out of date between the
two funcs, so perhaps that's the easy fix ?
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I was playing with blackfin when i hit a neat bug ... doing an open() on a
directory and then passing that fd to mmap() would cause the kernel to hang
after poking into the code a bit more, i found that
mm/nommu.c:validate_mmap_request() checks the length and if it is 0, just
returns the address ... this is in stark contrast to mmu's
mm/mmap.c:do_mmap_pgoff() where it returns -EINVAL for 0 length requests ...
i then noticed that some other parts of the logic is out of date between the
two funcs, so perhaps that's the easy fix ?
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| mm/nommu.c | diffblobblamehistory |