Re: locking user memory and kiobuf

Ingo Molnar (mingo@chiara.csoma.elte.hu)
Sat, 6 Nov 1999 11:39:15 +0100 (CET)


On Sat, 6 Nov 1999, Juan Gonzalez wrote:

> Three questions:
>
> 1. From what I've read in the archives, it seems that locking user
> memory from a driver isn't supported in current releases of the Linux
> kernel (2.2.xx). Is that correct?

it can be done, but is rather quirky. You can however rely on
map_user_kiobuf() if Stephen Tweedie's 'raw IO patch' is applied - this is
usually the case for the latest kernel packages of various Linux
distributions.

> 2. As I understand, there's a new "kiobuf mechanism" being added in
> 2.3.xx .
> Does that provide a solution to this particular issue?

yes, kiobufs are definitely the way to go. It handles all the security
issues, and provides the driver with an array of pages that can be used to
do DMA.

> 3. Alternatively, can I directly manipulate the PG_locked flag for the
> pages in question?

this is strongly discouraged. map_user_kiobuf() locks/makes present the
pages for you in a guaranteed way. (The driver still has to make sure that
the user doesnt lock too many pages.)

> For example, I could ensure the page(s) are in physical memory by
> accessing a word in that page (copy_to_user), and then set the PG_locked
> bit for the page to prevent swapping. Wouldn't this effectively "lock"
> the page for safe DMA transfers? After the transfer, I could clear the
> PG_locked bit and return to the user.
> Or would this be considered dangerous practice? Do I also need
> PG_reserved?

yes, this is dangerous and unsafe, map_user_kiobuf()/unmap_kiobuf() is
the right mechanizm - see drivers/char/raw.c how it's used.

-- mingo

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