Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 9 Apr 2020 13:56:31 -0700 | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 |
| |
On Thu, Apr 9, 2020 at 1:37 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > Since they are all waiting for each other that loop is a deadlock.
No.
That's just a user bug. It's not a deadlock for the kernel.
The fact that you guys kept calling it a deadlock was what confused me and made me think you were talking about something much more fundamental (like the same thread trying to take the lock recursively - *THAT* is a deadlock).
There are lots of easier ways to make people wait for each other. This is a trivial one:
#include <unistd.h>
int main(void) { int fd[2]; char buffer[1];
pipe(fd); fork(); read(fd[0], buffer, sizeof(buffer)); write(fd[1], buffer, sizeof(buffer)); }
where you have two readers that both wait for each other to write.
As far as the kernel is concerned, it's not a deadlock. It's just a user space bug.
The exact same thing is true here. The user space was buggy, and set it up so that both sides of two processes were just waiting for the other side to do something that they never did.
And exactly like the reads, it's not a kernel bug.
Now, I do agree that from a QoI standpoint, it's annoying when ptrace() just stops like that, particularly when you want to use ptrace for debugging. So I'm not dismissing trying to improve on interfaces, but I think you've confused things by calling this a deadlock and thinking that it's a kernel bug.
The kernel never tries to figure out "Oh, stupid users are waiting for each other". Sure, file locking has the special circular locking detection, but that's literally a special case. The normal semantics are that you give users rope. If users make a noose of the rope and then trip on it, that's _their_ problem, not the kernels.
Linus
| |