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