kernel newbie questions re: kiobuf

From: Jim Schutt (
Date: Wed Apr 26 2000 - 17:14:08 EST


I've been studying the code for kiobufs to make sure I understand
how to use them. I could use some help understanding the following:

- The comment above map_user_kiobuf(), as well as its usage in rw_raw_dev(),
  implies that it is responsible for pinning down the user pages in
  physical memory. It seems to me that the call to handle_mm_fault() is
  responsible for ensuring each page is in physical memory, but what
  is responsible for pinning them there?

- lock_kiovec() tries to set the PG_locked bit for each page it holds
  using TryLockPage() . What does this bit do if setting it
  doesn't pin the page in physical memory? Why doesn't map_user_kiobuf()
  need to set it for each page it faults in?

- map_user_kiobuf() increments the count for each page, but unmap_kiobuf()
  doesn't decrement it. I had the impression that the page count keeps
  track of the number of references to that page; if this isn't true,
  what does the page count keep track of? If so, why doesn't
  unmap_kiobuf() need to decrement it, as the kiobuf isn't referencing
  those pages anymore? (But, presumably the user app that supplied the
  buffer still is?)

- lock_kiovec() sets the kiobuf.locked flag for each kiobuf in the
  kiovec, and both unlock_kiovec() and unmap_kiobuf() clear it. Why
  doesn't map_user_kiobuf() set it?

- Under what circumstances am I likely to need lock_kiovec() and
  unlock_kiovec(), in addtion to map_user_kiobuf() and unmap_kiobuf()?
  I.e., what extra functionality do they give me, other than looping
  over multiple kiobufs?

The above questions are based on 2.3.99-pre3.

TIA for any time spent trying to enlighten me.

-- Jim

PS - Please cc: me on responses, as I follow the list through an archive.

  James A. Schutt Sandia National Laboratories 505 844-8882 Albuquerque, New Mexico USA

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:11 EST