Re: add remap_pfn_range_notrack instead of reinventing it in i915

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

 



On Mon, Mar 01, 2021 at 09:45:59AM +0100, Christoph Hellwig wrote:
> On Mon, Mar 01, 2021 at 09:44:13AM +0100, Daniel Vetter wrote:
> > On Mon, Mar 01, 2021 at 09:33:18AM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > > 
> > > i915 has some reason to want to avoid the track_pfn_remap overhead in
> > > remap_pfn_range.  Add a function to the core VM to do just that rather
> > > than reinventing the functionality poorly in the driver.
> > 
> > It's not _notrack it's "rely on the tracking established by the struct
> > io_mapping". Exporting a _notrack version to drivers sounds like not
> > something we want to ever do. So I think you want a helper which takes the
> > io_mapping, and not something that encourages drivers to go full stupid.
> 
> As far as I can tell there is no struct io_mapping anywhere near
> remap_io_sg.

Yeah that looks like real bad taste, but it is how this stuff is (or at
least was, been years I've followed this closely) meant to work. Comment
in the code still claims it's the way:

	/* We rely on prevalidation of the io-mapping to skip track_pfn(). */

If that's a lie and there's no iomapping for that range, then ugh.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux