[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgbxavbe82MTKYn8_qasqw-9kC346Azo0bGy062w0bWGg@mail.gmail.com>
Date: Sun, 5 Apr 2020 12:35:53 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bernd Edlinger <bernd.edlinger@...mail.de>
Cc: Waiman Long <longman@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Gladkov <gladkov.alexey@...il.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Sat, Apr 4, 2020 at 11:34 PM Bernd Edlinger
<bernd.edlinger@...mail.de> wrote:
>
> What really makes it impossible to write a multi-threaded strace program,
> is that *only* the tread that made PTRACE_ATTACH can do all the other
> PTRACE-APIs, but for a multi-treaded strace, any thread should be able
> to call PTRACE-APIs as long as we are in the same process.
I agree that the ptrace model is broken, and no, you can't do a
threaded ptrace the way things are now.
Some of that is really fundamental to how we do things (ie the ptracer
is the parent), and our data structures really make that be
per-thread.
I'm not sure how easy it would be to fix. Some of it is probably
really painful. For example, right now we know we can't race between
different pthread operations, because only the thread that did
PTRACE_ATTACH is allowed to do most of them.
So it could be very painful indeed to try to fix it so that you can do
threaded tracing. It woudl probably be a good thing to have, but it
might not be worth the pain.
Some daring person could try...
Linus
Powered by blists - more mailing lists