Hi Doyu-san, > > 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. Please share your thoughts. Thank you, Best regards, Hari -- 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
