On 11/12/26 23:08, David Hildenbrand (Arm) wrote: > While working on vm_ops->access related fixes in core code for FOLL_ANON > and VMA access permission + size handling, I stumbled over two driver > issues. Also, I have to update one selftest that specifies PROT_WRITE > but actually wants read-access. > > Fixing it all in this series, because it's all intertwined. > > In patch #5 we break a debugging use case for older ROCm versions, where > the amdgpu driver hacked around it by exploiting broken access checks in > core-mm. > > Tested as good as I can with selftests. I cannot really test the > i915 and powerpc/spufs stuff on real hardware. > > Signed-off-by: David Hildenbrand (Arm) <[email protected]> > --- > Chris Mason (1): > mm: do not call vm_ops->access with FOLL_ANON > > David Hildenbrand (Arm) (4): > drm/i915: consider vm_pgoff in vm_access() > drm/i915/selftests: request read access for mmap access tests > powerpc/spufs: consider vm_pgoff in spufs_mem_mmap_access() > mm: check permissions and bounds for vm_ops->access > > arch/powerpc/platforms/cell/spufs/file.c | 3 ++- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 +++- > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 ++- > mm/memory.c | 28 > ++++++++++++++++++++-- > 4 files changed, 33 insertions(+), 5 deletions(-) >
We get some test failures regarding error handling: e.g., https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_178442v1/shard-glk6/igt@[email protected] It's all about error handling. Before the correct handling in patch #5, we would pass a size that exceeds the actual VMA to vm_access(), and that one would return -EIO. In the test above 8 bytes whereby the VMA only allowed for 4 more bytes. Now we properly handle that in core code and get a partial read completion on the 4 bytes. I think the test should be fixed to expect a partial read completion. We won't hack around this in core-mm. -- Cheers, David
