lkml.org 
[lkml]   [1999]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: locking user memory and kiobuf
hi,

On Sat, 06 Nov 1999 20:19:16 -0500, Douglas Gilbert
<dgilbert@interlog.com> said:

> The kiobuf mechanism may be the way to go but it (or associated
> bits of the kernel) has some rough edges. Stephen Tweedie seems
> to be very busy so perhaps someone else could look at some of
> these points:

just finishing off a new ext3 release, then I'll get back to some kiobuf
work for 2.3. In particular:

> 1) If a driver has 2 or more pointers to the user space (e.g.
> iovec scatter gather mechanism) then the second call to
> map_user_kiobuf runs the risk of hanging forever if it
> presents a range containing a page that the first call
> to map_user_kiobuf has already locked.

I'll be doing a separate call to lock and unlock kiovecs independently
of the mapping of the user pages.

> [I think map_user_kiobuf should have a variant to return EBUSY
> rather than always wait for the page in question to free up. Could
> it determine that the current kernel thread is holding that page
> and so _not_ wait on it?]

The idea is that you call lock_kiovec() on the entire range of pages to
be locked. If there are any double pages, the second lock will fail and
you'll get EINVAL on the whole call. Kiovec operations are not supposed
to include a page more than once (the zero page is exempt from this).

> 2) If a character driver plans to call unmap_kiobuf in its
> release() call then it may never get a chance. Linux
> seems to freeze the process due to locked pages _before_
> it closes down file descriptors.

Again, that is addressed by the separating out of the lock operations.
Lock/unlock is supposed to surround one IO, not a process's mapping. An
IO is _always_ expected to complete, regardless of what is happening to
maps of the pages concerned.

> So the kiobuf mechanism may be sufficient for the "raw"
> character device but it needs more work (and documentation)
> before other driver writers are encouraged to use it.

Yep, but it should be getting closer.

--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/

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