copy_from_user user space address mapping in the kernel page table.
Hi, In the copy_from_user when the user passes the virtual address is the address mapped in the kernel page tables? In the function there is a source is a user virtual address(<3GB) and the destination is the kernel virtual address(3GB - 4GB) and for the MMU to access the physical page frame when in kernel space operating in behalf of the process context there should be a mapping of the virtual address to the page frame, correct? I am assuming the implementation would be to take the virtual address and walk the page table to get to the physical page frame and map the physical page frame in the kernel page table (i.e. swapper_pgd). Is this correct? If not what would be the mechanism? Thanks, Gautam.
On Sun, 02 Nov 2014 19:57:44 +0530, mind entropy said:
In the copy_from_user when the user passes the virtual address is the address mapped in the kernel page tables?
Actually, a large part of the reason for copy_from_user()'s existence is to deal with the possibility that the page is *not* mapped at the moment because it's been swapped out (at which point we need to schedule a read operation for whatever backing store the page had (filesystem, swap, or zero-page for a never-before-referenced page), wait for it to arrive, and then nail it down so it doesn't leave out from under us before we finish the copy from the page. And of course, it's even *more* fun when the copy crosses a page boundary, and one or both of the pages isn't resident....
In the function there is a source is a user virtual address(<3GB) and the destination is the
Only for 32-bit kernels. x86_64 has a different memory layout.
On Mon, Nov 3, 2014 at 6:45 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 02 Nov 2014 19:57:44 +0530, mind entropy said:
In the copy_from_user when the user passes the virtual address is the address mapped in the kernel page tables?
Actually, a large part of the reason for copy_from_user()'s existence is to deal with the possibility that the page is *not* mapped at the moment because it's been swapped out (at which point we need to schedule a read operation for whatever backing store the page had (filesystem, swap, or zero-page for a never-before-referenced page), wait for it to arrive, and then nail it down so it doesn't leave out from under us before we finish the copy from the page.
Got this part. Now the mapping will be done in the kernel page table,correct? i.e. in the swapper_pg_dir and this would be what the MMU will use to walk, correct? In short when the memcpy is being done the page table will be the kernel pgd right?
And of course, it's even *more* fun when the copy crosses a page boundary, and one or both of the pages isn't resident....
In the function there is a source is a user virtual address(<3GB) and the destination is the
Only for 32-bit kernels. x86_64 has a different memory layout.
participants (2)
-
mind entropy -
Valdis.Kletnieks＠vt.edu