On Wed, Nov 27, 2013 at 10:07:01AM -0800, Linus Torvalds wrote: > 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. I thought we had to return EINVAL if addr isn't aligned on a page boundry, so while ENODEV would be "nice", some posix-standard-person would probably not like this... Anyway, I like your patch, funny that we never checked this before. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html