Re: kiobuf using kernel pages

Matt Robinson (yakker@cthulhu.engr.sgi.com)
Thu, 11 Nov 1999 08:55:54 -0800 (PST)

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/