Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 8 Nov 1999 20:08:54 +0000 (GMT) | Subject | Re: 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/
| |