Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Wed, 25 Aug 1999 15:48:51 -0700 (PDT) | Subject | Re: [PATCH] 2.3.14: bug-fix for raw IO error recovery |
| |
Hi,
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/
| |