Re: Patch "Fix a few incorrectly checked [io_]remap_pfn_range() calls" has been added to the 3.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 27, 2013 at 10:42 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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...

No, we return EINVAL if the *virtual* address isn't aligned on a page
boundary, but the internal hardware address of the device is not a
visible API, and ENODEV is actually the better error number even for
POSIX exactly because that means "this device is not mmap'able" as
opposed to "you gave an invalid virtual address range to mmap". From
the open group documentation:

  [ENODEV]
    The fildes argument refers to a file whose type is not supported by mmap().

and if the underlying physical hardware address isn't page-aligned,
then that would match that description quite well, I'd say. The
hardware isn't sanely mmap'able.

> Anyway, I like your patch, funny that we never checked this before.

Well, I guess we expected the device drivers to just not have
unaligned memory areas. The patch that started this thread was about
checking the parameters the user passed in (and hey, even there to
some degree we've traditionally expected the *user* to be somewhat
trusted - you'd certainly hope that the device node for some hardware
interface isn't just randomly available to all users), but that's
still different from "we expect the kernel itself to have drivers that
don't try to expose mmap on random unaligned things".

Of course, the alternative is to say: "the user knows what he is
doing, and knows that the hardware is unaligned, and can do the proper
offsets within pages, and we'd rather allow mmap and expose the memory
*around* the device too than disallow it". That's what we've
historically done with /dev/mem - but if you can open /dev/mem you can
touch any memory anyway, so that's a somewhat different situation.

              Linus
--
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




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]