Andrea Arcangeli writes:
> Returning to the raw-io issue (not strictly about the not alien-arch-clean
> implementation), could it be ok? I reimplemented it in the safe way:
>
> + if (!get_page_map(page, &map))
> + {
> + dprintk(KERN_WARNING
> + "Forbidden page_map in map_user_kiobuf\n");
> + goto out_unlock_page_table;
> + }
No, this still misses the point. As long as you use __va and __pa to
manipulate the kernel virtual addresses which are returned by
get_map_page(), you should be able to populate a kiobuf with pages
from a network card's packet buffer or a video frame buffer quite
happily. Things don't begin to go wrong until you try to do block
device IO on these pages, because block device IO doesn't use __va and
__pa, but rather use __io_virt/__io_phys.
In other words, the error is to pass such a kiobuf page to brw_kiovec.
Just doing a map_user_kiobuf() is fine by itself. As long as all you
are doing is reading, writing or mmap()ing the kiobuf, there simply
isn't a problem. In the long term, brw_kiovec() is only one of the
things we might want to do with such kiobufs.
If kiobufs are to be generic objects, then the time at which we need
to check for a null page_map for the page is during brw_kiovec(), not
map_user_kiobuf(). And yes, I should add this (I'll do it once I'm
back in .uk, along with a couple of other tidy-ups), but I don't want
to restrict map_user_kiobuf() unnecessarily.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/