On Tue, 18 May 2021 at 14:21, Christoph Hellwig <hch@xxxxxx> 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?
