Hi Hari, From: "ext Kanigeri, Hari" <h-kanigeri2@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
