Quoting Chris Wilson (2019-03-18 12:10:12) > Quoting Chris Wilson (2019-03-14 11:44:37) > > Quoting Tvrtko Ursulin (2019-03-14 11:33:43) > > > I am only wondering what happens to reads/write to the trailing area? > > > Does shmemfs expands the backing store for this mmap and we just end up > > > with otherwise unused chunk at the end? > > > > My expectation would be that they generate a SIGBUS since the filp > > should not be extended to cover the absent pages. So it would be the > > equivalent of mmaping a file then calling ftruncate(0). > > Ok, having just checked, what actually happens is that shmemfs quite > happily allocates the extra page beyond the end of the object and > userspace can freely read/write into that address space with only the > mere consequence that those pages are not mapped to the GPU. Or egg-on-face moment, wrong kernel (already had the safety check!) ickle@kabylake:~/intel-gpu-tools$ sudo ./build/tests/gem_mmap --run bad-size IGT-Version: 1.23-g3fc026d3e (x86_64) (Linux: 5.0.0+ x86_64) Starting subtest: bad-size Received signal SIGBUS. Stack trace: #0 [fatal_sig_handler+0xd5] #1 [killpg+0x40] #2 [__real_main119+0x1b6] #3 [main+0x44] #4 [__libc_start_main+0xeb] #5 [_start+0x2a] Subtest bad-size: CRASH (0.001s) SIGBUS! -Chris
