Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1

[Linus Torvalds]

On Thu, Apr 9, 2020 at 1:37 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> 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