On Tue, Aug 16, 2005 at 19:04:10 +0200, Arjan van de Ven wrote:
> On Tue, 2005-08-16 at 19:14 +0300, Stavros Passas wrote:
> > Hi All,
> >
> > I working on a kernel module and I have been a little bit comfused with
> > Linux memory manager.
> >
> > When a user opens the device,the module stores somewhere user's
> > active_mm pointer.We can assume that only one user can open the device
> > at the same time. When a interrupt comes to my handler, I want to write
> > some data to a page of the user. The interrupt handler has the
> > destination address,and the length of the data that must be copied and
> > of course the data. The problem is that the destination address is from
> > address space of the user. At first,through user's active_mm, I find if
> > the user have access to the memory region that device must write. AFAIK
> > I cannot use copy_to_user function, or something like this, because
> > these functions can used only from the user proccess.
> >
> > So the question is how to "convert" the destination memory address to
> > interrupt handler address space, so the handler can write the data to
> > the correct place.
> >
>
> an interrupt handler has no address space.
> Also.. what if the memory in userspace is actually swapped out?
>
> you just can't do this in linux; you need to do this from user context;
> and wake that user context up from the irq.
Saying "process context" would be a bit clearer here, as it really runs in
kernel, either inside a syscall or in a kernel thread.
Actually there are two ways to read a device file and these determine the
solution:
1) The device is read via read syscall.
In this case, the irq must place the data in a buffer in kernel memory
and, if registered, wake up the process if waiting in poll or in read.
When the process is awoken it will issue/continue a read, which will do
the actual copy_to_user from it's file_operations->read.
2) The device is read via mmap.
In this case, the irq places the data in a buffer in kernel memory
exactly as before. It also should wake up the process if it is waiting
(it probably should have some means of waiting for the data).
Now there is _no_ copy_to_user, since the buffer is visible in the
process. The mmap method you would implement here would attach the buffer
where the data is placed into address space of the calling process.
In neither case you should save process' active_mm anywhere. Manipulating
process' memory should only ever happen in that process context, or, as in
the later case, in a shared buffer set up with mmap.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
