On Fri, 29 Nov 2019 21:07:33 +0100 Daniel Vetter daniel@ffwll.ch wrote:
On Fri, Nov 29, 2019 at 02:40:34PM +0000, Steven Price wrote:
On 29/11/2019 14:33, Boris Brezillon wrote:
On Fri, 29 Nov 2019 14:24:48 +0000 Steven Price steven.price@arm.com wrote:
On 29/11/2019 13:59, Boris Brezillon wrote:
If 2 threads change the MADVISE property of the same BO in parallel we might end up with an shmem->madv value that's inconsistent with the presence of the BO in the shrinker list.
I'm a bit worried from the point of view of user space sanity that you observed this - but clearly the kernel should be robust!
It's not something I observed, just found the race by inspecting the code, and I thought it was worth fixing it.
Good! ;) Your cover letter referring to a "debug session" made me think you'd actually hit all these.
Time for some igt to make sure this is actually correct?
That's not something I can easily trigger without instrumenting the code: I need 2 threads doing MADVISE with 2 different values, and there has to be a context switch between the drm_gem_shmem_madvise() call and the mutex_lock(shrinker_lock) one. And last but not least, I'll need a way to report such inconsistencies to userspace (trace?).