[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOp6jLbpfeypOqJO2B4D0Ye6AK0Ht6uh8GFX++j_kqMLFg21fw@mail.gmail.com>
Date: Mon, 4 Sep 2017 15:19:13 +1200
From: "Robert O'Callahan" <robert@...llahan.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Aleksa Sarai <asarai@...e.com>,
Andy Lutomirski <luto@...capital.net>,
Attila Fazekas <afazekas@...hat.com>,
Jann Horn <jann@...jh.net>, Kees Cook <keescook@...omium.org>,
Michal Hocko <mhocko@...nel.org>,
Ulrich Obergfell <uobergfe@...hat.com>,
open list <linux-kernel@...r.kernel.org>,
linux-api@...r.kernel.org
Subject: Re: [RFC][PATCH] exec: Don't wait for ptraced threads to be reaped.
Sorry about replying to this old thread, but...
On Mon, Apr 3, 2017 at 9:07 AM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> I don't know who actually useses PTRACE_O_TRACEEXIT so I don't actually
> know what the implications of changing it are. Let's see...
>
> gdb - no
> upstart - no
> lldb - yes
> strace - no
For the record, rr uses PTRACE_O_TRACEEXIT.
When a thread exits we need to examine its address space to find its
robust futex list and record the changes that will be performed by the
kernel as it cleans up that list. So, any failures to deliver
PTRACE_EVENT_EXIT are potentially problematic for us because we won't
get a chance to examine the address space before it disappears.
Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn
Powered by blists - more mailing lists