Hi
On Mon, Jun 30, 2014 at 8:21 PM, Jerome Glisse j.glisse@gmail.com wrote:
So in light of the radeon patch to add user ptr, i took a look at intel code and it is time to put an end to this non sense. It violate so many mm assumptions that it just not a doable options.
So Intel code only register a range_start callback that means that any gup or other i915 activities that happens just after this call back returns as no idea what so ever of it might get. It might get the old pages that are about to change or the new pages.
Can you give a complete example of that race? I cannot follow.
I did have a quite thorough look on intel's userptr implementation and it does things similar to AIO, Direct-IO and other APIs that pin user-pages (they also do it for reads or writes): - Get pages via GUP - don't care whether the user unmaps, truncates, moves, kills them; they work on pages, not on VM ranges
Additionally to what AIO and Direct-IO do, intel userptr adds the range_start callback to release pinned pages whenever the pages are unmapped. However, anyone who truncates inode pages, schedules writeback, etc., has to lock the page. Thus, any following GUP-fast from userptr will fail and the slowpath will wait on mmap_sem. So I'd really prefer if you could elaborate on your race?
Thanks David