[Nouveau] [PATCH] instmem/gk20a: fix race conditions
Alexandre Courbot
gnurou at gmail.com
Tue Nov 10 21:08:13 PST 2015
On Wed, Nov 11, 2015 at 9:19 AM, Ben Skeggs <skeggsb at gmail.com> wrote:
> On 11/09/2015 05:37 PM, Alexandre Courbot wrote:
>> The LRU list used for recycling CPU mappings was handling concurrency
>> very poorly. For instance, if an instobj was acquired twice before being
>> released once, it would end up into the LRU list even though there is
>> still a client accessing it.
>>
>> This patch fixes this by properly counting how many clients are
>> currently using a given instobj.
> Out of curiosity, which instobjs are being accessed concurrently?
PGTs it seems - at least this is what dumping a stack when detecting a
concurrent usage on an instobj indicates:
[ 270.547052] [<bf0618dc>] (gk20a_instobj_acquire [nouveau]) from
[<bf066358>] (gf100_vm_map_sg+0x58/0x124 [nouveau])
[ 270.557568] [<bf066358>] (gf100_vm_map_sg [nouveau]) from
[<bf0641b0>] (nvkm_vm_map+0x300/0x3bc [nouveau])
[ 270.567333] [<bf0641b0>] (nvkm_vm_map [nouveau]) from [<bf0bcbd4>]
(nouveau_bo_vma_add+0x74/0xa0 [nouveau])
[ 270.577189] [<bf0bcbd4>] (nouveau_bo_vma_add [nouveau]) from
[<bf0bdbd0>] (nouveau_gem_object_open+0x124/0x158 [nouveau])
[ 270.588196] [<bf0bdbd0>] (nouveau_gem_object_open [nouveau]) from
[<c02da62c>] (drm_gem_handle_create_tail+0x104/0x19c)
[ 270.599025] [<c02da62c>] (drm_gem_handle_create_tail) from
[<bf0be138>] (nouveau_gem_ioctl_new+0x90/0x18c [nouveau])
[ 270.609594] [<bf0be138>] (nouveau_gem_ioctl_new [nouveau]) from
[<c02db3b8>] (drm_ioctl+0x284/0x440)
[ 270.618777] [<c02db3b8>] (drm_ioctl) from [<bf0b6bfc>]
(nouveau_drm_ioctl+0x54/0x98 [nouveau])
[ 270.627441] [<bf0b6bfc>] (nouveau_drm_ioctl [nouveau]) from
[<c0103860>] (do_vfs_ioctl+0x458/0x6dc)
[ 270.636471] [<c0103860>] (do_vfs_ioctl) from [<c0103b18>]
(SyS_ioctl+0x34/0x5c)
[ 270.643767] [<c0103b18>] (SyS_ioctl) from [<c000f5c0>]
(ret_fast_syscall+0x0/0x3c)
More information about the Nouveau
mailing list