Re: [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

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

 




On 5/17/21 11:46 PM, Thomas Hellström wrote:

On 5/17/21 3:11 PM, Christoph Hellwig wrote:
On Mon, May 17, 2021 at 04:09:42PM +0300, Serge Belyshev wrote:
Christoph Hellwig <hch@xxxxxx> writes:

As an ad-hoc experiment:  can you replace the call to remap_pfn_range
with remap_pfn_range_notrack (and export it if you build i915 modular)
in remap_io_sg and see if that makes any difference?
That worked, thanks -- no artifacts seen.
Looks like it is caused by the validation failure then.  Which means the
existing code is doing something wrong in its choice of the page
protection bit.  I really need help from the i915 maintainers here..

Hmm,

Apart from the caching aliasing Mattew brought up, doesn't the remap_pfn_range_xxx() family require the mmap_sem held in write mode since it modifies the vma structure? remap_io_sg() is called from the fault handler with the mmap_sem held in read mode only.

/Thomas

And worse, if we prefault a user-space buffer object map using remap_io_sg() and then zap some ptes using madvise(), the next time those ptes are accessed, we'd trigger a new call to remap_io_sg() which would now find already populated ptes. While the old code looks to just silently overwrite those, it looks like the new code would BUG in remap_pte_range()?

/Thomas





_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
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