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@xxxxxxxxx> 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
