RE: Locking user space buffer in physical mem using get_user_pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Hi...
> 
> > Hi...
> >> As most of you will already know, one can use get_user_pages to get
a 
> >> struct pages list of a certain user space buffer.
> >> While doing this, get_user_pages also locks the pages into physical

> >> mem (preventing them from being swapped out to disk, or moved
within 
> >> phys mem) for usage with e.g. DMA.
> >
> > From my personal code observation, I don't see any codes that does 
> >page locking in RAM. I only saw page >faulting code, so it 
> just brought
> >page(s) to RAM, but not locking them.
> 
> In LDD3 p436 the function get_user_pages is explained and 
> there it states:
>   "Upon successful completion, the caller has a pages array 
> pointing to the user-space buffer, which is locked into memory"
> 
> That's where I got this idea.
> 
> >So, IMHO, you can call get_user_pages as many times as needed... 
> >locking
> >  is done in other function.
> 
> Regards,
> Tom
> 

Hi there,

After digging into the source of get_user_pages I found that at a
certain point, 
page_cache_get is called on every page in the buffer 
which in turn calls get_page
which will atomically increase the _count member of struct page

Could it be that because of this the memory management will make sure
that the related page(s) will be kept in phys mem (in other words, it
will prevent that they can be swapped out) ?

Thanks for your help,
Tom


DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux