Messages in this thread | | | Date | Sat, 06 Nov 1999 20:19:16 -0500 | From | Douglas Gilbert <> | Subject | Re: locking user memory and kiobuf |
| |
Ingo Molnar wrote:
> [snip] > yes, this is dangerous and unsafe, map_user_kiobuf()/unmap_kiobuf() is > the right mechanizm - see drivers/char/raw.c how it's used.
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:
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 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?]
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. This situation occurs when SIGINT hits a process. A side affect of this is that the driver will not release other resources and, if it is a module, will not unload.
3) As of 2.3.21 (I'm yet to try this on 2.3.25) trying to use unmap_kiobuf() in a bh handler results in a "BUG" oops. BTW This was an attempted work-around of point 2.
4) As of 2.3.25 map_user_kiobuf() and unmap_kiobuf() are not exported symbols in kernel/ksyms.c making them difficult to access from a module.
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.
Doug Gilbert
- 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/
| |