Messages in this thread |  | | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 | From | Bernd Edlinger <> | Date | Fri, 3 Apr 2020 01:22:45 +0200 |
| |
On 4/2/20 11:46 PM, Linus Torvalds wrote: > On Thu, Apr 2, 2020 at 2:00 PM Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: >> >> There are two more patches, which might be of interest for you, just to >> make the picture complete. >> It is not clear if we go that way, or if Eric has a yet better idea. >> >> [PATCH v7 15/16] exec: Fix dead-lock in de_thread with ptrace_attach >> https://www.spinics.net/lists/kernel/msg3459067.html > > There is no way I would ever take that patch. > > The amount of confusion in that patch is not acceptable. Randomly > unlocking the new lock? > > That code makes everything worse, it's completely incomprehensible, > the locking rules make no sense ahwt-so-ever. >
Linus,
let me explain what the locking here does.
It is a kind of soft mutex, which is normally strong, so taken from 1 .. 4. and nothing changes from how it was before.
But it can also be weak.
So if we detect that another thread is being ptraced, we drop the lock, and keep the boolean set to true, which makes the ptrace_attach acquire the lock, and the boolean is true, that make the ptrace_attach return -EAGAIN. release the lock immediatly, the deadlock is broken, the thread can handle the deadly signal from de_thread, de_thread continues. And just at the end of the execve, when the boolean has to be set to false again, we have to lock the mutex, set the boolean to false, and unlock the mutex. It is very important for the correctness that the boolean is only changed when the mutex is held.
Once again, please give Eric the time to catch up with his sleep, that can be more serious as you would think to have too less sleep. Then I am looking forward to see his idea, usually that may be something worth do consider. But we have all the time we want for that.
Thanks Bernd.
> I'm seriously starting to feel like I should not have pulled this > code, because the future looks _worse_ than what we used to have. > > No. No no no. Eric, this is not an acceptable direction. > > Linus >
|  |