Messages in this thread | | | From | (Ramakrishna K) | Subject | Re: Process VM Addr to Kernel VM Addr at Interrupt Time. | Date | Thu, 29 Apr 1999 10:10:26 +0530 (IST) |
| |
> > > Can you explain why the original proposal would not work if he: > > > > mlock() on application buffer > > mapped the memory into kernel space > > > > >From mlock() man page this seems like it would be safe... > > Suppose the page is shared by another process. You need to do page faulting > and copy on write even if you use mlock and make sure all the pages are > present.
Alan, Correct me whereever i am offtrack.
mlock() doesn't fault the pages by itself. The user needs to do a read/write to fault the pages in order to have the mlock take effect. Once this happens, it should work.
Now coming to the following cases :
1. SHARING of pages between different processes :
In case the pages are shared using shared memory or mmap ( MAP_SHARED), again the same logic applies. Call mlock() but make sure the page is faulted in by read or write. The faulting in can be done by one of the processes, which keeps the page in memory for all others too.
This works well for accessing info about devices. This can be implementated as you said using allocation of kernel buffer mmap'g to the user space. This is MAP_SHARED always for devices for device specific information etc.
2. sharing as COW ( using mmap ( MAP_PRIVATE ) ).
In this case i can think of only the user locking and exporting the user to kernel option to get data to be read from the kernel.
The other option of allocation of kernel buffer and exporting the data to the user using mmap using MAP_PRIVATE will never work.
This is for the following reason :
Assume there are process # A and process # B.
Allocate kernel buffer. This area is then exported to the user using say mmap ( MAP_PRIVATE ) option for both process # A and process # B.
Now if the process #B, does some processing, ( which can involve changes to the data ), and then making this visible to the kernel for further processing. ( Say DMA'ing purposes ). Then because of a possible COW fault in the user space the kernel data and the user data in the process # B space are different.
I agree though that this kind of usage/requirement will be very less.
thanks, Rama.
- 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/
| |