Hi On Mon, Jun 30, 2014 at 8:21 PM, Jerome Glisse <j.glisse@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
