Re: Device driver memory 'mmap()' function helper cleanup

[Linus Torvalds]

On Wed, Apr 17, 2013 at 2:15 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> I took a look at the hpet_mmap function, which still contains this check:
>
>         if (((vma->vm_end - vma->vm_start) != PAGE_SIZE) || vma->vm_pgoff)
>                 return -EINVAL;
>
> As far as I can tell, this check is implied by the new code in
> vm_iomap_memory as the len argument passed here is PAGE_SIZE, so you
> can remove another three lines in hpet_mmap.

Not the way things are now.

vm_iomap_memory() actually allows non-page-aligned things to be
mapped, with the assumption that the user will then know about the
internal offsets.

The *reason* for that is questionable, but that's how pretty much
every single user I've seen has worked, throwing the low bits of the
physical away (after adding them to the length of the area).

Now, I sincerely *hope* that there are no users of "let's mmap this
non-page-aligned thing and let people access the data around it", but
I didn't want to break things that I didn't know about, and that I
couldn't test.

The HPET case was the only one (admittedly of the very limited cases I
looked at and converted) that actually checked alignment, so I left
that part in.

It may be that I should have done things differently: make the normal
helper function verify page alignment, and warn if it's missing. Then,
we could have a "vm_unaligned_iomap_memory()" that would just do the
"extend to aligned pages" that people could convert any odd users for.
That would probably be a good thing to do, but it would be separate
"phase two" from the "let's start using the sane helper".

               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/