Messages in this thread | | | Date | Thu, 11 Nov 1999 08:55:54 -0800 (PST) | From | Matt Robinson <> | Subject | Re: kiobuf using kernel pages |
| |
On Fri, 12 Nov 1999, Keith Owens wrote: |>On Thu, 11 Nov 1999 11:31:35 +0000 (GMT), |>"Stephen C. Tweedie" <sct@redhat.com> wrote: |>>On Thu, 11 Nov 1999 22:05:31 +1100, Keith Owens <kaos@ocs.com.au> said: |>>> The problem is that sd_raw_{read,write} can be called from kernel or |>>> user space and those routines need some simple way of telling what |>>> buffers their caller is using. |>> |>>No, that's the wrong way to think about it. |>> |>>The _whole_ point about kiobufs is that they contain pages of |>>kernel-addressable memory, without _any_ information about where those |>>pages came from. |>> |>>A raw read/write function which uses kiobufs should never even think |>>about virtual memory. It should use the kernel addresses in the kiobuf |>>for the IO and then return. If the IO is coming from user space, then |>>the syscall interface that the user IO is using can do a |>>map_user_kiobuf() to map a user virtual address range into a kiobuf for |>>the duration of the IO. |> |>OK, I see the problem. SGI's code has sd_raw_{read,write} allocate the |>kiobuf then call sd_raw_rw() which issues map_user_kiobuf(). Their |>patch also passes an astype variable into sd_raw_rw() which copies the |>astype into the kiobuf and right at the bottom layer, map_user_kiobuf() |>does different mappings depending on the value of astype. Just a few |>layer violations in there.
We agree it's a violation in the worst sense. :) The problem is there was no good way to set AS_KERNEL without calling map_user_kiobuf() on your own. Until such a scheme is put in place (which we believe will be at some point soon), we put something in to make it work for us. It's certainly better than a conditional check in map_user_kiobuf(). :)
|>What I need is to move map_user_kiobuf() up to sd_raw_{read,write} and |>make the map call conditional on some external data (filp flag?). Use |>map_user_kiobuf() by default or use map_kernel_kiobuf() if the filp is |>marked "use kernel pages". That way the syscall code makes the |>decision about whether to use kernel or user mappings and passes the |>resulting mapped kiobuf to the low level raw I/O code. No decisions in |>the low level code about what mappings to use. |> |>So all we need is a map_kernel_kiobuf() routine and a wrapper |>map_kiobuf() which takes a flag and calls the relevant map_xxx_kiobuf() |>routine. That has a restriction that all the pages in a single kiobuf |>are mapped the same way but that is probably acceptable, the kiovec |>lets you plug kiobufs together. |> |>Does this sound sensible?
That'd be fine, or as you stated in a previous response, a way to set a struct file flag to indicate kernel pages that would be universal.
--Matt
- 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/
| |