[Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

Matthew Auld matthew.william.auld at gmail.com
Tue May 18 15:00:36 UTC 2021


On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch at lst.de> wrote:
>
> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > > 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..
> >
> > AFAIK there are two users of remap_io_sg, the first is our shmem
> > objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> > mmap modes for userspace. The other user is device local-memory
> > objects(VRAM), and for this one we have an actual io_mapping which is
> > allocated as WC, and IIRC this should only be mapped as WC for the
> > mmap mode, but normal userspace can't hit this path yet.
>
> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
> Is that device local?

The vm_fault_cpu covers both device local and shmem objects.

>
> > What do we need to do here? It sounds like shmem backed objects are
> > allocated as WB for the pages underneath, but i915 allows mapping them
> > as UC/WC which trips up this track_pfn thing?
>
> To me the warnings looks like system memory is mapped with the wrong
> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
> needs to be used on the kernel mapping as well to ensure that the
> attributes don't conflict.

AFAIK mmap_offset also supports multiple active mmap modes for a given
object, so set_memory_* should still work here?


More information about the dri-devel mailing list