[PATCH 01/19] drm/amdkfd: Fix double Mutex lock order

[Kuehling, Felix]

I guess in the current upstream code this patch doesn't make sense, because there is only one function that takes both locks. I included it in this patch series just because I stumbled over it while reducing cosmetic differences between amd-kfd-staging and upstream.

In our latest code we have other places that take both locks, so they have to all  take them in the same order. I think we can reverse the order and take the dbgmgr_mutex first where it's needed. I'll drop this patch for now and include it later in a context where it makes more sense.

Regards,
  Felix
________________________________________
From: Oded Gabbay <oded.gabbay at gmail.com>
Sent: Saturday, August 12, 2017 8:23 AM
To: Kuehling, Felix
Cc: amd-gfx list
Subject: Re: [PATCH 01/19] drm/amdkfd: Fix double Mutex lock order
[snip]

Hi Felix,
Could you please explain why this change is necessary ?

It seems to me this actually makes things a bit worse in a
multi-process environment, because the p->mutex is per process but the
dbgmgr mutex is global. Therefore, if process A first takes the
process mutex, and process B takes the dbgmgr mutex (in this function
or some other function, such as kfd_ioctl_dbg_address_watch) *before*
process A managed to take dbgmgr mutex, then process A will be locked
from doing other, totally unrelated functions, such as
kfd_ioctl_create_queue.

While, if we keep things as they are now, process A will first take
the dbgmgr mutex, making process B stuck on it, but allowing it to do
other unrelated ioctls because he hadn't taken the process mutex.

Thanks,
Oded