Re: User ptr horror show

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux