[lkml]   [1999]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Process VM Addr to Kernel VM Addr at Interrupt Time.
> > 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.

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.


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

 \ /
  Last update: 2005-03-22 13:51    [W:0.072 / U:5.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site