On Wed, Nov 27, 2013 at 7:38 AM, Holger Brunck <holger.brunck@xxxxxxxxxxx> wrote: > > And I wrote a simple main program which tries to mmap this uio device after > loading the kernel module. Your user program and kernel module is horribly horribly broken. You cannot map 128 bytes. By *definition* a mmap maps whole pages. That's how the hardware works. There is no "map byte granularity". It's all about pages. So if you say that you have a 128-byte device, then there's no way it can be mmap'ed, because mmap would map the following 3968 bytes too, and now your user program could read and write that memory that contains random kernel or IO data. So your device memory needs to be: - page-aligned (and right now we don't check that, because I was assuming everybody understood that) - and you can only mmap up to the last full page. The example driver you point to: https://lkml.org/lkml/2012/8/29/258 doesn't have that issue. The area it tries to mmap is page-aligned in size and base. So in fact this thread has convinced me that we need to *tighten* the requirements rather than loosen them. We should do the attached patch that verifies that the memory base is page-aligned, because if it isn't, it's not mmap'able (ENODEV is documented to be "The underlying file system of the specified file does not support memory mapping"), which is about as close as you can get to this case. Linus
drivers/uio/uio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index 67beb8444930..f7beb6eb40c7 100644 --- a/drivers/uio/uio.c +++ b/drivers/uio/uio.c @@ -653,6 +653,8 @@ static int uio_mmap_physical(struct vm_area_struct *vma) return -EINVAL; mem = idev->info->mem + mi; + if (mem->addr & ~PAGE_MASK) + return -ENODEV; if (vma->vm_end - vma->vm_start > mem->size) return -EINVAL;