lkml.org 
[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mapping user space buffer to kernel address space
On Mon, Oct 16, 2000 at 08:11:55PM -0700, Linus Torvalds wrote:
> Oh. So to fix a bug, you say "either delete the code, or do something else
> that is completely idiotic instead"?

I'm not saying this because the "something else" doesn't look completly idiotic
to me.

> Andrea, explain to me how pinning _could_ work? Explain to me how you'd
> lock down pages in virtual address space with multiple threads, and how
> you'd handle the cases of:
>
> - two threads doing direct IO from different parts of the same page
> - one thread starting IO from a page, another thread unmapping the range

I don't see the problem with those two cases.

In the first case the first task will sleep in wait_on_page until the
second task will unmap the kiobuf.

The second case the I/O will run even while the page is not visible
to userspace anymore. Then when unmap_kiobuf will run after the I/O
completed the page will be put back in the freelist.

The only "problematic" case that I can see is the one mentioned by SCT that is
the same physical page present in two entries of the maplist in the kiobuf (in
my patch the user_map_kiobuf will return -EINVAL gracefully in that case and
that behaviour doesn't look horribly wrong to me). And that case can be
trivially handled by checking the list backwards in the trylock slowpath as I
just said.

> The second case would require that unmap() synchronize completely with the
> IO. [..]

unmap doesn't need to synchronize at all. If it works without the locked
bit, it will work with the locked bit too.

NOTE: in the patch I'm definitely also increasing the page count (that is
certainly necessary). I never suggested to replace get_page with
the TryLock. I'm suggesting to _add_ the TryLock to avoid having to deal
with the VM for something that is just under I/O and unfreeable anyways.
Maybe you understood I was suggesting to remove the get_page? In that case I
explained wrong but you can check the patch to see I never removed the get_page
as confirm of my current words.

> [..] Which is wasteful, and doesn't make any sense: what's the point, when
> you can avoid it by just not pinning?

The point is to avoid making the driver to deal with the VM and the VM to know
about new special cases invoked by the driver. Exactly as a driver that uses
remap_page_range never known about the VM because it always kept the pages
pinned in the pte via the reserved bit just for that purpose.

If you want to put VM knowledge inside device drivers and also put new
conditions in the VM in order to avoid pinning the pages mapped via
map_user_kiobuf in the pte (so with no gain), then you have my disagreement
about the design.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.454 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site