User ptr horror show

[David Herrmann]

Hi

On Mon, Jun 30, 2014 at 8:21 PM, Jerome Glisse <j.glisse at 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