Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757661Ab1F1Ml5 (ORCPT ); Tue, 28 Jun 2011 08:41:57 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:41366 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756198Ab1F1Mi2 (ORCPT ); Tue, 28 Jun 2011 08:38:28 -0400 Date: Tue, 28 Jun 2011 14:38:23 +0200 From: Tejun Heo To: Denys Vlasenko Cc: Oleg Nesterov , linux-kernel@vger.kernel.org Subject: Re: [PATCH] ptrace: make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop (v.2) Message-ID: <20110628123823.GD3386@htj.dyndns.org> References: <201106262108.43011.vda.linux@googlemail.com> <20110626200442.GA16293@redhat.com> <20110627081139.GY30101@htj.dyndns.org> <20110627134713.GB3527@redhat.com> <20110627135252.GB30101@htj.dyndns.org> <20110627151827.GA6223@redhat.com> <20110628082512.GA3386@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1577 Lines: 39 Hello, On Tue, Jun 28, 2011 at 02:30:36PM +0200, Denys Vlasenko wrote: > On Tue, Jun 28, 2011 at 10:25 AM, Tejun Heo wrote: > > On Mon, Jun 27, 2011 at 05:18:27PM +0200, Oleg Nesterov wrote: > > Yeah, but that's a pretty silly way to do it. ?If we make it depend on > > PT_SEIZED, we can simply say "if seized, EXEC reports..." but as it > > currently stands, it would go like "If the message is non-zero on > > EXEC, it indicates... ?This behavior is valid since kernel version > > x.x.x". > > This is true for any new addition to API. > It starts from some kernel version. Hmmm... but as I wrote above, we have a choice to make here and the two options are clearly different? > >?Maybe adding a guarantee that PTRACE_SEIZE capable kernel > > always reports the old pid on EXEC but that would still seem > > unnecessarily complicated. ?It isn't a bug fix. ?I don't see much > > point in introducing new behavior separately. > > This new feature looks orthogonal to PTRACE_SEIZE to me. Yeah, sure, but we're bundling a number of behavior changes with PT_SEIZED because it's impractical to introduce each with its own compatibility / feature test bits, so it makes sense to do the same with this one, I think. It's not like there's a lot to gain by supporting this outside of SEIZE anyway. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/