Hi Hari,
From: "ext Kanigeri, Hari" <[email protected]>
Subject: RE: [PATCH 1/4] [OMAPZOOM] DSPBRIDGE: Memory lock for DMM.
Date: Wed, 1 Apr 2009 15:01:29 +0200
[...]
> > Hm....for this page swapping case, I think that handling this issue in
> > kernel may cause more complexity and this can be avoided by "mlock()"
> > for that buffer in userland? This looks more sipmpler?
> >
> > >
>
> -- I see your point of handling the locking from user-space
> itself. This can be done in normal Page swapping scenarios, but in
> the case of abnormal termination of the user-space Process that
> mapped the buffers we still have an issue.
>
> This is what I think the problem might be if we move the locking to user-land.
> - User process mapped and locked the buffer using mlock.
> - The Physical address mapped to DSP VA by DSPBridge.
> - The User process got terminated abnormally. I think this
> will cause the Kernel to reclaim the User buffers that were
> mapped.
> - Now the DSP is not aware of this cleanup and it might be
> still trying to access the Mapped address, but since the Pages
> are removed we will end up with MMU fault or DSP corrupting
> the memory of other Processes as the reclaimed Pages might be
> allocated to other Processes.
>
> By moving the locking to Kernel space, we are guaranteed that these
> Pages are locked even when an application that mapped the buffers is
> terminated. These Pages will be unlocked only during Bridge's
> resource cleanup of this Process after Bridge informing the DSP s/w
> not to access this buffer.
>
> I think if the resource cleanup is moved to bridge_release instead
> of bridge_open, then it might be possible to move the locking
> mechanism to User land. Here I am assuming that on abnormal
> termination of a Process, the Kernel first calls the bridge_release
> on behalf of the Process before reclaiming the buffers that were
> allocated by this Process otherwise there is a narrow Window when
> DSP might try to access the memory that is no longer valid.
There can be multiple user applications which can do (v)-(p)-(d)
mapping and these processes can be killed unexpectedly. Even in such a
case, it would be nice if (p)-(d) mapping could be released without
restarting a whole iommu.
(v): mpu virtual address
(p): physicall address
(d): device virtual address
So I am considering if "vma->vm_ops->close(vma)" can afford the above
mechanism.
Hiroshi DOYU
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
