Messages in this thread | | | From | (Alan Cox) | Subject | Re: Address spaces on a i386 - Getting Confused | Date | Tue, 30 Mar 1999 15:19:59 +0100 (BST) |
| |
> OK, so user process address space lies below 0xC0000000 and there is a > different mapping per process. Kernel mappings are above 0xC0000000 and are > constant. So when a syscall is run, we're still in the user process context,
Are constant for the moment.
> therefore the userspace mappings still exist for that process. (How am I > doing?) This means that the copy-from-user() and copy-to-user() can just be > simple copies.
No they have to consider the processor type, check the source/dest and allow for the possibility of faults.
Roughly speaking it looks like this (although some of this vanishes for non 386 builds)
check user address and user address+size are in user space, and that they don't wrap
if the cpu doesnt has working write protect ensure the faults will be caught/cleaned up [compile time] copy the data else walk the VMA tree to ascertain the addresses are all mapped copy on write any pages needed copy the data fi
Except when you feed it junk, it becomes a straight copy on any decent CPU.
> But I'm still confused by the virt-to-phys macro. I would have thought if I > want to find the physical address of a user space buffer I would have to go > through the page table to fins out where is physical page is, not just mask > off some bits.
You don't want to find the physical address of a user space buffer. For one thing the answer you get back may cease to apply at an arbitary point in the future. Secondly you must deal with copy-on-write. The list of problems continues from there onwards.
Stephen Tweedie is doing code to do this cleanly which will probably by for the 2.3.x kernel tree. Until then either map kernel space into the user process as your DMA buffers (see the bttv mmap() operation or the sound drivers), or don't play with fire
- 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/
| |