RE: locking user memory and kiobuf
Bret Indrelee (bindrelee@sbs-cp.com)
Sun, 7 Nov 1999 14:33:15 -0600
Douglas Gilbert [mailto:dgilbert@interlog.com] wrote:
> 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.
Just to add a couple of my own:
5) Since one of the expected uses of this is char DMA drivers, it would be
nice to include something that builds a scatter/gather list of PCI bus
addresses from the kiovec[] array information.
6) Documentation on this interface is non-existent.
7) If the BIGMEM stuff is going to allow data to exist in areas that PCI
can't access, we need some way of handling this. I think that this will
present a problem on some systems, but am not sure if the hardware already
has a method for handling this or not. I would suspect it would be best to
handle it in the map_user_kiobuf() routine, since that is the routine that
makes sure that everything is in physical memory.
For my own use, I would also like to get a patch put together that makes
this interface available in 2.2 kernels. That way people don't have to wait
for 2.4 before using my device.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------
-
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/