Libor Michalek wrote:
The problem we were seeing is that the minor fault by the app resulted in a new physical page getting mapped for the application. The page that had the elevated refcount was still waiting for the data to be written to by the driver at the time that the app accessed the page causing the minor fault. Obviously since the app had a new mapping the data written by the driver was lost.
Thanks Libor, this is much better explanation of the problem than what I posted.
It looks like code was added to try_to_unmap_one() to address this, so hopefully it's no longer an issue...
I doubt it. I tried this with an earlier 2.6 kernel, and get_user_pages() was still not enough to really pin the memory down. Maybe it works in 2.6.12, but that doesn't help me any, because our driver needs to support all 2.4 and 2.6 kernels. Currently, mlock() alone seems to be good enough, but I'm going to add calls to get_user_pages() just to be sure.
-- Timur Tabi Staff Software Engineer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
