Chris Wilson wrote: > On Thu, Jun 19, 2014 at 03:57:46PM +0300, Kirill A. Shutemov wrote: > > One possible option is to create a variant of remap_pfn_range() which will > > return how many PTEs it was able to setup, before hitting the !pte_none(). > > Caller will decide what to do with partially filled range. > > Looked at just returning the address remap_pfn_range() got up to, which is > easy enough, but I think given that remap_pfn_range() will clean up > correctly after a failed remap, any EBUSY from partway through would be > a pathological driver error. I would prefer keep remap_pfn_range() interface intact with BUG_ON() on unexpected !pte_none() and introduce new function with more flexible behaviour (sharing underlying infrastructure). This way we can avoid changing every remap_pfn_range() caller. -- Kirill A. Shutemov _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
